Про три пути тимлида
Карьерный рост разработчика более менее понятен. Ты набираешься новых знаний, применяешь их на практике, получаешь бесценный опыт, и дальше либо углубляешь знания в той же области, либо захватываешь соседние. В первом случае ты становишься очень узким и очень ценным экспертом, во втором – не менее ценным экспертом, который готов решать очень разнообразные задачи. Оба подхода имеют право на жизнь, оба востребованы.
Карьерный рост тимлида – штука гораздо более загадочная. Вот какие варианты предлагают в статье:
1️⃣Расти вверх по менеджерской ветке
С какими сложностями предстоит столкнуться:
👉Часто на высокие менеджерские позиции компании нанимают "варягов" снаружи. Это делается с простой целью – сломать исторически сложившиеся нормы и принести новую кровь. Единственный хороший способ этому что-то противопоставить – делать свою заинтересованность в дальнейшем росте очень явной, чтобы о ней знали и ваш менеджер, и его менеджер. Ну и не пропускать любые возможности.
👉Набор нужных скиллов будет меняться. Надо понимать, насколько вы готовы к решению задач, которые будут ждать на уровень выше, и насколько вы готовы потерять те навыки, которые есть сейчас (например, близкую работу с кодом).
👉Нужно честно ответить себе на вопрос – готовы ли вы принимать все более сложные решения, влияющие на людей – увольнения, сокращения, закрытие проектов.
2️⃣Работать в режиме маятника, и раз в два-три года переходить из менеджера в разработчика и обратно
Такой подход позволяет быть и очень сильным техническим менеджером, и ценным стафф-инженером – вы умеете управлять людьми и проектами, но при этом инженерные навыки все время остаются актуальными.
Второй плюс – хорошо работает для тех, кто чувствует усталость от текущей роли, но не полное отторжение. Отвлеклись на пару лет, выдохнули, вернулись обратно.
Проблема в том, что если в таком маятнике застрять, то в нем вы и остановитесь. Расти выше со временем станет сложнее. Поэтому надо относиться к такому треку либо как ко временному решению, либо как к долгосрочному плану, если вы хотите быть кем-то вроде техлида.
3️⃣Переход обратно в разработчики
Решение на такой переход обычно дается довольно тяжело и воспринимается как поражение. Но ничего плохого в нем нет – это сильное решение, если вы понимаете, что стресс от менеджмента мешает жить нормальную жизнь.
Карьерный рост разработчика более менее понятен. Ты набираешься новых знаний, применяешь их на практике, получаешь бесценный опыт, и дальше либо углубляешь знания в той же области, либо захватываешь соседние. В первом случае ты становишься очень узким и очень ценным экспертом, во втором – не менее ценным экспертом, который готов решать очень разнообразные задачи. Оба подхода имеют право на жизнь, оба востребованы.
Карьерный рост тимлида – штука гораздо более загадочная. Вот какие варианты предлагают в статье:
1️⃣Расти вверх по менеджерской ветке
С какими сложностями предстоит столкнуться:
👉Часто на высокие менеджерские позиции компании нанимают "варягов" снаружи. Это делается с простой целью – сломать исторически сложившиеся нормы и принести новую кровь. Единственный хороший способ этому что-то противопоставить – делать свою заинтересованность в дальнейшем росте очень явной, чтобы о ней знали и ваш менеджер, и его менеджер. Ну и не пропускать любые возможности.
👉Набор нужных скиллов будет меняться. Надо понимать, насколько вы готовы к решению задач, которые будут ждать на уровень выше, и насколько вы готовы потерять те навыки, которые есть сейчас (например, близкую работу с кодом).
👉Нужно честно ответить себе на вопрос – готовы ли вы принимать все более сложные решения, влияющие на людей – увольнения, сокращения, закрытие проектов.
2️⃣Работать в режиме маятника, и раз в два-три года переходить из менеджера в разработчика и обратно
Такой подход позволяет быть и очень сильным техническим менеджером, и ценным стафф-инженером – вы умеете управлять людьми и проектами, но при этом инженерные навыки все время остаются актуальными.
Второй плюс – хорошо работает для тех, кто чувствует усталость от текущей роли, но не полное отторжение. Отвлеклись на пару лет, выдохнули, вернулись обратно.
Проблема в том, что если в таком маятнике застрять, то в нем вы и остановитесь. Расти выше со временем станет сложнее. Поэтому надо относиться к такому треку либо как ко временному решению, либо как к долгосрочному плану, если вы хотите быть кем-то вроде техлида.
3️⃣Переход обратно в разработчики
Решение на такой переход обычно дается довольно тяжело и воспринимается как поражение. Но ничего плохого в нем нет – это сильное решение, если вы понимаете, что стресс от менеджмента мешает жить нормальную жизнь.
Хабр
Маршрут перестроен: исповедь лида о том, куда расти дальше (и всегда ли расти)
Я лид команды – и хочу идти дальше вверх! Точнее, не уверен, что хочу, но в айтишке надо ведь расти и развиваться, значит, следующая позиция для меня — менеджмент на уровень выше. Или нет? Как...
❤34
Про нормализацию девиаций
Если проблемы не исправляются в течение какого-то времени, то люди привыкают жить с ними и они становятся новой нормой. Скорее всего, вы сталкивались с такими историями в своем опыте:
❌Сломанные тесты в кодовой базе были замьючены вместо починки, спустя какое-то время такая же судьба постигла все тесты, и постепенно их отстутствие стало новой нормой.
❌В команду внедряли скрам, на негативные последствия закрыли глаза, и в итоге все приняли как норму то, что треть рабочего времени съедается на абсолютно бесполезные встречи и упражнения с бэклогом.
Давайте разбираться, почему нормализация девиаций очень опасна:
👉Оправдание существующего порядка. Люди не любят сталкиваться с дискомфортом. Признать, что система сломана – значит принять на себя часть ответственности, и поднять неудобные вопросы, за которые могут и по шапке дать. Гораздо проще защищать существующие подходы, и находить понятные оправдания им. Поэтому любая нормализация дисфункции в перспективе приведет к тому, что отыграть все назад будет в 10 раз сложнее.
👉Система выталкивает людей, не согласных с ней, и поддерживает согласных. Соответственно все те, кто открыто называл дисфункцию дисфункцией со временем уйдут, а оставаться будут как раз таки те, кто ее поддерживает. В итоге все вокруг вообще забудут о том, как может выглядеть норма.
👉Дисфункции поддерживают друг друга, и постепенно компания, в которой не принято открыто говорить о проблемах и решать их, превращается в бессмысленного и беспощадного монстра с бесконечностью митингов, пустых дэшбордов, KPI, но без явного направления движения и без лидеров, которые готовы брать на себя ответственность.
Если проблемы не исправляются в течение какого-то времени, то люди привыкают жить с ними и они становятся новой нормой. Скорее всего, вы сталкивались с такими историями в своем опыте:
❌Сломанные тесты в кодовой базе были замьючены вместо починки, спустя какое-то время такая же судьба постигла все тесты, и постепенно их отстутствие стало новой нормой.
❌В команду внедряли скрам, на негативные последствия закрыли глаза, и в итоге все приняли как норму то, что треть рабочего времени съедается на абсолютно бесполезные встречи и упражнения с бэклогом.
Давайте разбираться, почему нормализация девиаций очень опасна:
👉Оправдание существующего порядка. Люди не любят сталкиваться с дискомфортом. Признать, что система сломана – значит принять на себя часть ответственности, и поднять неудобные вопросы, за которые могут и по шапке дать. Гораздо проще защищать существующие подходы, и находить понятные оправдания им. Поэтому любая нормализация дисфункции в перспективе приведет к тому, что отыграть все назад будет в 10 раз сложнее.
👉Система выталкивает людей, не согласных с ней, и поддерживает согласных. Соответственно все те, кто открыто называл дисфункцию дисфункцией со временем уйдут, а оставаться будут как раз таки те, кто ее поддерживает. В итоге все вокруг вообще забудут о том, как может выглядеть норма.
👉Дисфункции поддерживают друг друга, и постепенно компания, в которой не принято открыто говорить о проблемах и решать их, превращается в бессмысленного и беспощадного монстра с бесконечностью митингов, пустых дэшбордов, KPI, но без явного направления движения и без лидеров, которые готовы брать на себя ответственность.
Medium
Normalizing the Broken
I’d been meaning to write about this for a month or so. But the topic is complex, sensitive to some extent, and interrelated with millions…
❤46👍18🔥4
Разница между оркестрацией и лидерством
Продуктовую работу услрвно можно разбить на шесть шагов:
1️⃣Problem Discovery: выбираем, какие проблемы существуют
2️⃣Problem Selection: выравниваемся со стейкхолдерами на тему того, какие из проблем самые важные
3️⃣Solution Discovery: ищем возможные решения для выбранной проблемы
4️⃣Solution Selection: выравниваемся со стейкхолдерами про то, какой подход к решению выберем
5️⃣Execution: запиливаем решение
6️⃣Ongoing Revision: постоянно выравниваем команду и стейкхолдеров про план действий
Так вот, в организациях, управляемых в top-down стиле, менеджеры часто превращаются в оркестраторов – они отвечают только за последние три шага, и вообще не представляют, что в другой компании с большей автономностью от них могли бы ожидать лидерства – то есть еще и принятия решений про то, что делать.
Вот признаки менеджера-оркестратора:
👉Относится к приоритизации как к своему основному инструменту работы. Это единственное, что доступно, когда ты не можешь повлиять ни на решаемые проблемы, ни на форму решения.
👉Принимает приносимые проблемы и решения как данность, единственное, что спрашивает – про их приоритет относительно других задач.
👉Фокусируется на планировании и процессах, защищает команду от изменений планов всеми силами.
Продуктовую работу услрвно можно разбить на шесть шагов:
1️⃣Problem Discovery: выбираем, какие проблемы существуют
2️⃣Problem Selection: выравниваемся со стейкхолдерами на тему того, какие из проблем самые важные
3️⃣Solution Discovery: ищем возможные решения для выбранной проблемы
4️⃣Solution Selection: выравниваемся со стейкхолдерами про то, какой подход к решению выберем
5️⃣Execution: запиливаем решение
6️⃣Ongoing Revision: постоянно выравниваем команду и стейкхолдеров про план действий
Так вот, в организациях, управляемых в top-down стиле, менеджеры часто превращаются в оркестраторов – они отвечают только за последние три шага, и вообще не представляют, что в другой компании с большей автономностью от них могли бы ожидать лидерства – то есть еще и принятия решений про то, что делать.
Вот признаки менеджера-оркестратора:
👉Относится к приоритизации как к своему основному инструменту работы. Это единственное, что доступно, когда ты не можешь повлиять ни на решаемые проблемы, ни на форму решения.
👉Принимает приносимые проблемы и решения как данность, единственное, что спрашивает – про их приоритет относительно других задач.
👉Фокусируется на планировании и процессах, защищает команду от изменений планов всеми силами.
Lethain
Moving from an orchestration-heavy to leadership-heavy management role.
For managers who have spent a long time reporting to a specific leader or working in an organization with well‑understood goals, it’s easy to develop skill gaps without realizing it. Usually this happens because those skills were not particularly important…
👍25❤4
Разверните ваш проект в облаке
Запускайте сайты и приложения, разворачивайте базы данных и обрабатывайте большие объемы данных в гибком и надежном облаке Selectel. Здесь в одном окне браузера можно развернуть инфраструктуру для проектов с разными запросами: от небольшого телеграм-бота до высоконагруженного сервиса с пиковыми нагрузками.
Облако Selectel подойдет проектам, которым важны:
☁️ Гибкость: можно выбрать конфигурацию под разные запросы по мощности и бюджету и в пару кликов масштабировать инфраструктуру при изменении нагрузки.
☁️ Надежность: легко создать геораспределенную инфраструктуру, чтобы получить максимальную отказоустойчивость
☁️ Поддержка: инженеры провайдера помогут выбрать индивидуальное решение и перенести проект в Selectel, а также поддержат на всех этапах.
Переносите ваш проект в облако Selectel бесплатно: https://slc.tl/pw9pa
Реклама. АО «Селектел», ИНН 7810962785, ERID: 2VtzqwMeYCp
Запускайте сайты и приложения, разворачивайте базы данных и обрабатывайте большие объемы данных в гибком и надежном облаке Selectel. Здесь в одном окне браузера можно развернуть инфраструктуру для проектов с разными запросами: от небольшого телеграм-бота до высоконагруженного сервиса с пиковыми нагрузками.
Облако Selectel подойдет проектам, которым важны:
☁️ Гибкость: можно выбрать конфигурацию под разные запросы по мощности и бюджету и в пару кликов масштабировать инфраструктуру при изменении нагрузки.
☁️ Надежность: легко создать геораспределенную инфраструктуру, чтобы получить максимальную отказоустойчивость
☁️ Поддержка: инженеры провайдера помогут выбрать индивидуальное решение и перенести проект в Selectel, а также поддержат на всех этапах.
Переносите ваш проект в облако Selectel бесплатно: https://slc.tl/pw9pa
Реклама. АО «Селектел», ИНН 7810962785, ERID: 2VtzqwMeYCp
👎7👍4
Как в AWS подходят к оценке продуктивности разработки
Инженеры AWS, занимающиеся оптимизацией инфры и процессов разработки, искали способ получить оценку влияния своих изменений, хоть как-то приближенную к реальному миру. Считать только velocity – опасно, так как из уравнения исключается качество. Считать сэкономленное время в отдельных задачах – бесполезно, не дает общей картины, и не обязательно ведет к системному улучшению.
Вместо этого они взяли фреймворк Cost-to-Serve (CTS), который до этого использовался Amazon, чтобы оценивать эффективность цепочки доставки физических товаров. В чем суть:
👉CTS измеряет общую стоимость доставки unit of software. Юнит – какой-то конечный результат работы, который команда считает достаточно ценным, чтобы разработать, проверить качество, доставить до пользователей и поддерживать его. Этот юнит различается для разных команд, потому что, например, регулярность релизов мобильных приложений накладывает свои ограничения.
👉CTS расчитывается как (стоимость разработки + стоимость разработческой инфры) / количество поставленных юнитов.
👉Так как результат метрики – деньги, она хорошо привязывается к любым другим финансовым показателям, и дает хорошее представление о ценности платформенных улучшений.
Инженеры AWS, занимающиеся оптимизацией инфры и процессов разработки, искали способ получить оценку влияния своих изменений, хоть как-то приближенную к реальному миру. Считать только velocity – опасно, так как из уравнения исключается качество. Считать сэкономленное время в отдельных задачах – бесполезно, не дает общей картины, и не обязательно ведет к системному улучшению.
Вместо этого они взяли фреймворк Cost-to-Serve (CTS), который до этого использовался Amazon, чтобы оценивать эффективность цепочки доставки физических товаров. В чем суть:
👉CTS измеряет общую стоимость доставки unit of software. Юнит – какой-то конечный результат работы, который команда считает достаточно ценным, чтобы разработать, проверить качество, доставить до пользователей и поддерживать его. Этот юнит различается для разных команд, потому что, например, регулярность релизов мобильных приложений накладывает свои ограничения.
👉CTS расчитывается как (стоимость разработки + стоимость разработческой инфры) / количество поставленных юнитов.
👉Так как результат метрики – деньги, она хорошо привязывается к любым другим финансовым показателям, и дает хорошее представление о ценности платформенных улучшений.
👍11❤7👎6🔥2
Новые выпуски тимлидских подкастов
За месяц с последнего дайджеста подкастов вышло много новых интересных выпусков. Сохраняем в подборки и слушаем – можно даже параллельно с очередным бесполезным митингом!
👉"Бреслав и Ложечкин" про то, может ли руководитель проявлять свои эмоции, и где провести грань
👉"Три тимлида заходят в бар" про то, как ужерживать в команде самых ценных и важных специалистов на высоких грейдах
👉"КОДА КОДА" про то, как тимлиду управлять собственной энергией и мотивацией
👉Подлодка про то, как AI помогает в рабочих и личных задачах за пределами разработки (например, в поиске работы и подготовке к интервью)
👉"Едим слона целиком" про то, что такое стресс в менеджерской работе, и как с ним справляться
За месяц с последнего дайджеста подкастов вышло много новых интересных выпусков. Сохраняем в подборки и слушаем – можно даже параллельно с очередным бесполезным митингом!
👉"Бреслав и Ложечкин" про то, может ли руководитель проявлять свои эмоции, и где провести грань
👉"Три тимлида заходят в бар" про то, как ужерживать в команде самых ценных и важных специалистов на высоких грейдах
👉"КОДА КОДА" про то, как тимлиду управлять собственной энергией и мотивацией
👉Подлодка про то, как AI помогает в рабочих и личных задачах за пределами разработки (например, в поиске работы и подготовке к интервью)
👉"Едим слона целиком" про то, что такое стресс в менеджерской работе, и как с ним справляться
1❤13👍6🔥4
Про культуру встреч
Митинги, особенно регулярные, имеют свойство постепенно разрастаться из-за того, что не приглашенные туда изначально люди чувствуют FOMO. В итоге на встречи ходят не потому, что их надо посетить, а потому, что страшно пропускать.
Чтобы это сломать, нужно сделать так, чтобы безопасным дефолтным выбором было отклонить встречу. Вот каких изменений это требует:
👉В описании митинга должна быть агенда встречи с примерной оценкой, сколько времени на какую тему вы хотите потратить
👉Если на встрече планируется принять решения, напишите об этом явно
👉Модератор встречи должен следить за тем, что вы придерживаетесь запланированной агенды, и ей в итоге можно верить
👉Любые отклонения от запланированных тем тормозятся и откладываются на другие обсуждения
👉Участники приходят только тогда, когда сильно заинтересованы в теме, готовятся к участию, и активно участвуют в обсуждениях
👉Те, кто отклоняет встречу, готовы к тому, что решения принимаются без них
👉Ведутся подробные meeting minutes
The goal of an exceptional meeting culture is to allow for people to constructively decline meetings by fully understanding the consequences of their action.
Митинги, особенно регулярные, имеют свойство постепенно разрастаться из-за того, что не приглашенные туда изначально люди чувствуют FOMO. В итоге на встречи ходят не потому, что их надо посетить, а потому, что страшно пропускать.
Чтобы это сломать, нужно сделать так, чтобы безопасным дефолтным выбором было отклонить встречу. Вот каких изменений это требует:
👉В описании митинга должна быть агенда встречи с примерной оценкой, сколько времени на какую тему вы хотите потратить
👉Если на встрече планируется принять решения, напишите об этом явно
👉Модератор встречи должен следить за тем, что вы придерживаетесь запланированной агенды, и ей в итоге можно верить
👉Любые отклонения от запланированных тем тормозятся и откладываются на другие обсуждения
👉Участники приходят только тогда, когда сильно заинтересованы в теме, готовятся к участию, и активно участвуют в обсуждениях
👉Те, кто отклоняет встречу, готовы к тому, что решения принимаются без них
👉Ведутся подробные meeting minutes
Abitmighty
a BIT mighty - The ultimate meeting culture
I like bits, bits are mighty. With bits you can do impressive things!
11❤29👍19
Никто ничего не читает
Несмотря на истории из Amazon про writing culture, реальность и бигтеха, и компаний поменьше в том, что никто не читает больших документов. В самом лучшем случае часть людей прочитает по диагонали executive summary, но и на это расчитывать не стоит.
Единственный способ добиться того, чтобы информация из документа осела – перевести его в презентацию, регулярно показывать ее разным группам людей, и в целом регулярно ссылаться на документ в других коммуникациях.
Такое отношение к написанному тексту не только в нашей индустрии. Похожая ситуация в науке, где рецензенты не читают бумаги, и в финансах, где никто даже не пытается вчитаться в финансовые отчеты глубже, чем на уровне самых базовых метрик.
А теперь мы в картину сломанной письменной культуры добавляем еще и AI. В итоге еще больше документов будут писаться людьми, не обладающими глубоким знанием темы, а затем суммаризироваться для более быстрого прочтения. И если где-то в этом процессе важная информация теряется или искажается – никто и не заметит.
Несмотря на истории из Amazon про writing culture, реальность и бигтеха, и компаний поменьше в том, что никто не читает больших документов. В самом лучшем случае часть людей прочитает по диагонали executive summary, но и на это расчитывать не стоит.
Единственный способ добиться того, чтобы информация из документа осела – перевести его в презентацию, регулярно показывать ее разным группам людей, и в целом регулярно ссылаться на документ в других коммуникациях.
Такое отношение к написанному тексту не только в нашей индустрии. Похожая ситуация в науке, где рецензенты не читают бумаги, и в финансах, где никто даже не пытается вчитаться в финансовые отчеты глубже, чем на уровне самых базовых метрик.
А теперь мы в картину сломанной письменной культуры добавляем еще и AI. В итоге еще больше документов будут писаться людьми, не обладающими глубоким знанием темы, а затем суммаризироваться для более быстрого прочтения. И если где-то в этом процессе важная информация теряется или искажается – никто и не заметит.
Learningbyshipping
If Writing is Thinking…
Then what happens if AI is doing the writing and reading?
4👍40❤5👎2
Конференция Стратоплана про кризисный менеджмент
Менеджеру нужно постоянно балансировать между интересами двух сторон – бизнеса и его команды. В идеальном мире они, конечно же, сонаправлены, но на практике практически всегда разъезжаются. В кризисных ситуациях все только усугубляется – бизнесу нужно и двигаться быстрее, и резать косты, а сотрудникам, наоборот, нужны стабильность и понятные задачи.
На открытой конференции Стратоплана куча крутых экспертов расскажут, как менеджеру выживать в такой ситуации, приносить пользу и компании, и своей команде, и при этом не сходить с ума и не нарушать своих принципов. Вот самые интересные доклады из программы:
👉Слава Панкратов даст базовые принципы поведения в кризисных ситуациях
👉Роман Ивлиев объяснит, почему техлиду не стоит надевать на себя шапочку финансового директора, и вместо этого оставаться в своей зоне компетенции
👉Николай Ашанин разберет кучу инструментов по тому, как сокращать издержки и быстро перенаправлять команду, не убивая ее мотивацию
👉Андрей Менде расскажет, как строить автономные команды, у которых не нужно стоять над душой
А, в целом, там будут фаундеры и топы Skyeng, Kolesa Group, Nimax, Карьерного цеха, Sprouty, ОКБ «Понедельник», TDM из EPAM. Так что почерпнуть точно будет чего
📆Конференция онлайн, проходит с 12 по 15 августа. Участие бесплатное, с вас – только зарегистрироваться и прийти.
Менеджеру нужно постоянно балансировать между интересами двух сторон – бизнеса и его команды. В идеальном мире они, конечно же, сонаправлены, но на практике практически всегда разъезжаются. В кризисных ситуациях все только усугубляется – бизнесу нужно и двигаться быстрее, и резать косты, а сотрудникам, наоборот, нужны стабильность и понятные задачи.
На открытой конференции Стратоплана куча крутых экспертов расскажут, как менеджеру выживать в такой ситуации, приносить пользу и компании, и своей команде, и при этом не сходить с ума и не нарушать своих принципов. Вот самые интересные доклады из программы:
👉Слава Панкратов даст базовые принципы поведения в кризисных ситуациях
👉Роман Ивлиев объяснит, почему техлиду не стоит надевать на себя шапочку финансового директора, и вместо этого оставаться в своей зоне компетенции
👉Николай Ашанин разберет кучу инструментов по тому, как сокращать издержки и быстро перенаправлять команду, не убивая ее мотивацию
👉Андрей Менде расскажет, как строить автономные команды, у которых не нужно стоять над душой
А, в целом, там будут фаундеры и топы Skyeng, Kolesa Group, Nimax, Карьерного цеха, Sprouty, ОКБ «Понедельник», TDM из EPAM. Так что почерпнуть точно будет чего
📆Конференция онлайн, проходит с 12 по 15 августа. Участие бесплатное, с вас – только зарегистрироваться и прийти.
2🔥21👍20❤9
Карьера вайб-кодера – это тупик
Хороший разбор нескольких тейков, которые сейчас звучат из каждого утюга:
👉Те, кто первыми научится использовать AI, получат огромное преимущество.
Вряд ли. Навыками вайбкодинга овладеть довольно просто, наборы лучших практик меняются каждую неделю, а на рынок выходят все новые и новые продукты. Нет никакого конкурентного преимущества, которое можно сохранить. Нет никаких глубоких технических навыков, которые можно освоить. В лучшем случае вы выступаете бета-тестером и весело проводите время.
👉Главное – уметь хорошо промптить
Опять же, промптинг – это не сложный навык, требующий долгого обучения. Научиться писать качественный код на новом языке программирования, или строить надежные системы, в тысячи раз сложнее. А для good enough промпта достаточно описать качественную спецификацию, и вместе с AI в несколько заходов ее докрутить.
👉Вайбкодинг ускоряет работу в десять раз
Зависит от типа работы. В прототипировании точно да. В бойлерплейте – тоже. Но большинство разработчиков делает не greenfield проекты, а подкручивает огромные легаси системы. И в таких задачах реального мира ускорение в генерации кода практически никогда не ускоряет получение реального результата, так как бутылочные горлышки вообще не там.
👉AI упрощает работу программиста
Вы обмениваете ясность на скорость. Фичи генерируются быстро, но в голове программиста не выстраивается ментальная карта того, что и как в проекте работает. Поддерживать его становится сложнее, дебажить тоже, и со временем это только накапливается.
Главный вывод, к которому постепенно подходит индустрия – AI нужно уметь держать на коротком поводке, использовать его с очень конкретной целью, и избегать магического мышления. Опыт инструментом не заменить.
Хороший разбор нескольких тейков, которые сейчас звучат из каждого утюга:
👉Те, кто первыми научится использовать AI, получат огромное преимущество.
Вряд ли. Навыками вайбкодинга овладеть довольно просто, наборы лучших практик меняются каждую неделю, а на рынок выходят все новые и новые продукты. Нет никакого конкурентного преимущества, которое можно сохранить. Нет никаких глубоких технических навыков, которые можно освоить. В лучшем случае вы выступаете бета-тестером и весело проводите время.
👉Главное – уметь хорошо промптить
Опять же, промптинг – это не сложный навык, требующий долгого обучения. Научиться писать качественный код на новом языке программирования, или строить надежные системы, в тысячи раз сложнее. А для good enough промпта достаточно описать качественную спецификацию, и вместе с AI в несколько заходов ее докрутить.
👉Вайбкодинг ускоряет работу в десять раз
Зависит от типа работы. В прототипировании точно да. В бойлерплейте – тоже. Но большинство разработчиков делает не greenfield проекты, а подкручивает огромные легаси системы. И в таких задачах реального мира ускорение в генерации кода практически никогда не ускоряет получение реального результата, так как бутылочные горлышки вообще не там.
👉AI упрощает работу программиста
Вы обмениваете ясность на скорость. Фичи генерируются быстро, но в голове программиста не выстраивается ментальная карта того, что и как в проекте работает. Поддерживать его становится сложнее, дебажить тоже, и со временем это только накапливается.
Главный вывод, к которому постепенно подходит индустрия – AI нужно уметь держать на коротком поводке, использовать его с очень конкретной целью, и избегать магического мышления. Опыт инструментом не заменить.
Хабр
Карьера вайб-кодера — это тупик
Сразу расставлю все точки над «и»: LLM полезны. Вопрос не в том, могут ли LLM писать код, они на это способны. Вопрос в том, почему вайб-кодинг может оказаться вашей худшей карьерной инвестицией. Я...
2👍83❤18👎7
Бизнесу (не) нужен ML
Хайп в сторону. Разбираемся в насущном вопросе с анализом успешных кейсов и рабочих инструментов.
Команда Selectel собрала все нужное в новом медиа ML Impact:
- как технологии Edge AI трансформируют бизнес в 2025 году,
- как не переплатить за автоматизацию,
- как подготовить бизнес к запуску ML-проекта (гайд!)
Переходите по ссылке, чтобы внедрить ИИ в бизнес осознанно и без рисков: https://slc.tl/fis4c
Реклама. АО «Селектел», ИНН 7810962785, ERID: 2VtzqvL6Ax1
Хайп в сторону. Разбираемся в насущном вопросе с анализом успешных кейсов и рабочих инструментов.
Команда Selectel собрала все нужное в новом медиа ML Impact:
- как технологии Edge AI трансформируют бизнес в 2025 году,
- как не переплатить за автоматизацию,
- как подготовить бизнес к запуску ML-проекта (гайд!)
Переходите по ссылке, чтобы внедрить ИИ в бизнес осознанно и без рисков: https://slc.tl/fis4c
Реклама. АО «Селектел», ИНН 7810962785, ERID: 2VtzqvL6Ax1
2👎10👍3
Быстрые и долгие проекты
Первый список вы, скорее всего, когда-то уже видели – это перечень амбициозных проектов, которые были сделаны удивительно быстро для своего масштаба. Например, Unix, написанный за три недели, JavaScript за 10 дней, или iPod, на весь цикл от идеи до продакшна которого ушло всего 290 дней.
Второй список еще интереснее – он про проекты, на которые человечеству потребовалось очень много времени: детектор гравитационных волн, на который ушло почти 50 лет, доказательство теоремы Ферма, или продолжительные исследования того, как разные жизненные факторы влияют на здоровье сердца.
Первый список вы, скорее всего, когда-то уже видели – это перечень амбициозных проектов, которые были сделаны удивительно быстро для своего масштаба. Например, Unix, написанный за три недели, JavaScript за 10 дней, или iPod, на весь цикл от идеи до продакшна которого ушло всего 290 дней.
Второй список еще интереснее – он про проекты, на которые человечеству потребовалось очень много времени: детектор гравитационных волн, на который ушло почти 50 лет, доказательство теоремы Ферма, или продолжительные исследования того, как разные жизненные факторы влияют на здоровье сердца.
1❤26👍3
Про stack ranking
Вы наверное слышали про отвратительную практику, иногда встречающуюся в корпорациях – stack ranking. В чем суть – вы должны отсортировать всех своих сотрудников по перфомансу по бакетам по какой-то спущенной сверху эвристике. Например, в Microsoft долгое время в каждой команде всегда надо было выделять 10% худших сотрудников, даже если на деле все работали примерно одинаково. Обычно эта система влияет на распределение бонусов, а иногда служит и основой для сокращений.
Так вот, в нашем втором канале "Тимлид не спит" Александр Орлов из Стратоплана разбирает кейс, в котором тимлид впервые столкнулся с такой системой и ему надо выбрать кого-то худшего в команде, в которой все молодцы.
Вы наверное слышали про отвратительную практику, иногда встречающуюся в корпорациях – stack ranking. В чем суть – вы должны отсортировать всех своих сотрудников по перфомансу по бакетам по какой-то спущенной сверху эвристике. Например, в Microsoft долгое время в каждой команде всегда надо было выделять 10% худших сотрудников, даже если на деле все работали примерно одинаково. Обычно эта система влияет на распределение бонусов, а иногда служит и основой для сокращений.
Так вот, в нашем втором канале "Тимлид не спит" Александр Орлов из Стратоплана разбирает кейс, в котором тимлид впервые столкнулся с такой системой и ему надо выбрать кого-то худшего в команде, в которой все молодцы.
Telegram
Тимлид не спит: разбор менеджерских болей, вопросов и кейсов
Разбираем новый кейс
👉 Кейс #18. Кого назначить худшим?
К нам пришел новый СЕО, и первое, что сделал – ввел stack ranking. Теперь в каждой команде по итогам года надо выделить 10% звезд, 80% середнячков и 10% лоу-пкрформеров. Увольнять лоу-перформеров сразу…
👉 Кейс #18. Кого назначить худшим?
К нам пришел новый СЕО, и первое, что сделал – ввел stack ranking. Теперь в каждой команде по итогам года надо выделить 10% звезд, 80% середнячков и 10% лоу-пкрформеров. Увольнять лоу-перформеров сразу…
👎10👍8🔥3❤1
Мы входим в эпоху быстрой моды
На MBA программах всегда разбирается кейс того, как Zara создала новый рынок быстрой моды. Это стало возможным благодаря нескольким радикальным изменениям в цепочке поставок, которые позволили существенно сократить время на разработку и доставку до конечных точек нового товара.
Мы стремительно приближаемся к аналогичной ситуации, но в мире разработки. Условный Lovable дает возможность очень быстро получать что-то рабочее, но довольно низкого качества, как бы это качество мы не измеряли. Многие из таких сервисов, уже получив пользователей, не проходят столкновения с реальностью – данные утекают, нагрузка не держится, пользовательский опыт разваливается. И мы получаем рынок софта, который плохо справляется со своими задачами, а разработчики которого, в попытке залатать дыры, делают его еще более сложным и хрупким, так как не умеют в инженерию и в дизайн систем. Короче, будущее выглядит не очень радостным!
На MBA программах всегда разбирается кейс того, как Zara создала новый рынок быстрой моды. Это стало возможным благодаря нескольким радикальным изменениям в цепочке поставок, которые позволили существенно сократить время на разработку и доставку до конечных точек нового товара.
Мы стремительно приближаемся к аналогичной ситуации, но в мире разработки. Условный Lovable дает возможность очень быстро получать что-то рабочее, но довольно низкого качества, как бы это качество мы не измеряли. Многие из таких сервисов, уже получив пользователей, не проходят столкновения с реальностью – данные утекают, нагрузка не держится, пользовательский опыт разваливается. И мы получаем рынок софта, который плохо справляется со своими задачами, а разработчики которого, в попытке залатать дыры, делают его еще более сложным и хрупким, так как не умеют в инженерию и в дизайн систем. Короче, будущее выглядит не очень радостным!
👍11❤3👎1
Запускаем новое исследование тимлидов
Тимлиды в 2025 году стали страдать, кажется, еще сильнее, чем раньше. К постоянно сменяющим друг друга кризисам, мертвому рынку найма, некомпетентным топам и периодическим сокращениям добавилось повсеместное давление на внедрение AI даже там, где этого не требуется.
Так вот, если вы руководите командами разработки, принимайте участие в новом исследовании тимлидов от DevCrowd. Это поможет вам сравнить свою роль с коллегами по индустрии, перенять полезные навыки и практики, узнать, как решаются похожие на ваши проблемы, ну и просто помочь собрать классные факты!
Результаты будут в открытом доступе где-то в конце сентября. На заполнение уходит минут 10-15, так что можете заварить себе вкусный кофе, расслабиться, и поделиться своими мыслями.
А если хотите посмотреть, как выглядели результаты в прошлом году – вам сюда.
Тимлиды в 2025 году стали страдать, кажется, еще сильнее, чем раньше. К постоянно сменяющим друг друга кризисам, мертвому рынку найма, некомпетентным топам и периодическим сокращениям добавилось повсеместное давление на внедрение AI даже там, где этого не требуется.
Так вот, если вы руководите командами разработки, принимайте участие в новом исследовании тимлидов от DevCrowd. Это поможет вам сравнить свою роль с коллегами по индустрии, перенять полезные навыки и практики, узнать, как решаются похожие на ваши проблемы, ну и просто помочь собрать классные факты!
Результаты будут в открытом доступе где-то в конце сентября. На заполнение уходит минут 10-15, так что можете заварить себе вкусный кофе, расслабиться, и поделиться своими мыслями.
А если хотите посмотреть, как выглядели результаты в прошлом году – вам сюда.
❤15👍5👎1🔥1
Как AI влияет на безопасность
В продолжение вчерашней темы о том, что нас ждет темная эра софта. Исследователи из Veracode взяли 100 разных LLM, дали им много разных задач по генерации кода, а затем прогнали по результатам свой SAST сканер. Вот что получилось:
👉Только 55% решенных задач не содержали ни одной выявленной уязвимости.
👉Несмотря на то, что более новые модели лучше справляются с генерацией кода, уязвимостей в нем меньше не становится.
👉Не зависит количество найденных уязвимостей и от размера модели.
👉Результаты по Python, JavaScript, C# показали примерно одинаковые результаты, а вот с Java все намного хуже.
В продолжение вчерашней темы о том, что нас ждет темная эра софта. Исследователи из Veracode взяли 100 разных LLM, дали им много разных задач по генерации кода, а затем прогнали по результатам свой SAST сканер. Вот что получилось:
👉Только 55% решенных задач не содержали ни одной выявленной уязвимости.
👉Несмотря на то, что более новые модели лучше справляются с генерацией кода, уязвимостей в нем меньше не становится.
👉Не зависит количество найденных уязвимостей и от размера модели.
👉Результаты по Python, JavaScript, C# показали примерно одинаковые результаты, а вот с Java все намного хуже.
🔥9
Media is too big
VIEW IN TELEGRAM
Может показаться, что это типичный корпоративный ролик… Если не досмотреть его до конца 🚀
Команда AvitoTech собрала все клише корпоративных видео в одном месте… Чтобы показать на контрасте, какая атмосфера действительно существует в их офисе и на каких принципах построена инженерная культура в Авито.
После просмотра точно будет «Продано!». А если хотите подробнее про их принципы и команду в целом, то вам сюда.
Команда AvitoTech собрала все клише корпоративных видео в одном месте… Чтобы показать на контрасте, какая атмосфера действительно существует в их офисе и на каких принципах построена инженерная культура в Авито.
После просмотра точно будет «Продано!». А если хотите подробнее про их принципы и команду в целом, то вам сюда.
Please open Telegram to view this post
VIEW IN TELEGRAM
👎64👍9🔥4❤1
Как стресс влияет на прохождение интервью
Группа рисерчеров из Microsoft попробовали понять, как стресс интервью сказывается на способностях решать технические задачи. Для этого они просили участников решать одни и те же задачи в двух условиях – кто-то делал это в одиночку в комнате на доске, а кто-то – под присмотром собеседующего, с требованием рассуждать вслух.
Собеседуемые, которые решали задачу перед собеседующим, в среднем справились в два раза хуже чем те, кто делал это в одиночку!
Что интересно – если смотреть не на среднее, а на распределение результатов, то видно, что на этот результат влияет группа людей, кому лайвкодинг дается особенно тяжело. И в то же время есть люди, кто, несмотря на стресс, справился даже лучше чем группа, решавшая задачи в одиночку.
Поэтому не стоит удивляться тому, что кандидаты с огромным опытом за плечами могут проваливать лайвкодинг, и сразу же записывать их в шарлатаны.
Группа рисерчеров из Microsoft попробовали понять, как стресс интервью сказывается на способностях решать технические задачи. Для этого они просили участников решать одни и те же задачи в двух условиях – кто-то делал это в одиночку в комнате на доске, а кто-то – под присмотром собеседующего, с требованием рассуждать вслух.
Собеседуемые, которые решали задачу перед собеседующим, в среднем справились в два раза хуже чем те, кто делал это в одиночку!
Что интересно – если смотреть не на среднее, а на распределение результатов, то видно, что на этот результат влияет группа людей, кому лайвкодинг дается особенно тяжело. И в то же время есть люди, кто, несмотря на стресс, справился даже лучше чем группа, решавшая задачи в одиночку.
Поэтому не стоит удивляться тому, что кандидаты с огромным опытом за плечами могут проваливать лайвкодинг, и сразу же записывать их в шарлатаны.
❤29👍13🔥5
Результаты опроса Stack Overflow за 2025
Во вполне вероятной смерти Stack Overflow в ближайшие годы мне больше всего жаль будет потерять их ежегодные опросы, которые дают репрезентативный и очень полезный срез индустрии. Вот несколько интересных фактов за этот год:
🧑💻Про разработчиков:
👉Только четверть разработчиков счастливы на своей работе, но в прошлом году таких было еще меньше.
👉Больше всего на счастье влияют автономность, хорошая компенсация и решение реально важных проблем.
👉Основные причины по которым разработчики теряют интерес к инструментам: проблемы с приватностью, цена, наличие альтернатив получше. А вот отсутствие AI ни для кого не является проблемой.
💻Про технологии:
👉Самый быстрорастущий язык, ожидаемо, Python, причем на невероятные 7%. Среди баз данных быстрее всего растет Redis.
👉В списке самых любимых языков новичок – Gleam. Обязательно про него выпуск Подлодки скоро запишем!
🤖Про AI:
👉В прошлом году к AI относились на 10% позитивнее, чем в этом. Что контринтуитивно – профессиональные разработчики ценят AI больше, чем начинающие.
👉84% опрошенных используют AI в своей работе.
👉Чаще всего AI используют для поиска и генерации контента, а реже всего – для деплоя, мониторинга, планирования проекта.
👉AI агенты все еще не стали мейнстримом, только треть опрошенных их как-то использует. Из них 70% считают, что их продуктивность выросла.
Во вполне вероятной смерти Stack Overflow в ближайшие годы мне больше всего жаль будет потерять их ежегодные опросы, которые дают репрезентативный и очень полезный срез индустрии. Вот несколько интересных фактов за этот год:
🧑💻Про разработчиков:
👉Только четверть разработчиков счастливы на своей работе, но в прошлом году таких было еще меньше.
👉Больше всего на счастье влияют автономность, хорошая компенсация и решение реально важных проблем.
👉Основные причины по которым разработчики теряют интерес к инструментам: проблемы с приватностью, цена, наличие альтернатив получше. А вот отсутствие AI ни для кого не является проблемой.
💻Про технологии:
👉Самый быстрорастущий язык, ожидаемо, Python, причем на невероятные 7%. Среди баз данных быстрее всего растет Redis.
👉В списке самых любимых языков новичок – Gleam. Обязательно про него выпуск Подлодки скоро запишем!
🤖Про AI:
👉В прошлом году к AI относились на 10% позитивнее, чем в этом. Что контринтуитивно – профессиональные разработчики ценят AI больше, чем начинающие.
👉84% опрошенных используют AI в своей работе.
👉Чаще всего AI используют для поиска и генерации контента, а реже всего – для деплоя, мониторинга, планирования проекта.
👉AI агенты все еще не стали мейнстримом, только треть опрошенных их как-то использует. Из них 70% считают, что их продуктивность выросла.
survey.stackoverflow.co
2025 Stack Overflow Developer Survey
The 2025 Developer Survey is the definitive report on the state of software development. In its fifteenth year, Stack Overflow received over 49,000+ responses from 177 countries across 62 questions focused on 314 different technologies, including new focus…
1👍12🔥10❤2
Как бороться с лишними созвонами
👉По-максимуму переходить на асинхронные коммуникации вместо встреч. В первую очередь научиться работать с таск-трекером – обсуждать там все задачи, следить за прогрессом важных для вас задач, ставить отложенные напоминания. Второй полезный инструмент – запись коротких видео с объяснениями в Loom, которые можно посмотреть потом в любой момент.
👉Оптимизировать количество и формат встреч. Во-первых, избавиться от мало полезных – обсуждение статуса задач, созвоны уточнить что-то, дать апдейт по проекту. Во-вторых, сокращать длительность нужных встреч, и хорошо к ним готовиться – четко формулировать вопрос, который хотите решить, и заранее делиться повесткой. В-третьих, не звать всех подряд, исключать наблюдателей, включать только активных участников.
👉Не стесняться предлагать отменять чужие встречи, которые не проходят через эти правила, и предлагать другие форматы для них.
👉По-максимуму переходить на асинхронные коммуникации вместо встреч. В первую очередь научиться работать с таск-трекером – обсуждать там все задачи, следить за прогрессом важных для вас задач, ставить отложенные напоминания. Второй полезный инструмент – запись коротких видео с объяснениями в Loom, которые можно посмотреть потом в любой момент.
👉Оптимизировать количество и формат встреч. Во-первых, избавиться от мало полезных – обсуждение статуса задач, созвоны уточнить что-то, дать апдейт по проекту. Во-вторых, сокращать длительность нужных встреч, и хорошо к ним готовиться – четко формулировать вопрос, который хотите решить, и заранее делиться повесткой. В-третьих, не звать всех подряд, исключать наблюдателей, включать только активных участников.
👉Не стесняться предлагать отменять чужие встречи, которые не проходят через эти правила, и предлагать другие форматы для них.
Хабр
Если у вас больше 5 созвонов в день — пора увольняться. Или начать делать это
10:00 — дейлик. 11:00 — синк по новой фиче. 13:00 — демо. 15:00 — созвон «на пару минут». 16:00 — еще один. 17:30 — ретро. 18:30 — теперь можно поработать. Так выглядит обычный день в...
👍25❤13👎1