На днях мне предложили добавиться в очередную папку тимлидских/руководительских каналов, ну я и согласился.

Разнообразие — хорошо. Бесстыдной ***илитации нет — тоже хорошо.

Из этой папки я пока знаком сам только с Тимлидом Леонидом из SkyEng’а, придётся познакомиться и с другими 🙂

https://www.group-telegram.com/addlist/tlsQuGigGwRjODA0

https://arxiv.org/abs/2504.17004

забавно: обнаружение галлюцинаций невозможно в современных LLM в принципе, какой бы механизм self-evaluation не применялся.

Правильно ли я понимаю, что без достаточного уровня RLHF человеком, LLM будет галлюцинировать только больше со временем, и ничего с этим не сделать никак?

И ещё: получается, что чем жирнее LLM становится (то есть, чем больше данных в тренинг запихивается), тем хуже будет ситуация становиться?

Значит ли это, что коллапс моделей неизбежен, если не вкладывать всё больше и больше денег в человеческую RLHF?

Продолжая тему “best practices”.

Кажется, само стремление к поиску «best practice» часто является симптомом одной или нескольких проблем:

1. перегрузка: когда времени нет подумать, легче всего последовать упрощённой “эвристике” (отсюда все карго-культы). [1][2][3]

2. отсутствие “навыка” критического мышления. (Навык в кавычках — я не до конца понимаю, умение ли это или навык. Современная литература говорит, что критическое мышление редко развивается само, чаще всего ему нужно осознанно учиться. Но всё же иногда появляется и само, то есть может быть и умение и навык) — человек просто не знает, как выбирать и анализировать проблему, и как подходить к выработке оптимального решения [4][5][6]

3. cоциальное или организационное давление. Иногда к неоптимальным решениям принуждают так или иначе, прямо через “давление” со стороны коллег или менеджера или косвенно через конформизм. [7][8]

набор любопытных исследований про TDD:

1. A Comparative Case Study on the Impact of Test-Driven Development on Program Design and Test Coverage
2. Realizing quality improvement through test driven development: results and experiences of four industrial teams
3. A structured experiment of test-driven development

я не знаю, кому нужны какие доводы, чтоб попробовать TDD, но для меня сейчас значимым преимуществом такого программирование стало почти полное отсутствие “когнитивного страха”.

Я не программирую щас фултайм, буквально полчаса-час в день, да и то не каждый день получается выделить. Так вот раньше, когда я писал code-first подходом, “сесть на полчасика” было довольно трудно — я знал, что мне придётся всю структуру подпрограммы “вгрузить в голову” для того, чтоб изменение, которое я вношу, не разломало ничего. Сейчас же я просто сажусь, думаю о том, для чего и как сформулировать ожидания, пишу по ним тест, и потом пишу код. Или даже не пишу код, а оставляю систему в “red” состоянии — всё равно основная работа уже сделана.

28 мая товарищи Павел и Илья будут проводить (бесплатное) онлайн-мероприятие мотивам тренинга: https://www.group-telegram.com/above_the_range/714

я о марте месяце участвовал в их курсе, помогал с темой переговоров про увольнение. Ребята хорошие, советую. Это вот мероприятие, что будет — про переговоры на работе вовсе (далеко не только про увольнение и повышение зп).

P.S. реклама бесплатная и искренняя

С четверга по вчера проехал 3000км на поезде, постоял со стендом в Цюрихе на GreaTEST Quality conf, выступил на Tech Internals Conf в Берлине, попытался (безуспешно) уехать на автобусе в Лиссабон, чтобы выступить там на митапе. Пришлось выступить онлайн, спасибо ув. тов. Евгению Коту, что организовал стриминг.

Надеюсь, что “спонсоры” моей смены полётов на разъезды — британское консульство в Париже — успеют мне-таки вернуть паспорт до понедельника, чтоб улететь на всю следующую неделю в Эдинбург на EuroSTAR.

Выступления и общение вживую с людьми — очень весело, но поездки на дальние дистанции на поездах и автобусах — крайне тяжело.

а вот очередное про DISC

Как вы, наверное, знаете, мы уже совсем скоро выпускаем для вас мракобесную настолку.

