Кривые развития программиста и немного об эффекте Даннинга—Крюгера

Существует два основных пути становления топ-менеджмента в IT-компаниях:

1. Менеджерский — когда менеджер проекта начинает управлять другими менеджерами.
2. Технарский — когда разработчик начинает управлять другими разработчиками и количество управляемого им персонала увеличивается.

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

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

Внимание, спойлер.

1. Все имена — вымышленные
2. Повествование относится в большей степени к заказной разработке
3. Скилы, а в особенности софт скилы, сложно оценить формально, все графики в этой статье являются условными и отражают мое личное мнение

Начало пути программиста

Итак, мы в самом начале пути программиста.

Знакомьтесь: Николай (имя изменено). Николай — молодой программист, он хорошо учится в универе и уже пробовал писать простенькие сайты. Он устроился в студию на должность джуна-фронтендера, его посадили на проект, который уже пишется два года с использованием современного фреймворка Angular версии 1.5. Мальчик Коля не работал с ним, но он увидел знакомый знак доллара, а он уже успел написать пару плагинов для jQuery. Этот факт ободрил Николая, но потом старшие товарищи рассказали ему, что это — совсем не jQuery, и, вообще, тут надо директиву написать, а вот тут два фильтра надо сделать. Николай подавлен, но твердо намерен влиться в этот проект.

И вот уже пролетел год, Николай мастерски пишет директивы и не проходит и дня без нового модуля. Коля на коне, оптимизма ему прибавляет тот факт, что полгода назад к нему на проект подсадили молодого джуна, а тот даже не знает, что такое директива. Щенок! Николай подружился со старшими товарищами, и только 30-летний старик в углу вечно чем-то недоволен.

Собственно, на графиках мы видим технические навыки для проекта и все скилы Николая, что у него есть. Поскольку это его первый проект, то по факту это все, что знает Николай. Через некоторое время он идет к начальству и просит два мешка денег — ведь он мастерски создаёт директивы на проекте, и вообще, он посчитал, что в два раза больше оставляет комментариев в MR, чем тот 30-летний старик. Очевидно, что он — лучше своего тимлида. На это получает вполне резонный отказ и начинает искать новую работу, возможно задумывается о переходе на другой проект или в другую команду. В любом случае он сталкивается с ситуацией, когда только что полученные знания становятся уже неактуальными и ему надо учиться дальше.

Это — первый кризис Николая «Эффект первого проекта».

На новом месте Николаю дают проект на Ангуляре 5, ну он же мастерски пишет директивы! Но там он видит какую-то дичь! Какой ещё TypeScript? Какой RxJs и потоки? Старшие товарищи смеются над ним, а 30-летний старик кидает недобрые взгляды. Я видел огромное количество таких звёздочек и очень много звездопада, когда разработчик понимал, что оказывается-то он ничего ещё не знает! И чем раньше это произойдет, тем лучше. Это называется Эффектом Даннинга — Крюгера — метакогнитивное искажение, которое заключается в том, что люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации.

Джун, который сменил 3-4 проекта за год, для работодателя намного предпочтительней джуна, который год сидел в одиночку на одном проекте, потому что он:

• Объективно оценивает свои знания и навыки
• Постоянно развивается
• Больше общается в коллективе
• Больше понимает цену ошибки, потому что он видел больше дедлайнов и релизов

Коллегам, которые оказались на этом этапе, хочется пожелать следующего:

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

Junior → Middle → Senior

Ну вот прошло еще пару лет и что же мы видим?

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

Сейчас существует разделение на Junior, Middle, Senior. Мидл думает, что для того чтобы стать Синьором, ему надо освоить новый язык программирования и подтянуть матчасть. Это не совсем так. На заре отечественной разработки была должность аналогичная Синьору, называлась она Ведущий программист — такой специалист не просто много знает, но и еще ведет проекты или коллектив. Без соответствующих софт скиллз Синьором не стать.

Николай научился находить подходы ко всем членам команды, он постоянно развивается и развивает остальных. Он повидал уже «звездунов первого проекта», но ему гораздо комфортнее работать с такими же профессионалами, как и он сам. Ведь они понимают, что успех проекта — это успех каждого, а прокол одного члена команды в конечном счете сказывается на всех его участниках.

На этом этапе возможно два пути: быть простым исполнителем, не напрягаться и решать поставленные задачи; второй — развиваться в направлении ведущего программиста, брать на себя ответственность и инициативу.

На этом этапе развития программиста команда и руководство ценят такие его качества:

• Ответственность
• Надежность
• Коммуникабельность
• Проактивность

Куда стоит развиваться?

• Углубленное понимание технологий, которые он использует
• Расширение кругозора
• Брать на себя ответственность за проекты и людей

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

Кризис технологии

В какой-то момент Николай с ужасом осознает, что уже никто не пишет на JS, а большинство его знаний никому не нужны. Вот так наступает кризис технологии. Я застал такой кризис с десктоп-приложениями. Чуть позже просто верстальщики стали никому не нужны — везде стали требоваться фронтендеры. Потом PHP стал резко не моден, и на рынке стали нужны JS-разработчики.

Тут есть три выхода:

1. Переучиваться под новый стек
2. Становиться лучше в старом и хвататься за последние заказы. Тот же Delphi все ещё востребован в узких кругах с огромным количеством legacy кода
3. Уходить в менеджмент при наличии соответствующих навыков

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

TeamLead. Кризис возраста

