Привет! Решил поделиться своей историей – может, кому-то будет полезно или хотя бы весело. За 20+ лет в разработке я прошёл путь от студента, который изучал C++, до техлида в госкомпании. И знаешь что? Понял, что комфортнее всего мне было просто кодить, а не управлять людьми.
НАЧАЛО: КОГДА ИНТЕРНЕТ БЫЛ ПО КАРТОЧКАМ
Всё началось в институте. Купил толстенную книгу по C++ (автор – Бьерн Страуструп), но начать кодить получилось не сразу, компилятор на горбушке было трудно достать. Поэтому я смотрел на предлагаемый в книге код и представлял себе результат выполнения. Да-да, я мысленно «компилировал» код и пытался понять, что выведется на экран. Сейчас это звучит странным, но тогда у меня не было другого выхода, а программировать ужас как хотелось.
Потом появился Delphi. Drag&Drop интерфейс – сразу видишь результат. Чувствуешь себя настоящим программистом, что вот-вот и начнёшь делать «мега крутую программу», а то и новую оболочку для Windows. Параллельно ненадолго пришёл 1С, потом интранет-сайт (олдовое название) на работе на PHP. И меня уже было не остановить: HTML, CSS, немного JavaScript – всё по классике.
ГОДЫ СТРАНСТВИЙ
Дальше понеслось: десктопные приложения на C# WPF, перехват хуков Windows API, бэкенд, фронтенд, базы данных – что угодно, лишь бы работало. С упоением ждал новых версий технологий, чтобы попробовать их новые фишки. PostgreSQL, MSSQL, MySQL, Redis, MongoDB – всё перепробовал. Параллельно с этим хочешь не хочешь, но изучаешь, как не только «переустановить винду», но и поднять с нуля БД, что прописать в реестр и как создать сервер для сайта. Был универсальным солдатом: утром фиксишь баг в API, днём рисуешь новую форму на фронте, вечером оптимизируешь запросы к базе.
Честно говоря, это было круто! Понимаешь весь процесс от начала до конца, можешь сам решить любую проблему. Никого не ждёшь, ни на кого не злишься – просто делаешь.
КАРЬЕРНЫЕ КАЧЕЛИ
Последние лет 10 меня кидает как маятник: то руковожу проектом, то ведущий фронтенд-разработчик, то архитектор, то снова тимлид. Код-ревью, планирование, совещания, ещё совещания... В какой-то момент понял, что кода пишу всё меньше, а времени на орг вопросы трачу всё больше.
Тимлид – это когда ты должен быть на связи 24/7. Суббота, воскресенье, утро 1 января – не важно. «Можешь быстро посмотреть?», «А как ты думаешь?», «А почему не работает?». И вроде бы статус высокий, зарплата больше но кайфа от работы меньше. Да, ты как небольшой руководитель стараешься всё автоматизировать, все процессы работы твоих сотрудников – от Jira правил до автопроверки кода и выкладки Docker-контейнеров на стенд. Но при этом теряешь контроль над самым важным элементом – кодом проекта.
ПРОЗРЕНИЕ
И тут до меня дошло: я программист, чёрт возьми! Мне больше нравится решать задачи кодом, а не людьми. Мне нравится видеть, как оживает интерфейс, как оптимизированный алгоритм работает в разы быстрее. Мне НЕ нравится объяснять в пятый раз, почему нужно не просто «добавить кнопочку» из задачи, а и предугадать к чему это добавление может привести (в том числе намёк в сторону тестов кода).
Сейчас я сделал небольшой дауншифтинг, остановился на техлиде по фронтенду и стараюсь держать баланс: архитектурные решения принимаю, но руки от клавиатуры не отрываю.
ВЫВОД
Карьерный рост – это не всегда движение вверх по иерархии. Иногда это движение в сторону того, что тебе действительно нравится. Хочешь управлять людьми – становись менеджером. Хочешь решать сложные технические задачи – оставайся разработчиком.
Мой совет: не гонись за должностями. Иди за тем, что приносит удовольствие. Потому что в IT можно хорошо зарабатывать и просто разработкой. А спать спокойно – это вообще бесценно.
Мои статьи также доступны тут.
Комментарии (48)
ForestDront
30.07.2025 20:02А я дошёл до тимлида и свалил на удалёнку тогда, когда это ещё не было трендом. И вот теперь, спустя 12 лет, я бы снова не прочь потимлидствовать, но поезд ушёл, второй раз по этому пути не пройти.
Ravius
30.07.2025 20:02Почему не пройти? Идёте на курсы какого-нибудь менеджмента и звучиваете свою "хотелку" и/или переходите в другое.
Не "не пройти" а лень и "случай" ушёл, и все о вас как о разрабе думают...и вы тоже.
ForestDront
30.07.2025 20:02Какие курсы? Везде требования от 5 лет опыта тимлидства на последнем месте работы
IAdmiral
30.07.2025 20:02Aurora прав, напишите лет 5-7 опыта, или вообще напишите его как свой опыт работы в компании, главное понимание того что вы вообще будете делать, но порой даже этого не нужно.
Хороший HR, который сможет вас поймать на лжи в вашей же области знаний - редкость - таких даже меньше чем токарей 8го разряда, котоыре существуют только на бумаге.(Почитал однажды их требования и компетенции, там требуется буквально супермен.)
Ravius
30.07.2025 20:02Хорошие;) Теоретическую базу получить, поучаствовать в семинарах и разборках кейсов. На ютубе были конфы яндекса про тимлидство.
Если команда маленькая - то менеджмент не особо важен ....даже если просят 10 лет опыта.
Но если вы хотите сразу на 10+ человек, а оно вам точно надо?)
summerwind
30.07.2025 20:02Хочешь управлять людьми – становись менеджером. Хочешь решать сложные технические задачи – оставайся разработчиком.
Непонятно только, почему выбор сводится только к тому чтобы либо идти управлять людьми, либо вечно быть в роли разработчика.
Есть же и технические направления роста вплоть до Architect и Principal Engineer :)
ritorichesky_echpochmak
30.07.2025 20:02технические направления роста вплоть до Architect и Principal Engineer
А можно весь списочек в куда расти на всяк случай? А то меня на одном собеде прям забодали "идите лидом". Правда выяснилось что там попил тендеров для гос.заказов и от "лида" только ответственность и никаких ручек на что-то повлиять
summerwind
30.07.2025 20:02Вряд ли есть какой-то единый список, но из того, что я встречал, есть два технических направления для роста:
Ветка Staff → Principal → Distinguished.
Разные виды архитекторов: Solution Architect, Software Architect, Data Architect, Enterprise Architect.
life-developer Автор
30.07.2025 20:02И на каждой работе компетенции этих должностей понимаются по разному. По крайней мере в РФ.
TechnoMag82
30.07.2025 20:02ГОДЫ СТРАНСТВИЙ
И тут, когда я эти годы, казалось бы повод для гордости, озвучиваю в резюме, на меня смотрят как на "Overqualification"....
urvanov
30.07.2025 20:02Тимлид – это когда ты должен быть на связи 24/7. Суббота, воскресенье, утро 1 января – не важно. «Можешь быстро посмотреть?», «А как ты думаешь?», «А почему не работает?».
А нельзя сказать им, что в понедельник посмотришь? Я просто уже 16 лет работаю. И я точно могу сказать, что большая часть задач, которые "срочные", не такие уж и срочные, да и не особо нужные в данный момент. Да вообще больше половины того, что мы делали, в реальности было бессмысленной работой, большая часть сроков сдачи проектов была взята просто с потолка без учёта имеющихся ресурсов и других проектов. Но все бегают, суетятся, придумывают новые задачи, рефакторинги туда-обратно, новые трансформации и т. д. Может, нам иногда стоит успокоиться и начать более-менее спокойно работать и пытаться отсечь хотя бы часть ненужной работы, а не только узкоколейку за три месяца под дождём и снегом строить.
mixsture
30.07.2025 20:02большая часть задач, которые "срочные", не такие уж и срочные, да и не особо нужные в данный момент
Вот это прям в точку. Более того, из моего опыта: если задача не представляет из себя фикс бага, то чем "срочнее" задача, тем меньше стоит ожидать от нее продуманности. Ну не успевают люди сфокусироваться на ней и продумать, "срочная" задача это часто эскиз какой-то идеи, а вовсе не что-то готовое к выполнению. И это для меня (со стороны исполнителя) обычно означает, что требования к задаче будут докидываться в процессе ее исполнения, иногда меняя ее чуть ли не на противоположную.
Отсюда, имхо, и рождается
больше половины того, что мы делали, в реальности было бессмысленной работой
Это еще и ухудшает само планирование. В сущности "срочность" это часто попытка обойти нормальные процессы планирования, анализа и проектирования. Это вот очередь "я только спросить" к доктору, которые, забежав, там на полноценный прием остаются, да еще и пришедшие без всех анализов (а их на лету надо сделать).
Chelyuk
30.07.2025 20:02Полностью поддерживаю. По моему опыту, особенно в аутсорсе. Менеджер на стороне компании провайдера услуг гонит всех на ровном месте исключительно для собственных бонусов. Когда удаётся поговорит с заказчиком напрямую и дать обоснованный развернутый ответ, что и почему, и сколько нужно времени. Я ни разу не слышал от заказчика возражений и попыток торопить. А вот от своих же менеджеров очень часто. Мало попадалось действительно толковых.
Ну и в целом, приходишь и говоришь давайте в начале проекта спланируем договоримся и задокументируем хотя бы тикетами. Но нет, так никто не хочет. А вот после дедлайна все переделывать - это пожалуйста.
kimisa
30.07.2025 20:02Не всегда так. Бывает проблема - упал сервер. Тебя дергают. Минут 30 сидишь разбираешься, в итоге это сисадминская проблема. Или проблема другой системы от которой зависит твоя.
urvanov
30.07.2025 20:02Одно дело, если упал продакшен сервер. Вот это реально срочная таска. А если упал, но стенд разработчиков, тестировщиков или аналитиков, то почему утром в понедельник его починить нельзя?
kimisa
30.07.2025 20:02а кто-то во вне рабочее время по этой проблеме дергает? я только про прод знаю.
Dhwtj
30.07.2025 20:02больше половины того, что мы делали, в реальности было бессмысленной работой, большая часть сроков сдачи проектов была взята просто с потолка без учёта имеющихся ресурсов и других проектов
Воистину!
gybson_63
30.07.2025 20:02Тимлидами тоже надо руководить, чтобы не шарахали команду по экстремальным практикам.
Chelyuk
30.07.2025 20:02Тоже так скитаюсь, только в тестировании.
Когда последний раз был лидом, понял что кодом то заниматься получается. Но мир меняется очень быстро, новые инструменты, подходы, языки. Но времени их изучать нет. Поэтому спрыгиваю периодически в разработку.
Проблема потом вернуться в некоторых местах. Потому что нет стандартных требований, у одних лид - это чистый менеджер, у других это Senior Principal Test Engineer. А у третьих ты должен быть на уровне Software Architect плюс всё про тестирование. И тут я не очень понимаю, почему позиция по оплате ниже на 20-30% чем Dev Lead требует в 2 раза больше знаний? И зачем тогда программисты, если тестировщики должны знать языки не хуже?
ELark
30.07.2025 20:02Тимлид — это менеджер младшего звена.
Мой кейс один из самых распространённых: тимлид и техлид в одном лице. Главная моя мотивация стать лидом была возможность наладить процессы, некоторые из них аккуратно отстроить с нуля; вырастить себе замену и уйти в техлиды, делегировав пост тимлида своему протеже.
Сейчас я в середине пути. Выстраивать процессы работа щепетильная и очень деликатная.Становясь тимлидом, полезно обозначить свой профит и цену за него. Я заранее знал на что подписываюсь, потому двухкратные перегрузки на старте не были внезапными.
По итогу полученный опыт для меня оказался предельно полезным.По сабжу. Тимлид это вполне себе карьерный рост, но не профильный для трудяг (программистов, тестировщиков, аналитиков и т.п.), а потому это почти всегда отдаление от профиля в сторону менеджмента.
Я достаточно молод как тимлид (1,5 годика), а потому ещё не определился — хочу ли остаться в этом должности или срочно возвращаться к любимому делу.
zuek
30.07.2025 20:02Любой "рост" в менеджеры - отдаление от предметной области. Я, будучи админом, лет 10 проработал на менеджерских позициях (вплоть до ИТ-директора в компании на 1к+ пользователей), но вернулся "к истокам" - все эти планирования, совещания, бесконечные отчёты... не моё это.
ELark
30.07.2025 20:02Отличный кейс, внушающий опыт. Охотно почитал бы ваши статьи на тему менеджмента.
Если в течение пары-тройки вернусь к своему основному профилю, то менеджерский опыт для меня будет крайне полезным опытом и в разработке. Ибо то, до чего я бы годами доходил, глядя с позиции исполнителя; с позиции руководителя многие процессы стали понятны почти "моментально" (каких-то 1,5 года) сразу в глубину.
ИМХО, вне зависимости от того продолжить рост в менеджменте или вернуться "в поля" -- профессионал нисколько не потеряет от полученного опыта. Разве что перспективы раскроются в других плоскостях.
п.с. совещания (когда эффективны) и планирование - мне по душе, но вот отчёты - это боль. У любой профессии есть свои издержки :)
MadMaxLab
30.07.2025 20:02Тимлид – это когда ты должен быть на связи 24/7.
Тимлид - это человек, который, при необходимости поддержки 24/7, должен помочь организовать справедливый график дежурств. Если же вот эти «А как ты думаешь?» приходят от внутренних членов команды, то можно просто игнорировать до рабочего времени.
Да, ты как небольшой руководитель стараешься всё автоматизировать, все процессы работы твоих сотрудников – от Jira правил до автопроверки кода и выкладки Docker-контейнеров на стенд.
Да, от тебя ожидается налаженная работа команды, но не обязательно это делать своими руками. Нарисовал команде вижн "как надо", завел задачи, согласовал с руководством время на их исполнение и распределил по команде.
Все-таки тимлид - это небольшой руководитель и получает "дополнительную пайку" именно за организацию процесса, а не за то, что самый продуктивный кодер.
Juri7788
30.07.2025 20:02"Никого не ждёшь, ни на кого не злишься – просто делаешь"
По мне так работа в команде это не просто делаешь, а делаешь вместе. И тут естественно есть поле для возможных споров, недопониманий и так далее. Так что работа над кодом это всё равно работа с людьми, хотя и в сильно меньшей степени.
LeoKudrik
30.07.2025 20:02Всё то же, но у меня еще и бизнес был по теме. В итоге - просто программер.
QtRoS
Основной посыл статьи неплохой, однако выводы на основе частных случаев смущают. Например:
Нет, это просто-напросто неправда. Похоже вас в этом убедила пагубная среда или это ваша гиперответственность материализовалась. На самом деле бывает и даже очень распространена зрелая, спокойная и уверенная тимлидская работа.
История стара как
мирнаша индустрия. Подобное часто бывает с тимлидами-самоучками (или как сейчас называют first-time manager). Главное не опускать руки, ознакомиться с многочисленными похожими историями и научиться терраформировать окружение под себя, а не пытаться усидеть на всех стульях. И работа снова начнет приносить удовольствие ;)life-developer Автор
Конечно, я не имел ввиду, что это нормально. Просто это реалии среднестатистической работы. К сожалению, мой опыт говорит, что очень редко когда можно встретить нормально выстроенные бизнес-процессы в компании. Отсюда и "переработки" ответственных людей.
У меня гиперответственность присутствует, безусловно. Иначе бы я не смог посвятить всю жизнь разработке.
rpc1
Мой опыт говорит обратное, я перерабатывал только на первой своей работе.
Попробуйте прочитать книжку: "Одноминутный менеджер", мне она помогла, когда я перешел на должность лида.
emerald_isle
Дык не только у менеджеров или тимлидов такое бывает. У вполне себе individual contributor бывает также или хуже, вполне бывает что и по субботам надо, и 24/7, иногда переработки оплачивают, иногда не особо. Просто ваш опыт специфичный, менеджером вам быть не повезло в нездоровых коллективах, тогда как инженером вас удалось поработать без лишнего стресса.
Хотя в среднем, конечно, менеджерство - стресса больше, так как больше ответственности. Даже если вы работаете строго 40 часов в неделю и не секундой больше, без переработок, даже такая работа может выматывать и демотивировать, если всё валится из рук, везде бардак, слишком много болтовни и слишком мало дела.
rpc1
Вот и ответ, почему такие условия работы
geher
По моему опыту условные "лиды" в госкомпаниях (условные, поскольку должности в госкомпаниях обычно именуются иначе) гораздо реже прояаювляют гиперответстаювенность, чем их коллеги из частных контор.
Другой вопрос, что причины такой гиперответственности (помимо особенностей личности сомого лида) обычно разные. Но таки бывает по разному, и у частника бывает более жесткая рабочая обстановка, чем у госа.
R3B3LL10N
Это может быть не гиперответственность, а давление начальства. Мол, ты ж лид, значит единственное оправдание что не на связи - это смерть.
geher
Это тоже форма гиперответственности: начальство сказало - не рассуждая метнулся исполнять.
urvanov
Там в начальстве сидят такие же как мы. Они тоже не знают, что делают и зачем.
R3B3LL10N
Или конформизм/неуверенность в себе из за которых хочется выслужиться лишь бы не уволили.
uuger
Работал в, фактически, госкомпании много лет. 99% всех "срочностей" создаются искусственно участниками процесса, хотя все эти бурления фактически не влияют ни на что, кроме выполнения ритуалов внутреннего карго-культа со всякими KPI, поддерживающими процессами и прочим барахлом: тома документации, которые никто не читает, так как они устарели ещё до момента утверждения; системы, в которые перестают заходить спустя полгода после релиза; дашборды, наполненные метриками не на основе реальных транзакций, а после ручного докручивания заинтереснованными менеджерами; регистрация интеллектуальной собственности на базу данных, выдранной из стороннего софта - you name it. "Настоящий" же бизнес (то, что японцы кличут "Гэмба") на большинство этих танцев может плевать с высоченной колокольни.
SchwertPG
Имхо, наоборот должно быть. В госкомпании в 17.30 закрыл ноут и пошел себе домой. Все незавершенные дела завтра с утра буду думать)))
life-developer Автор
Когда твоим продуктом пользуется вся Россия (госслужащие во всех часовых поясах РФ), а тестировщики проглядели баг - фиг тут "закрыл ноут" сработает