Привет! Решил поделиться своей историей – может, кому-то будет полезно или хотя бы весело. За 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 можно хорошо зарабатывать и просто разработкой. А спать спокойно – это вообще бесценно.

 Мои статьи также доступны тут.

Комментарии (42)


  1. QtRoS
    30.07.2025 20:02

    Основной посыл статьи неплохой, однако выводы на основе частных случаев смущают. Например:

    Тимлид – это когда ты должен быть на связи 24/7. Суббота, воскресенье, утро 1 января – не важно

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

    История стара как мир наша индустрия. Подобное часто бывает с тимлидами-самоучками (или как сейчас называют first-time manager). Главное не опускать руки, ознакомиться с многочисленными похожими историями и научиться терраформировать окружение под себя, а не пытаться усидеть на всех стульях. И работа снова начнет приносить удовольствие ;)


    1. life-developer Автор
      30.07.2025 20:02

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

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


      1. rpc1
        30.07.2025 20:02

        Мой опыт говорит обратное, я перерабатывал только на первой своей работе.
        Попробуйте прочитать книжку: "Одноминутный менеджер", мне она помогла, когда я перешел на должность лида.


      1. emerald_isle
        30.07.2025 20:02

        Дык не только у менеджеров или тимлидов такое бывает. У вполне себе individual contributor бывает также или хуже, вполне бывает что и по субботам надо, и 24/7, иногда переработки оплачивают, иногда не особо. Просто ваш опыт специфичный, менеджером вам быть не повезло в нездоровых коллективах, тогда как инженером вас удалось поработать без лишнего стресса.

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


    1. rpc1
      30.07.2025 20:02

      За 20+ лет в разработке я прошёл путь от студента, который изучал C++, до техлида в госкомпании

      Вот и ответ, почему такие условия работы


      1. geher
        30.07.2025 20:02

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

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


        1. R3B3LL10N
          30.07.2025 20:02

          Это может быть не гиперответственность, а давление начальства. Мол, ты ж лид, значит единственное оправдание что не на связи - это смерть.


          1. geher
            30.07.2025 20:02

            Это тоже форма гиперответственности: начальство сказало - не рассуждая метнулся исполнять.


            1. urvanov
              30.07.2025 20:02

              Там в начальстве сидят такие же как мы. Они тоже не знают, что делают и зачем.


            1. R3B3LL10N
              30.07.2025 20:02

              Или конформизм/неуверенность в себе из за которых хочется выслужиться лишь бы не уволили.


      1. uuger
        30.07.2025 20:02

        Работал в, фактически, госкомпании много лет. 99% всех "срочностей" создаются искусственно участниками процесса, хотя все эти бурления фактически не влияют ни на что, кроме выполнения ритуалов внутреннего карго-культа со всякими KPI, поддерживающими процессами и прочим барахлом: тома документации, которые никто не читает, так как они устарели ещё до момента утверждения; системы, в которые перестают заходить спустя полгода после релиза; дашборды, наполненные метриками не на основе реальных транзакций, а после ручного докручивания заинтереснованными менеджерами; регистрация интеллектуальной собственности на базу данных, выдранной из стороннего софта - you name it. "Настоящий" же бизнес (то, что японцы кличут "Гэмба") на большинство этих танцев может плевать с высоченной колокольни.


      1. SchwertPG
        30.07.2025 20:02

        Имхо, наоборот должно быть. В госкомпании в 17.30 закрыл ноут и пошел себе домой. Все незавершенные дела завтра с утра буду думать)))


        1. life-developer Автор
          30.07.2025 20:02

          Когда твоим продуктом пользуется вся Россия (госслужащие во всех часовых поясах РФ), а тестировщики проглядели баг - фиг тут "закрыл ноут" сработает


  1. ForestDront
    30.07.2025 20:02

    А я дошёл до тимлида и свалил на удалёнку тогда, когда это ещё не было трендом. И вот теперь, спустя 12 лет, я бы снова не прочь потимлидствовать, но поезд ушёл, второй раз по этому пути не пройти.


    1. life-developer Автор
      30.07.2025 20:02

      После тимлидства чем начали заниматься?


      1. ForestDront
        30.07.2025 20:02

        В программеры пошёл, на большую зарплату на удалёнку.


    1. Ravius
      30.07.2025 20:02

      Почему не пройти? Идёте на курсы какого-нибудь менеджмента и звучиваете свою "хотелку" и/или переходите в другое.

      Не "не пройти" а лень и "случай" ушёл, и все о вас как о разрабе думают...и вы тоже.


      1. ForestDront
        30.07.2025 20:02

        Какие курсы? Везде требования от 5 лет опыта тимлидства на последнем месте работы


        1. AuroraBorealis
          30.07.2025 20:02

          Ну так напишите 5 лет тимлидства на последнем месте работы


    1. themen2
      30.07.2025 20:02

      Почему не пройти?


  1. summerwind
    30.07.2025 20:02

    Хочешь управлять людьми – становись менеджером. Хочешь решать сложные технические задачи – оставайся разработчиком.

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

    Есть же и технические направления роста вплоть до Architect и Principal Engineer :)


    1. MyraJKee
      30.07.2025 20:02

      Ну, наверное это не всем дано. Не каждый солдат может стать генералом )


    1. ritorichesky_echpochmak
      30.07.2025 20:02

      технические направления роста вплоть до Architect и Principal Engineer

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


      1. summerwind
        30.07.2025 20:02

        Вряд ли есть какой-то единый список, но из того, что я встречал, есть два технических направления для роста:

        1. Ветка Staff → Principal → Distinguished.

        2. Разные виды архитекторов: Solution Architect, Software Architect, Data Architect, Enterprise Architect.


        1. life-developer Автор
          30.07.2025 20:02

          И на каждой работе компетенции этих должностей понимаются по разному. По крайней мере в РФ.


  1. TechnoMag82
    30.07.2025 20:02

    ГОДЫ СТРАНСТВИЙ

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


    1. Ioanna
      30.07.2025 20:02

      О да. Больше 5-7 лет опыта в резюме вообще нельзя писать.


      1. the_homeless_god
        30.07.2025 20:02

        +1


  1. urvanov
    30.07.2025 20:02

    Тимлид – это когда ты должен быть на связи 24/7. Суббота, воскресенье, утро 1 января – не важно. «Можешь быстро посмотреть?», «А как ты думаешь?», «А почему не работает?».

    А нельзя сказать им, что в понедельник посмотришь? Я просто уже 16 лет работаю. И я точно могу сказать, что большая часть задач, которые "срочные", не такие уж и срочные, да и не особо нужные в данный момент. Да вообще больше половины того, что мы делали, в реальности было бессмысленной работой, большая часть сроков сдачи проектов была взята просто с потолка без учёта имеющихся ресурсов и других проектов. Но все бегают, суетятся, придумывают новые задачи, рефакторинги туда-обратно, новые трансформации и т. д. Может, нам иногда стоит успокоиться и начать более-менее спокойно работать и пытаться отсечь хотя бы часть ненужной работы, а не только узкоколейку за три месяца под дождём и снегом строить.


    1. mixsture
      30.07.2025 20:02

      большая часть задач, которые "срочные", не такие уж и срочные, да и не особо нужные в данный момент

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

      Отсюда, имхо, и рождается

      больше половины того, что мы делали, в реальности было бессмысленной работой

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


    1. Chelyuk
      30.07.2025 20:02

      Полностью поддерживаю. По моему опыту, особенно в аутсорсе. Менеджер на стороне компании провайдера услуг гонит всех на ровном месте исключительно для собственных бонусов. Когда удаётся поговорит с заказчиком напрямую и дать обоснованный развернутый ответ, что и почему, и сколько нужно времени. Я ни разу не слышал от заказчика возражений и попыток торопить. А вот от своих же менеджеров очень часто. Мало попадалось действительно толковых.
      Ну и в целом, приходишь и говоришь давайте в начале проекта спланируем договоримся и задокументируем хотя бы тикетами. Но нет, так никто не хочет. А вот после дедлайна все переделывать - это пожалуйста.


    1. kimisa
      30.07.2025 20:02

      Не всегда так. Бывает проблема - упал сервер. Тебя дергают. Минут 30 сидишь разбираешься, в итоге это сисадминская проблема. Или проблема другой системы от которой зависит твоя.


      1. urvanov
        30.07.2025 20:02

        Одно дело, если упал продакшен сервер. Вот это реально срочная таска. А если упал, но стенд разработчиков, тестировщиков или аналитиков, то почему утром в понедельник его починить нельзя?


    1. Dhwtj
      30.07.2025 20:02

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

      Воистину!


  1. gybson_63
    30.07.2025 20:02

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


  1. Chelyuk
    30.07.2025 20:02

    Тоже так скитаюсь, только в тестировании.
    Когда последний раз был лидом, понял что кодом то заниматься получается. Но мир меняется очень быстро, новые инструменты, подходы, языки. Но времени их изучать нет. Поэтому спрыгиваю периодически в разработку.
    Проблема потом вернуться в некоторых местах. Потому что нет стандартных требований, у одних лид - это чистый менеджер, у других это Senior Principal Test Engineer. А у третьих ты должен быть на уровне Software Architect плюс всё про тестирование. И тут я не очень понимаю, почему позиция по оплате ниже на 20-30% чем Dev Lead требует в 2 раза больше знаний? И зачем тогда программисты, если тестировщики должны знать языки не хуже?



  1. ELark
    30.07.2025 20:02

    Тимлид — это менеджер младшего звена.
    Мой кейс один из самых распространённых: тимлид и техлид в одном лице. Главная моя мотивация стать лидом была возможность наладить процессы, некоторые из них аккуратно отстроить с нуля; вырастить себе замену и уйти в техлиды, делегировав пост тимлида своему протеже.
    Сейчас я в середине пути. Выстраивать процессы работа щепетильная и очень деликатная.

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

    По сабжу. Тимлид это вполне себе карьерный рост, но не профильный для трудяг (программистов, тестировщиков, аналитиков и т.п.), а потому это почти всегда отдаление от профиля в сторону менеджмента.

    Я достаточно молод как тимлид (1,5 годика), а потому ещё не определился — хочу ли остаться в этом должности или срочно возвращаться к любимому делу.


  1. MadMaxLab
    30.07.2025 20:02

    Тимлид – это когда ты должен быть на связи 24/7.

    Тимлид - это человек, который, при необходимости поддержки 24/7, должен помочь организовать справедливый график дежурств. Если же вот эти «А как ты думаешь?» приходят от внутренних членов команды, то можно просто игнорировать до рабочего времени.

    Да, ты как небольшой руководитель стараешься всё автоматизировать, все процессы работы твоих сотрудников – от Jira правил до автопроверки кода и выкладки Docker-контейнеров на стенд.

    Да, от тебя ожидается налаженная работа команды, но не обязательно это делать своими руками. Нарисовал команде вижн "как надо", завел задачи, согласовал с руководством время на их исполнение и распределил по команде.

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


  1. Dhwtj
    30.07.2025 20:02

    А почему вы решили что тимлид выше техлида?


  1. Juri7788
    30.07.2025 20:02

    "Никого не ждёшь, ни на кого не злишься – просто делаешь"

    По мне так работа в команде это не просто делаешь, а делаешь вместе. И тут естественно есть поле для возможных споров, недопониманий и так далее. Так что работа над кодом это всё равно работа с людьми, хотя и в сильно меньшей степени.


  1. LeoKudrik
    30.07.2025 20:02

    Всё то же, но у меня еще и бизнес был по теме. В итоге - просто программер.