Открыть список
Как стать автором
Обновить

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

Блог компании VDSina.ruПрограммированиеУправление проектамиУправление персоналомКарьера в IT-индустрии
Перевод
Всего голосов 40: ↑32 и ↓8 +24
Просмотры16.8KКомментарии 21

Комментарии 21

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

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

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

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

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

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

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

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

Мне кажется сначала было бы неплохо объяснить что такое "техлид" и чем он отличается от тимлида или архитекта с точки зрения автора статьи.

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

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


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

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

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

Ну если мы возьмём именно обучение менеджменту и например ВО, то там часто идёт сам менеджемент и надо выбирать направление в котором потом хочешь работать и немного изучать и его.


To есть например те же Information Systems или Business informatics это как раз такое обучение менеджменту в ИТ.


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

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

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

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

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

Ну я бы сказал что это тот человек, который [в команде] имеет последнее слово в случае спорных ситуаций :)

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

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

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Информация

Дата основания
Местоположение
Россия
Сайт
vdsina.ru
Численность
11–30 человек
Дата регистрации
Представитель
Mikhail

Блог на Хабре