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

[Oz_Alex]

Из личного опыта — последний техлид (из-за которого я уволился и указал это в причине) имел своё представление о жизненных стадиях софта и стандартная схема (dev, test, staging, prod) его не устраивала. Он придумал свой жизненный цикл и внедрил его — preprod, nonprod и prod. Угадайте, что ближе к проду?

Ответ

preprod = dev
nonprod = staging

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

В Джире все тикеты имели только заголовок, без какого-либо текста внутри — так было принято: если ты пропустил планирование спринта, значит ты обречён две недели отвлекать других вопросами «что это за тикет?». Если в тикете написать в чём заключается проблема и что, собственно, нужно делать — техлид в личке пишет: «Ты же был на планировании, зачем это писать? Ты что, не помнишь о чём мы говорили? Я тебе напомню — то и это».

В общем всё было спроектировано так, чтобы без обращения к техлиду никто не мог разобраться как тут что работает и что вообще делать. Ему было 54, он работал по контракту и как я понял — это была его подстраховка для продления контракта снова и снова.
Как разработчик — он был весьма неплох. Как менеджер — полный отстой.

[TheCluster]

В общем всё было спроектировано так, чтобы без обращения к техлиду никто не мог разобраться как тут что работает и что вообще делать. Ему было 54, он работал по контракту и как я понял — это была его подстраховка для продления контракта снова и снова.

Как менеджер — полный отстой

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

[DenisTrunin]

У вас хоть prod был. Я работал на проекте где было 5 окружений и они назывались именами планет. т.е. фраза — «установлена ли у нас эта модификация на юпитере» поначалу приводила в ступор. Хотя через полгода привыкаешь :)

[theuser]

без какого-либо текста внутри — так было принято

Палкой по горбу бы дал.
У меня ситуация наоборот, индусские QA создавая тикеты не удосуживаются даже написать где конкретно баг произошёл и степы для воспроизведения.
Приходится заставлять писать подробно, привлекая их лида

[shai_hulud]

Job Saving Driven Development впролне себе рабочая методология и для менеджеров тоже.

[Skynet2034]

Ага, особенно в сочетании с Deadline Driven Development.

[sogarkov]

У каждого вырабатывается своя практика, но чем старше становишься, тем отчетливее понимаешь, что заниматься надо тем, к чему лежит душа и руки. Не хочешь руководить? Не надо туда лезть. Пусть будет меньше денег (что, часто, ещё под вопросом), зато не заработаешь неврастении, неподъемного стресса и, как следствие, серьёзных проблем со здоровьем. Цель "стать CTO" — это такой антипаттерн, который может стоить очень дорого в долгосрочной перспективе.

[slonopotamus]

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

Скорее всего большинство программистов — это посредственные программисты. И вообще, большинство людей — это посредственные люди. Было бы очень странно если бы из них получались не посредственные техлиды, а какие-то другие.

И причём здесь "чрезвычайно амбициозный и активный" Боб решительно непонятно. Извините, но я не верю что он является типичным представителем большинства программистов.

[omxela]

Вы бескомпромиссны (на мой взгляд). И не уловили проблему. А она имеет общий характер. При чем тут программирование? Я — научный работник. Это же тема стара, как мир: почему из хороших ученых не всегда (а это мягко сказано) получаются хорошие руководители? Завлабы, например, или директорА институтов. И ответ известен: это просто разные профессии. От слова совсем. И профессиональные лифты у них разные. Должны быть. Скажем, на Физтехе есть факультет научного менеджмента. Можно придираться, но он есть.

[Viacheslav01]

О это еще ничего, а вот какие получаются заведующие ДС из воспитателей это прям вообще огонь)

[vmkazakoff]

С одной стороны я полностью согласен. С другой — ну вот есть у нас руководитель который вырос не из специалистов (или из плохих и был выскочкой вечной) — это что, лучше?) Я смотрю на некоторые наши… эммм… отрасли. И понимаю что всё-таки нужен человек который понимает как все устроено, а не только "руками водить"...

[sshikov]

Давайте все-таки будем честны: автор, т.е. Zachary Minott, ничего не знает про большинство программистов. Он эту фразу выдумал, чтобы было солиднее. Все что у него есть (да и у меня в общем тоже, как и у всех нас) это личный опыт. Исследования он не проводил, данных по ним не привел. Ему так кажется.

Сколько вы встречали в жизни техлидов, которые выросли из программистов, и стали посредственными? Двоих? Пятерых? Десятерых? Я могу припомнить примерно пятерых — за двадцать лет. Никто из них не был посредственным. Можно ли такой опыт вообще куда-то пытаться обобщать?

[hellamps]

Я так и не понял из статьи, почему?

[qyix7z]

Почему большинство [подставить любую профессию] оказываются посредственными [руководителями]
Ответ простой: это другая специализация.
Из того, что некто на отлично справляется со своей работой, не следует, что он может организовать других людей выполнять эту работу даже на удовлетворительно.

[kasiopei]

Какой вообще смысл вкладывается в слово лидер? Начальник или высокомотивированный харизмат с высокой квалификацией? Если второе, то все сразу редко бывает.

[Lee_Fun]

Мне кажется в статье не совсем верно понимается роль именно техлида. Это не тимлид. И техлид может и должен быть из самых сильных разработчиков. Судя по всему в статье рассмотрен случай когда техлид тянет роль тимлида, поскольку того тупо нет.

[bitaraf]

программмрование это психология тормоза

[z1024]

А зачем мне готовится к роли тимлида если я и не хочу им быть? Прослойкой между командой и начальством? Бесконечные митинги, оправдываться за факапы людей, которых не ты выбирал, всякая нудная возня и бюрократия практически за те же деньги? Не не, спасиба.