Можно бесплатно получить книгу https://buf.build/resources/data-engineering-design-patterns

В комментариях я скачал для вас.

Учите JOINs!

По инженерным командам заметил определенные patterns.

Например, по размеру команды и поведению.

Я могу разделить команды на две большие группы.

1) маленькая команда 1-3 человека, где все делают все достаточно быстро, помогают друг другу. Это не обязательно стартап, это может быть большая компания, но команды там маленькие и автономные. Инженеры чувствуют свободу и занимаются тем, что нравится.

2) большая команда до 10 человек и выше. Тут уже полная неразбериха, каждые пилит что-то свое, старенькие инженеры не хотят помогать новеньким. Решения принимаются либо очень долго, либо очень быстро и непрозрачно, часто кулуарно. Эксперты становятся bottle neck и могут быть токсичными для всей команды. Особенно их бесит, когда берут новых инженеров с зарплатой на 30% выше, чем у них.

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

->Согласно закону Брукса, каждая “добавленная голова” повышает стоимость координации (n(n-1)/2).

->Согласно эффекту Рингельмана, с ростом группы падает индивидуальный вклад.

->Согласно закону Конуэя, система копирует структуру коммуникаций. Если оргуструктура запутана, продукт тоже будет фрагментирован.

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

Как диагностировать проблему?

- Время принятия решения и кол-во решения принятых без обсуждений с командой. Иначе говоря, отсутствия технических документов - tech spec, RAPID, etc
- Задержка с Code Review и очередь к “экспертам”
- Низкие оценки в опросах про эффективность команды (опросы важный элемент для больших команд)
- Четкие сигналы о проблемах на встречать 1:1
- Отсутствие ownership и инициативы от команды

А как у вас обстоят дела с инженерными командами? Вы эксперт bottle neck? Страдаете от закрытости коллег? Не знаете как расшевелить ваши команды?

👩‍💻👨‍💻 Хочешь узнать, как AI реально меняет работу инженеров в России?

Александр, автор канала Книжный Куб рассказал про исследование в Т-Банке: они собирают данные о том, как компании применяют AI, что работает, а что — просто хайп.

Пройти можно здесь 👉 Ссылка на опрос (≈30 минут).

А в январе–феврале будут результаты + отчёт по методологии.

PS в РФ паттерн использования AI инструментов отличается от того, что я вижу в Северной Америке, поэтому мне будет тоже интересно узнать его результаты.

Всех с пятницей!

Как появляется технический долг? (Technical debt)

Все очень просто - ушлые ребята менеджеры топят за скорость в ущерб качеству.

Вот свежий пример:

would encourage us to bias for speed over accuracy, ship it (Нужно скорее фокусироваться на скорости, чем на точности, и выкатывать)

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

А как у вас со “speed over accuracy”?

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

would encourage us to bias for speed over accuracy, ship it

То получается, все таки время у нас не так много, на написания кода. Я спорить не буду с экспертами, кто будет доказывать, что ❌уйн😮 ваш AI и ничего он не понимает в написании кода😇

Лучше расскажу другую идея, что системный дизайн сейчас очень важен, так как AI (еще) не способен понять бизнес контекст и ему все равно, что там будет Batch или Streaming. С poker face он вам будет доказывать, что Batch лучше, streaming. А если ему сказать, что он не прав, он вам точно также расскажет, что Streaming лучше Batch.

Для меня сейчас самое ценное это System Design. Его намного сложней “списать” и “придумать” на собеседовании, если не было реального опыта. Далее был бы data modelling, но без него можно существовать, а вот без правильной архитектуры совсем сложно.

Для любого собеседования на ML, DE - system design must have. Ну и самим было бы классно разбираться, что зачем и почему. Так что качайте системный дизайн для аналитических и ML систем, и там обязательно должно быть место для GenAI.