В инженерных командах развитие часто пытаются рассматривать как индивидуальное качество: хочет человек учиться или нет. Кто хочет — вырастет, с остальными и возиться нечего.

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

Но на практике обучение и развитие — это не столько про личную мотивацию, но и про социальные отношения. Люди вкладывают силы потому, что считают сам процесс развития осмысленным и безопасным для себя. И одна из задач нас как лидеров (формальных или нет) — как раз придать процессу осмысленность и безопасность

Хочется на стриме разобраться, как мотивация, доверие и готовность команды вкладываться связаны между собой и почему без этого даже разумные решения и инициативы часто остаются на уровне разговоров.

Разбираться в этом мне будет помогать Ася Исакова — организационный психолог (магистр Work, Organizational & Personnel Psychology) и приглашённый лектор университета Pompeu Fabra (Барселона).

Почитать Асю можно в её канале: Это База | Компас конгруэнтности

Дата: 26 января 18-00 мск. Добавьте себе в календарь https://addcal.io/e/yd2ty2ewu9m6

Ссылки на стрим
Youtube
Zoom

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

Сейчас разбираюсь в проекте на не совсем мне привычных Python/Django. Естественно использую агенты для изучения и модификации. Поменял код, поправил, потестил, залил в репу, создал ПР, мне накидали комментов — все как обычно.

Дальше я настроил в копайлоте github mcp, хотел по очереди получать правки, менять код и коммитить. Но промпт получился слишком общим. В итоге агент сам поправил весь код в соответсвии с комментами, запушил, прокомментил в пулл-реквесте через mcp. Ладно я сознательный — посмотрел коммиты, добил промптами пару вещей, которые явно не были проговорены в пулл-реквесте, дополнительно отревьювил код ллмкой и только после этого понес на повторное ревью.

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

Саша Поломодов запилил книгу сайт про Систем дизайн и все что около. Саша давно форсит эту тему — круто, что у него дошли руки все это скомпилировать.

https://system-design.space/

Друзья, уже через час ждем вас на стриме, выбирайте удобную платформу и усаживайтесь поудобнее

Вопросы, кейсы, комментарии пишите в этом треде или в личку, если нужна анонимность

Youtube
Zoom

Велкам! 🎉

Сегодня так много интересного!!!

1. Стрим с Владом Хононовым Loosely Coupled - Deep dive into coupling with Domain-Driven Design https://www.youtube.com/live/NGENigtNUck 🍾

2. Дискуссия Rebecca Wirfs-Brock и Mathias Verraes https://virtualddd.com/sessions/critically-engaging-with-models-a-conversation-with-rebecca-and-mathias/ 👏

3. Финальный тур ЛЧ 🙈

Альберто Брандолини с командой выкатили паттерны для проведения Event Storming

https://www.eventstorming.com/patterns/

Рекомендую ознакомится, но кажется главная проблема теперь как позвать агентов на такой воркшоп

Завидую джавистам в том что у них есть такие спикеры как Алексей Шипилёв (рассказывает всякое про сборку мусора) и Андрей Бреслав

Очень интересный подкаст про котлин и как его делали https://newsletter.pragmaticengineer.com/p/the-programming-language-after-kotlin

в свете использования LLM для разработки людя много обсуждают покупать или строить. Если смотреть с позиции DDD, то все однозначно: generic сабдомен покупаем, core саюдомен строим сами, supporting -- как получится.

Но LLM -- геймчейнджер, и теперь люди задаются вопросом, зачем нам платить за SaaS $n per months per user, если мы можем просто такой же саас навайбкодить за вечер (и пачку токенов)?

Для меня ответ по-прежнему прост: можете купить зрелое решение -- купите. Дорого? Попробуйте план попроще. Все равно не по карману? Посмотрите на опенсорс!

Когда вы берете готовый продукт, вы получаете не только код, вы покупаете:
- некую готовую методологию решения проблемы
- тонны продуманных и решенных корнер-кейсов
- какую-никакую секурность
- решенные инфраструктурные вопросы
- потенциальное развитие

Когда все таки кодить/вайбкодить с нуля имеет смысл?

1. На рынке нет устоявшихся/готовых решений для вашей проблемы. В том числе из-за санкций или других ограничений.
2. У вас какие-то специфические требования (реально специфические, а не просто "мынетакиекаквсе"). Например, требования регулятора или стратегическое решение компании. Но и то я бы начал с обзора опенсорсных решений под подходящей лицензией.
3. Вам нужен какой-то небольшой набор фич от огромного и дорогого сааса. Опять же можно посмотреть на конкурентов.
4. Когда продукт может стать частью портфеля компании. Если сфера SaaS близка компании и есть желание реализовать свою экспертизу в продукте, то вполне хороший повод стартануть такое как внутренний продукт. Но будьте готовы, что будут не только прямые затраты на разработку, но и на косвенные на адаптацию.
5. Вы крупняк и платить даже большой команде разработки заметно дешевле.


Вы начали уже вайбкодить что-то своё вместо подписки?

Опять про ллм- разработку.

Сейчас на работе у меня сложилась идеальная ситуация

Есть достаточно большой неизвестный мне проект на плохо известном стеке (джанга)

Есть набор задач без горящих дедлайнов

Есть надежные процессы, которые не пропустят дичь на прод

Есть мое, как мне кажется, неплохое понимание прекрасного в разработке

И вот чувствую себя как на эмоциональных качелях: от восторга до полного разочарования и обратно.

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

Вроде все просто: надо взять токен и в бекграунд таске сходить в другую систему.

Но оказалось:

Тот токен который есть нельзя использовать для этого обращения

Передавать нужный токен в celery таску несекурно

Кэш основной аппки и селери разделен — нельзя использовать просто тот же метод получения токена

При переходе на треды могут начаться проблемы с утечкой коннекшенов.

И вот с каждой итерацией решение усложняется и усложняется, хотя на старте казалось что там «пять минут работы программиста»

И пока что я не понимаю что делать с подобными задачами. Изначально они все выглядят одинаковыми по сложности