Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 57
Если команда более-менее ровная по уровню квалификации и квалификация достаточно высокая, то ваш Серега поступал правильно. Он доверял разработчикам и защищал их от внешних воздействий. Результат очевидный. Андрей, судя по всему, перфекционист без меры. С командой из слабых разработчиков это в общем-то и неплохо. Без дубины тут порой не обойтись. Но с сильными разработчиками это метод работает плохо. Они, как говорится, и сами с усами. Да, можно и нужно поправить, обсудить, убедить в конце-концов, но ломать через коленку и принуждать делать исключительно так, а не иначе - рано или поздно приводит к выгоранию, раздражению и уходу
Плот твист: заметку написал Серёга
Плот-твист: заметку написал Андрей, а Серёга - его раздвоение личности, возникшее из-за дикого истощения. И первое правило клуба: рост PR - это показатель эффективности, а вовсе не признак снижения качества первоначальной реализации задач.
Если бы статью писал Серёга, он бы делегировал написание мне )
Еще было бы интересно увидеть метрики количества багов пролезших при старом и новом лидах, и количество переделок / рефакторингов / фиксов в кода, написанного опять же при старом и новом лидах. Еще один неучтенный фактор - новому лиду вы достались в состоянии "мы такие жертвы лида" - но подтянутые в профессиональном плане.
Есть такое замечательное высказывание - "Ребёнок – гость в твоём доме. Накорми, выучи и отпусти". Менее опытный коллега, которого ты взялся обучать, такой же гость в твоём доме. Нужно вовремя его "отпустить". Иначе вреда от твоего менторства будет больше, чем пользы. Гиперопека так же вредна, как и полное невнимание.
И есть ещё одно замечательное высказывание - "На ошибках учатся". Дай возможность своему ученику ошибаться. Иначе он ничему не научится.
По моим данным — команда без кодящего тимлида выдаёт на 41% больше
Больше не значит лучше
Он сел и за полтора часа переписал 70% моего кода. Объективно стало лучше. И абсолютно чужим
Зато вы научились новому, верно? Ведь научились, да? Теперь вы тоже сможете делать такого класса задачи не за три дня, а за один (ну, для начала) - то есть ваша эффективность выросла в три раза.
Эффективность, то, может, и выросла. Только мотивация упала. А она важнее.
Нужно каждый день тянуть лямку, можно и плохо, и медленно, и неэффективно. А не пару раз в год - зато супер эффективно!
Только мотивация упала.
Если у вас упала мотивация от того, что вам на практике принесли новое знание, то наверное вы не в той профессии. Тем более, насколько понимаю, первый тимлид не оскорблял, не обзывал дураком и вообще всячески берег самоощущение автора
Именно. Работать без мотивации это как ехать идеально правильно, но с полупустым баком.
Судя по описанию автора, команда там была из необучаемых "инженеров". Т.е. им показывают как надо/правильно/лучше. Объясняют принципы, методики, бестпрактисы, приводят ссылки на материалы и исследования, буквально вкладывают разжеванный опыт индустрии в мозг ... но у них не откладывается ни-че-го. Годами. Ну ок.
Я тоже не пишу. И не собираюсь. В редких случаях, когда вообще нет ресурса, помогаю в проектировании бд, в аналитике, написание контрактов. Могу подсказать по архитектуре. Но все - именно как исключение из обычного рабочего процесса. Есть другие активности, которые не позволяют серьезно и вдумчиво погружаться в код.
Мало что погружаться, так ещё и нет предсказуемости в сроках
"Тимлид должен кодить" - это не про то, что он должен всё ревьювить круче всех, обучать и быть параллельно техлидом, а про то, что он должен иметь адекватное представление о рабочих процессах, проблемах и подходах к их решению. Если не кодить, то года за 3 можно сильно оторваться от реальности. Просто вспомните, как все писали код 3 года назад (без LLM), как пишут сейчас, и как это повлияло на рабочие процессы - и представьте, что тимлид всё это пропустил, потому что вместо того, чтобы лично пощупать LLM он ходил на созвоны и отбивал фичереквесты…
Жёсткие ревью PR с десятками замечаний и переделкой по 4 раза могут быть крайне полезны для развития и обучения команды, и давать кратный рост производительности команды. А могут душить инициативу команды и вести к её выгоранию и увольнению. Это вопрос софт-скиллов того, кто такие ревью делает - он должен учитывать много факторов: есть ли бизнес-возможность отложить мерж этого PR ради обучения, есть ли время у самого ревьювера заниматься обучением во время этого ревью, готов ли автор PR обучаться прямо в рамках работы над этим PR… ну и сдерживать собственную вкусовщину, потому что требовать чтобы другие писали ровно как ты - бессмысленно и вредно.
Доверие команде "не глядя" может идеально работать в сильной команде и полностью провалиться в слабой (равно как и в команде увлёкшейся вайб-кодингом и пользующейся отсутствием жёстких ревью чтобы быстро мержить мусор выдаваемый LLM).
Иными словами, как лучше - жёсткие ревью или доверие команде не глядя в код - сильно зависит от конкретной команды. Но, в любом случае, тимлид должен кодить. ;-)
А я понимаю Андрея и его цели. Думаю, что он хотел понятную и управляемую систему без накопленного технического долга. По крайней мере, вот эта фраза об этом говорит:
Объективно стало лучше
Да, он тормозил разработку, но у этого была причина - недопущение экспоненциального роста сложности системы. Да и 31% отклонённых PR я бы не назвал гейткипом.
Вы можете и не заметить дальнейшего ухудшения процессов, ориентируясь на PR. PR, как и строки кода, ни о чём не говорят. Сказать может лишь сложность выполнения новой неожиданной задачи. Только метрику такую ещё не придумали, чтобы измерять эффективность выполнения новых неожиданных задач. Потому что они новые и неожиданные.
Всё верно, только одновременно с этим ещё крайне важно не убивать мотивацию команды. Иначе можно прийти к понятной и управляемой системе с единственным разработчиком в команде, что само по себе сильно замедлит разработку.
Тут все сложнее. Я - такой Андрей (только в собственном бизнесе и меня не уволить).
Команда и правда демотивирована. Но я экспериментировал и на несколько месяцев отпускал поводья. Команда встаёт колом просто. Какое-то время по инерции двигаются, потом замирают.
А когда сам - оно растет и развивается. А так, как технический долг не копится, даже спустя несколько лет мне не сложно одному все писать за всех.
Команда сегодня почти уже не нужна. Всегда код пишут 1-2 самых сильных, а остальные - обуза.
Это порождает другую проблему, bus factor, но пусканием под автобус Андрея она не решается.
А как решается - сам не знаю...
Но я экспериментировал и на несколько месяцев отпускал поводья. Команда встаёт колом просто.
Тут одно из двух: либо команда в принципе не способна самостоятельно работать, либо им это отбил текущий стиль управления. Первое встречается редко, это должно было либо "повезти" при найме, либо команда прошла многолетний "отрицательный отбор", когда способные на самостоятельную работу просто не выдерживали и увольнялись, а оставались те, кому норм. В первом случае придётся менять всю команду, во втором помимо самоустранения необходимо нанять нового сильного тимлида практикующего другой стиль управления - если, конечно, нужно чтобы команда начала работать самостоятельно.
Команда сегодня почти уже не нужна. Всегда код пишут 1-2 самых сильных, а остальные - обуза.
Пока продукт небольшой - так было всегда. А вот когда продукт начинает активно развиваться, то 1-2 сильных разработчиков резко перестаёт хватать. Да, сегодня, если эти разработчики успешно освоят LLM, то они смогут выдавать больше результата (того же качества) в месяц. Но больше - всё-таки не в разы, по разным оценкам это 20%+. Потому что всё-равно нужно тщательно продумывать архитектуру, постановку задач и внимательно ревьювить код выдаваемый LLM. Объективно можно рассчитывать максимум на то, что команда из 2-х сильных разработчиков будет выдавать результат как будто их там таких 3, а не 2.
Помимо роста продукта нужда в команде обычно возникала ещё и потому, что во-первых не всем удавалось нанять тех самых 1-2 реально сильных, и во-вторых для защиты от bus factor. И вот это пока никуда не делось. Без контроля сильного разработчика LLM будет выдавать мусор очень среднего уровня, и bus factor тоже никуда не делся.
Если, как в Вашем случае, сильный разработчик одновременно владелец компании, и продукт достаточно небольшой чтобы он лично успевал его развивать, то да, команда особо не нужна (особенно если перекинуть всю рутину на LLM). Только вот есть проблема: шансы что бизнес будет развиваться при таком подходе стремятся к нулю. Потому что владелец либо будет тратит свои силы на бизнес, либо на код. Если он будет заниматься бизнесом, то код придётся писать кому-то другому, плюс резко увеличивается шанс, что с развитием бизнеса понадобится больше (сильных) разработчиков чтобы успевать развивать продукт. А если он будет заниматься кодом, то вполне реально поддерживать текущий уровень бизнеса, но не более того.
Тут одно из двух: либо команда в принципе не способна самостоятельно работать, либо им это отбил текущий стиль управления.
Что-то как-то вывод похож на ложную дихотомию. Неужели не допускаете промежуточных вариантов?
Я допускаю. Допускаю, что у наёмных сотрудников есть семья, ипотека, свои проблемы и радости. И работа у них далеко не в первых строках приоритетов. Они могут быть замечательными и честными людьми. Но ответьте на вопрос: а у них будет выше зарплата, если они начнут работать больше?
А если будут работать меньше, будет ли у них снижаться уровень стресса? А что им даёт устойчивость и поддержание низкой сложности проекта? Они будут меньше получать, если проект станет сложнее?
Собственники замотивированы в решениях, влияющих на долгосрок. Есть отдельная категория наёмных сотрудников, которые действительно думают о долгосрочных последствиях и очень ответственно относятся к работе. Но это скорее исключение.
Разные команды могут быть эффективны в разных конфигурациях. Одни раскрываются, когда все синьеры и плоская структура. Другие – сильный лид + много рабочих рук. Довелось как-то поработать в диджитале, там команда человек на 30–40 разрабы с менеджерами примерно 1:1 количественно, зато QA не существовало даже как понятия. Эта роль была размазана по всем участникам.
К чему это я? В статье, мне кажется, описан кейс, когда команде поменяли лида на ПМ и команда поехала быстрее. А вся интрига в том, что шильдик на позиции поменять забыли. И изменения, следовательно, потребовали больше времени на осознание сути произошедшего.
Хороший тимлид — не обязательно лучший инженер. Иногда это тот, кто даёт инженерам спокойно работать. Банально звучит, на практике — редкость.
Это называется не тимлид а менеджер. А если он менеджер, то все-равно должен быть старший от разработки, можно называть как угодно, хоть ведущий разраб хоть техлид, иначе однажды команда просто разосрется из за природы разных мнений и опыта.
По моим данным — команда без кодящего тимлида выдаёт на 41% больше. Может, мой случай — исключение, и мне просто повезло с Серёгой. Но мне кажется, мы неправильно понимаем, что такое лидерство в разработке.
Два сеньора с противоположными точками зрения и тимлид который 3 года не кодит...
Поздравляем! Партия вами довольна! Вы получаете повышение: держите своя кошка-жена и миска риса!
Всем бы найти такого Серёгу) Рад, что есть такой мощный сотрудник😁
У нас тоже есть такой, только имя его — Claud Code :)
Как вам удалось получать отчеты от тимлида?
Ваш тимлид пишет код? Помогает это команде или мешает?
А можно пофантазировать с точки зрения программиста, который никогда не работал в команде? По советскому принципу: «Если бы я был директором!»?
Разрабатывая и внедряя учетные программы на производственных предприятиях, которые кормили меня двадцать лет, я иногда задумывался над тем, а как бы я делал их в команде?
Особенно ярко эти мысли стали возникать на фоне моей обучающей (иностранным языкам) программы «L'école», о которой я писал в своих статьях, здесь. Там я себе чуть мозги не сломал, пока не довел её до, более-менее, рабочего состояния. Теперь вот решил разобраться, а как ее можно сделать коллективно?
В итоге, пришел к мнению, что прототип программы должен разрабатывать архитектор программы. Это должен быть работающий минимальный код, в котором весь потенциальный функционал реализован в виде формальных классов – модулей. В данном случае я имею в виду оконные приложения на С++.
Все формальные классы представлены своими публичными функциями, которые ничего не возвращают (обмен данными происходит через их параметры), за исключением обработчиков сообщений. Те возвращают стандартные значения LRESULT (TRUE либо FALSE), но, как и все остальные публичные функции имеют пустые тела.
Приватные части автономных классов (на уровне файлов это *.h и *.cpp модули) находятся в компетенции членов команды.
Далее, архитектор программы фиксирует вызовы формальных публичных функций в «модуле управления» (для оконных интерфейсов это, как правило, обработчики класса типа CMainFrame либо CMainWindow). Но, поскольку, эти функции – пустые, то их использование никак не проявляется.
На примере моей обучающей программы, основными, независимыми друг от друга модулями, являются: класс для работы с чтением / записью текущего состояния приложения, класс логирования, классы для работы с графикой, текстом (отображение и редактирование), звуком и данными, классы вспомогательных окон («О программе», «Помощь», «Настройка» и прочее) и т.д. и т.п.
Для всех этих классов архитектор дает их формальную реализацию. Затем раздает копии своего проекта всем членам команды и говорит, кому, какой модуль реализовывать. Такой подход позволяет достаточно просто организовать коллективную работу без использования внешних систем контроля версий, вроде, гита.
Члены команды доводят до ума свои модули и передают их архитектору. Он замещает формальные модули – их полными версиями и тестирует общую реализацию. При необходимости вносит коррективы в работу команды.
При таком подходе члены команды могут работать удаленно и иметь минимальный конфликт интересов, о которых шла речь в статье.
Я даже не знаю, нужен ли, в таком случае, тимлид либо техлид. Наверное, да, для больших проектов. Но, для группы из нескольких программистов, думаю, без последних можно обойтись. В таком случае, архитектор «пишет» код прототипа либо ваяет его по принципу конструктора модулей.
Таким образом, используя модульное программирование либо итерационно-модульное (где предыдущие итерации, собственные для «своего» модуля каждого программиста, фактически являются просто бэкапами), можно, как мне кажется, упростить работу команды. Зато, основная нагрузка ложится на архитектора. А члены команды могут даже работать независимо друг от друга.
Однако, возможность «легко подключить модуль к проекту» (путем простой замены формальной реализации – полной) и «легко отключить модуль от проекта» (соответственно, наоборот, заменяя полную реализацию – формальной), позволяет, со временем, накаливать потенциальные модули для будущих проектов. Что дает возможность быстро создавать новые прототипы для новых проектов, аналогичного типа.
По сути, в идеале, мы получаем этакий конструктор для будущих программ.
Например, у меня есть неопубликованная программа «МедиаТекст» ( http://scholium.webservis.ru/Pics/MediaText.png ).
Вместе, эти две программы, явно, могут иметь общие модули. При этом, в последней используются потоки и опенсорсный видеоплейер, для которых можно создать свою формальную реализацию.
Вот, приведение уже только этих двух программ к общему модульному типу (к ним можно добавить и мою третью программу – загрузчик «MiniDL» для любимых видосиков, которая опубликована здесь), позволит создать хорошую базу прототипов для будущих проектов данного типа задач. После чего можно будет уже спокойно предлагать себя в роли архитектора на похожую работу :) .
Но, даже если программировать только для себя на уровне пет-проектов, то данный подход кажется перспективным, по крайней мере, я перестану забывать программную логику своих давно написанных программ и смогу спокойно модернизировать их до новых версий. Чем и собираюсь заняться, в ближайшее время.
Как-то так.
В компаниях, где я работал, тимлид всегда лидировал продукт\проект, а то, что делал описываемый Андрей - у нас делал техлид. Именно к техлиду обращались тимлид и остальные участники команды по вопросам разработки, планирования загрузки разработчиков, каким-то техническим деталям.
С чего бы тимлиду быть сильным разрабом? - не понимаю... А почему не системным\бизнес аналитиком, или тестировщиком? Эти роли не менее важны, чем собственно кодирование.
Мне кажется, тимлиду не нужно программировать, это менеджерская роль, которая очень часто выполняется Владельцем продукта.
Половина стилистика
а нечего вместо табуляции пробелы использовать
Скрипт писал ночью, продакшн-качество не обещаю. Для разовой аналитики хватило.
А разве LLM-кам имеет значение, в какое время суток по UTC генерировать код?
На Хабре любят хейтить менеджеров, которые «забыли, как кодить».
Не совсем так. Хейтят менеджеров, которые изначально не умели кодить, так как они не понимают сроков, не чувствуют боль разработчика и полностью оторваны от реальности.
К тем, кто умеет кодить, хейта как раз таки нет.
Хороший тимлид — не обязательно лучший инженер.
Лучший инженер называется техлидом или архитектором, а не тимлидом. Тимлид - это работа с людьми и бизнесом, т.е. менеджерская работа.
В некоторых компаниях часто жалеют денег на отдельного менеджера, поэтому заставляют ведущего разработчика сочетать в себе роль техлида и тимлида. Получается дёшево и сердито, но крайне не эффективно.
Если команда маленькая (до 6 человек), то в ней менеджерской работы может быть не так много, поэтому остаток времени человек может посвящать кодингу, т.е. выполнению технических задач.
P.S. Тимлид всегда должен помнить, что работу по кодингу могут выполнить другие люди в группе, а вот менеджерскую работу может выполнить только он, т.к. наделён для этого полномочиями. Так что пока тимлид занимается кодом, менеджерская работа в этот момент не делается, а это очень плохо, т.к. возникает узкое место в работе.
Два часа: как у вас локально фронт запустить? Ещё час: почему npm install ругается на peer dependency? Полчаса: поменял CSS, изменения не появляются.
Кстати, это его факап. Должна быть инструкция для новичка для входа в проект - что где лежит, как запускать локально, как запускать unit-тесты, как пушить, как собирать и разворачивать на сервере.
И раз уж он столкнулся с этой проблемой, то надо ее решить так, чтобы больше с ней не сталкиваться.
Вторую статью подряд "поднял метрики из GitLab... Написал скрипт...". Попробуйте готовые отчеты по репе:// NodeJS
npx assayo
// Python
pipx install assayo
assayo
У нас CTO был, который обожал ходить, особенно какие-то новые фичи, которые он обсуждал напрямую с заказчиком. Качество кода было такое себе, куда лучше было бы, если бы он объяснял задачу и отдавал ее команде. По итогу его теперь нет, и в большей части этого кода никто не разбирается, потому что чем тратить время на понимание хренового кода, проще это переписать с нуля, но переписать тоже сложно, потому что никто в этих решениях не участвовал, и что там из-за чего и почему именно так, никому не понятно. Так что уж лучше бы он не кодил вообще.
У нас тимлид вообще не разработчик. Хорошо живётся, формирует план работ и практически от него не отступаем, все работы сбоку отсекаются если ни что то рискованное. Это нормальная практика - разделение труда называется
Я не пишу код в 95% случаев, но я знаю как это все работает и если команде нужна помощь - они уверены в том, что могут обратиться ко мне за советом.
Некоторые уже отметили в комментариях, очень странная структура команды в вашем примере.
Тимлид и Техлид - это две большие разницы. Если на очень небольших продукте и команде эти роли ещё как-то можно совмещать, то при масштабировании они должны разделяться, иначе либо ревью либо коммуникации и развитие команды будут страдать. Либо ваш всея лид быстро закончится и пострадают оба направления.
Судя по истории:
Андрей всегда был и остался Техлидом. Техлид само собой должен писать код и быть очень близко к продукту, стеку, архитектуре и тех долгу. Автор сам упоминает, что к нему ходят за советом, значит функции Техлида он продолжил выполнять.
Серёга - адекватный Тимлид, который знает продукт настолько, чтобы адекватно общаться со всеми внешними заказчиками. Писать код для этого не требуется, гораздо важнее понимать кто и зачем просит какие фичи, кому что лишний раз стоит объяснить и напомнить и подобное. Все что может составлять техническую проблему (трудоемко, может вызвать клинч, сложно тестировать и т. д. ) - можно взять у команды или того же Техлида.
В общем кажется, что в описанной истории проблема не в практике писать код, а в адекватности разделения обязанностей.
Метрики очень косвенные, в них нет ничего про то, что компании нужно от команды.
Хотелось бы увидеть что-то связанное с доставкой ценности - насколько то что команда делает нужно компании, какого это качества и так далее.
С точки зрения people management ясно что у первого тимлида были недостатки. Люди чувствовали неудовлетворённость и, похоже, он не давал им ошибаться в тех случаях когда можно было бы и давать.
По идее это должно было быть ясно на 1:1 и ретроспективах также это должны были заметить hr при опросах удовлетворенности или каких-то ещё механизмах обратной связи которые должны быть.
С этим вообще непонятно как было. Беседовал ли старый лид с вами просто по ощущениям от работы? А новый беседует?
Про доставку ценности, тут бизнес голосует деньгами. Та же история с демо для инвесторов или отбитая атака безопасников сэкономили компании кучу ресурсов, чего при Андрее могло и не случиться из-за перфекционизма (хотя кто его знает).
Насчёт почему не заметили раньше имхо это ловушка авторитета. Ну банально сложнее жаловаться на технического гуру, который «тратит время на твоё обучение», проще поверить, что это ты сам не тянешь.
Андрей на встречах обсуждал только код и сроки, а Серёга на 1:1 спрашивает про «как тебе работается» и «что мешает».
У меня как-то не сходится - в компании где есть архитектор, новый тимлид говорит что архитектурные решения на разработчиках. Дак может первый тимлид как настоящий инженер защищал чистоту архитектуры, а второй работает на бизнес и kpi? И кайфовую атмосферу в команде) Что косвенно подтверждает ваш график.
Может ли так получиться что с новым тимлидом ваш продукт через пару лет будет с красивым kpi, но по сути представлять огромную кучу грязи?)
Ждём сиквелл через год когда посчитаем среднее время выполнения задач и увидим, что бывают более важные метрики помимо душевного равновесия во время ревью. Система всегда усложняется, бизнес требования каждый раз пытаются проверить текущую кодовую базу на прочность. В какой то момент станет понятно, что кодить просто ужасно больно, а уже будет поздно и на рефакторинг время не выделят. Но в памяти останется крутой Серёга, а не душный Андрей.
А какой ожидаемый срок жизни кода в современном мире? Только не говорите что проектируете ядрену электростанцию или полет на Марс. В 95% это очередная гениальная маркетинговая фича чтобы выкинуть через пол года когда не взлетело. Перфекционизм здесь вреден
Код к одному из серийных изделий был написан в 2017м году. Доработки - до 2020го были выполнены.
Сейчас - производство и косметические правки для стыков с другими системами.
Но перфекционизм даже там был вреден, потому что устройство нужно было выпустить в срок.
Другой программный комплекс писался в середине 00х. Он до сих пор в активной, хоть и не масштабной, разработке.
Команда или нытиков и/или слабых специалистов. Если автор пишет так, что за него надо большую часть переписывать, то даже не знаю, что тут сказать.
Учитывая что скрипт явно нагенерен нейронкой, а автор пишет что "писал скрипт ночью" - сразу возникло сомнение по поводу правдивости всего текста. Хотя может просто неудачный оборот)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Мой тимлид не пишет код 3 года. Почему он — лучший тимлид, с которым я работал