Ну вот, Николай сменил стек технологий, и вроде бы все хорошо, но мы видим, что новые навыки даются все медленнее, а подрастающее поколение схватывает все быстрее.

Вот тут наступает последний кризис — кризис возраста.

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

Какие тут могут быть варианты:

• Если ты работаешь в продуктовой компании, то, наверное, это для тебя не так критично, и можно оставить все как есть
• Уйти в обучение, например, стать консультантом, архитектором и т.д.
• Таки уйти в менеджмент

Перейдем к кривым

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

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

Технические скилы относительно быстро приобретаются и ещё быстрее забываются и устаревают, если посмотреть со стороны.

Получается, что программист имеет свой пик развития, а потом начинает «стареть», и в какой-то момент ему пора уходить на пенсию?

И да и нет. На самом деле, вместо одного графика можно нарисовать 3 (опять же IMHO, как и значения).

• tech skills — это знания именно в технологии, языке программирования, фреймворке. Вы помните, что я ранее писал о том, что тимлид начинает меньше писать код и больше управлять? Эти скилы имеют свой пик именно в момент наибольшей востребованности специалиста в роли кодера.
• hard skills — это совокупность знаний и опыта разработчика, со временем рост их снижается по той причине, что старые знания уже устаревают и становятся не востребованы, но остается полезен из них именно сухой остаток.
• soft skills — это именно те личностные качества, которые нельзя посчитать, но которые надо развивать. Это качества, которые важны всегда, но в разной степени даны всем от рождения.

Но давайте добавим еще один график

value = (0,5*tech + 1*hard + 1,5*soft)/3

В третий раз повторюсь, что это лично моя формула, а коэффициенты я вывел за более чем 10 лет профессиональной деятельности в области разработки.
Зеленый график отражает совокупность всех качеств специалиста, и это является его итоговой ценностью.

Почему технические скиллы ценятся в три раза меньше, чем софт скилз? Вспомните фразу «как специалист он хороший, а как человек — не очень» и тех, к кому она применялась. Руководитель более охотно выберет соискателя, на которого всегда можно положиться, чем соискателя, который пригоден только для одного единственного проекта, и то над ним нужен глаз да глаз. Даже джуну легче работать и быстрее развиваться в команде, где ему помогут и направят, а не будут стремиться подставить при первом удобном случае.

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

2 варианта развития программиста

Я описывал вариант, когда разработчик двигается по следующему пути:

Junior → Middle → Senior → TeamLead? → Project manager? → Head Of * → Chief * Officer

Но что делать если это не получается или не надо?
Та же самая формула работает и в случае, если вы хотите развивать свои софт скиллз и становиться менеджером: можно развивать технические скиллы и быть востребованным специалистом без необходимости двигаться в сторону менеджмента. Но тут надо понимать, что технические скилы имеют свойство устаревания: сегодня ты отличный программист на Фортране, а завтра ты уже никому не нужен.

TechLead vs TeamLead

В связи с укором со стороны читателей за то, что эта тема была не раскрыта в статье (соглашусь, что стоило бы добавить материал), то я дополню отличиями двух видов лидов.

TeamLead (вариант 1 из предыдущей главы) — технически грамотный специалист, который управляет командой разработчиков. Для работодателя этот вариант является более выгодным по ряду причин:

1. Он ближе к разработчикам и может их адекватно оценивать
2. Разработчики к нему относятся лучше, чем к проектному менеджеру
3. Можно убрать из проекта или снизить участие проектного менеджера (а он не приносит прямого дохода)
4. Он может общаться с клиентом с точки зрения бизнеса, а не технологий.
5. Совмещает в себе роли TechLead и PM

TechLead (вариант 2 из предыдущей главы) — технический специалист без управления командой. В ряде случаев он более технически подкован, нежели TeamLead, но для работодателя менее интересен, т.к. не совмещает в себе 2 роли.
Почему конкретный человек — именно TechLead, а не TeamLead:

1. Он может быть технически очень сильным, и отвлекать его не стоит, например, может участвовать в большем количестве проектов
2. Он — интроверт или мизантроп, ему очень сложно общаться с людьми, а им — с ним
3. Он очень сильно любит программировать, и управленческие задачи ему не интересны
4. PM не хочет делиться с ним обязанностями
5. В компании нет необходимости в TeamLead, и больше требуются технические специалисты

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

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

Заключение

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

Переход от разработчика в менеджеры (под менеджером я подразумеваю скорее не продуктового менеджера, а руководителя, тот же тимлид сочетает в себе менеджерские и технические роли) стоит делать, если софт скилы превосходят технические, и если инициатива исходит от самого разработчика.

Плохие варианты, которые не дадут хороших результатов:

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

Если вам не нравится или не получается менеджерить, но вас заставляет руководитель, то лучше сразу ему об этом сказать, а не пересиливать себя, а потом в какой-то момент сорваться и «улететь кодить на Бали». Помните: если вам нравится писать код, а не руководить, то и пишите его.

Если же вы не можете/не хотите уйти в менеджеры, но при этом просто программировать вам уже не интересно, то можно рассмотреть вариант перехода в коучи: продавать свои услуги архитектора, вести свои курсы и т.д.

Если же вам хочется и нравится руководить командой разработчиков, то стоит двигаться в этом направлении и стремиться искоренять из себя разработчика — это самое сложное. Надо стараться делегировать задачи, а не делать их самому. Кстати, рекомендую отличную книгу «Как пасти котов», в которой собраны советы программистам, которые хотят стать руководителями.