Мой соавтор в этом проекте — мой друг, психолог Илья Косников.

Недавно Илья решил завести свой блог на YouTube. И, по-моему, у него получилось отлично. Первое видео — про соционику, но под другим углом, не так, как было на канале у меня. Предлагаю поддержать хорошего человека с начинающим каналом просмотром и репостом. Пусть снимает больше видео! А у мракобесов пусть пусть пригорает.

https://www.youtube.com/watch?v=sW--GT4imfg

пришёл мне esp32-s3 от seeed.

самый крошечный esp32-s3 из тех, что я видел вообще

назвал Грегом

Первый созвон рабочий по-французски — done.

Офигенно волнительно было до, но оказалось всё довольно несложно. Во дела!

ребята, расскажите пожалуйста, что с помощью LLM у вас получилось сделать из области, которая раньше вам была неизвестна? И так, чтоб результат кто-то знающий эту область оценил как хороший?

я вот решил попробовать RTSP сделать, и до того, как почитал книжку, никак не выходило у меня с помощью гопоты что-то сделать работающее вообще.

У замечательного Дмитрия продолжение вышло, очень советую:

Всем привет! Продолжаем разговор :) А в каком-то смысле, учитывая долгий перерыв и масштаб предстоящей задачи, и начинаем его заново.

В предыдущем цикле я рассказывал о том, что такое команда, зачем она нужна и как образуется естественным образом, если ничего специально не делать с точки зрения командостроения. Теперь же я сосредоточусь на том, как строить команду целенаправленно. Начну с описания "матчасти": как устроена командность как феномен, от каких факторов зависит её возникновение, с чем вообще предстоит работать. Дальше будем всё это подробно разбирать. Как всегда, материала получилось много, поэтому разобью его на две части. Сегодня часть 1-я.

Видео
https://www.youtube.com/watch?v=y1vBMyyEA44

Только звук (подкаст)
* Хост на Podster.fm (RSS)
* Apple Podcasts
* YouTube Music
* Яндекс.Музыка

Текстовая версия
1. Постановка задачи
2. Общая структура командности
3. Люди
4. Группа
5. Контекст
6. Выполняемая работа

выпадал на две недели, сначала была куча поездок, а потом срочный отпуск, ибо кончились силы совсем.
наплавался от души!

пора и поработать! На этой неделе будут посты.

На одном из моих следующих митапов будет выступать товарищ Митеш, занимающийся производством и обслуживанием цифровых копий (digital twins). У них моделей — тьма, от полноценных моделей батарей
до целых медицинских устройств, от тракторов до систем подводных лодок.

Будет рассказывать, что такое вообще эти цифровые копии, где их применяют и почему.

Если кто знаком с темой, или кому тема интересна, задавайте свои вопросы пожалуйста, я постараюсь включить их в доклад.

миллион лет назад делал доклад про PDR , и до сих пор считаю, что любая добавляемая сложность в процессы труда должна быть обоснована не хуже, чем добавление сложности в техническую систему.

инженер не добавляет (я надеюсь) условную кафку просто потому что “кафка это ништяк”, но почему-то этот же инженер становится тимлидом или того хуже СТО и спокойно накидывает в процессы труда всё, что где-то ему казалось прикольным.

вослед за ув. тов. Аланом Холубом хочу собрать набор приемлемых “defaults” для процессов труда.

Начну, наверное, с асинхронности.

Мне видится, что синхронный труд — то есть, mob work — стоит рассматривать как дефолтный, и асинхронность — то есть “декомпозиция” задачи для “разбиения” по отдельным разработчикам — добавляться только после обоснования необходимости.

Ровно так же, кажется, в программирование синхронность — default, и добавление любой асинхронщины мы стараемся обосновывать так, чтоб выгоды было больше, чем сопутствующей цены обслуживания увеличенной сложности.


Upd:
в программировании различие между синхронщиной и асинхронщиной всем вроде известно и понятно, а вот в работе буквально сихнронно это “взяли и сделали все вместе”, а асинхронно это “‘декомпозировали’ задачу, ‘раскидали по людям’, а потом начали играть в пинг-понг со статусами и тикетами в джире”