На этой должности вы будете плохим разработчиком +2



Вы никогда не думали, что вас могут уволить не из-за того, что вы глупый и плохой разработчик, а из-за того, что все процессы в организации построены так, что вы на данной позиции априори будете кривым и плохим! И единственный вариант перестать быть кривым – сменить ответственный участок, за который вы отвечаете.


Если вы работали в больших компаниях (больше 30 разработчиков), вы могли бы заметить, что на определенных участках ответственности разработчики меняются гораздо чаще, чем на других. И что самое интересное, часто разработчиков увольняют за некомпетентность, нарушение трудовой дисциплины (ругается с тех-диром, лидом), и общий пофигизм (перегорание). И знаете, в этом есть определенная закономерность.

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


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

Легаси системы не сексуальны


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

  • Продуктовые команды показывают новые фичи, все довольно хлопают, как стало круто.
  • Команды доработки существующего функционала показывают, как они круто исправили ошибки и недочеты, которым клиентами насиловали саппорт и отдел продаж (все в восторге).
  • Команда развития инфраструктуры показывает, что они смогли оптимизировать работу и теперь мы сможем сэкономить 4-5 тысяч долларов в месяц на серверах (тех-дир в экстазе).
  • Команда поддержки легаси систем, говорит, что они исправили формирования отчета для бухгалтерии, если шли невалидные данные от контрагентов (Всем пофиг).

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

Легаси системы наказывают твой зад


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

Если мы говорим про легаси ситемы, то чаще всего ситуация выглядит так. В лида заходит какой-то из отделов (продажи, бухгалтерия, маркетинг итд). И говорят, вот у нас проблема её надо починить. Лид передает разработчику и забывает про это дело.

Условно через неделю в лида снова заходит руководитель отдела маркетинга, продаж и говорит — какого хера вы не починил этот косяк. Мы не можем так работать, «нам что зайти выше?!». Лид заходит в разработчика и говорит «Какого хрена меня тут прессуют из-за того, что ты тут что-то не можешь сделать. Давай уже исправь это».

Легаси системы не дают тебе ценность


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

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

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

Легаси системы не допускают ошибок


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

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

В итоге, в первом случае – ошибка, это допустимая ситуация. Во-втором, вы мудак, что допустили ошибку и все сломали.

Разработчика с легаси систем легко уволить


Представьте, что появляется мысль, что кто-то из разработчиков плохо работает, и его нужно уволить. Лид заходит в ПМ спрашивает про увольнение. ПМ скажет «Вы там что сдурели, у нас и так горят сроки, если вы сейчас уволите Макса, мы точно не успеем. Я прямо скажу тех-диру, что это ваш косяк, и пусть он уже вас трахает. Лид думает, что действительно трахать будут его, поэтому он откладывает данное увольнение». А там уже и Макс одумается, либо еще что-то произойдет.

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



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

Вы можете помочь и перевести немного средств на развитие сайта



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

  1. eugenius_nsk
    /#20046014

    В голосовалке нет варианта «Нет, я всегда выясняю про проект перед трудоустройством».

    • WebMonet
      /#20046242

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

  2. brrr
    /#20046112 / +1

    Вы это на основании своего опыта нам рассказываете? Ну так по себе людей не судят. Я сам работал с легаси системой долгое время и могу по каждому пункту дать опровержение, потому что скорее всего вы частное выдаете за общее.

    • zzzmmtt
      /#20046408

      Либо вы выдаёте свой опыт за общий, а истина будет где-то между вашим опытом и опытом автора статьи.

      • exception13x
        /#20047540

        2 примера явно недостаточно, даже чтобы судить, что истина где-то посередине.

      • JustDont
        /#20048198

        Лично я тоже считаю, что статья какая-то очень бездоказательная. Вопрос бизнес-процессов внутри конторы — легаси точно так же добавляет в балансовое «итого», а что «славу забирает отдел маркетинга» — прямо скажем, очень спорное заявление. С чего бы, если в конторе нормально выстроенные процессы?

        ЗЫ: Это я тоже пишу как человек, много поддерживавший легаси, которое ценится.

    • sysif
      /#20049600

      Как по мне, так вопрос не в легаси как таковом. Вопрос в отношении к конкретным проектам внутри компании. Если в компании считают, что вон то проект — это адская поделка, то это будет сильно отражаться на проекте. Т.о. проблема частично находится в плоскости культуры в компании. А понятие легаси относительно само по себе и может быть разным в разных коллективах. И кстати легаси проекты обычно оставляют именно потому, что они все еще приносят ценность.

  3. TheR
    /#20046230

    Редкая чушь, написанная с печальной позиции outer locus of control.

    P.S. Стошнило в момент применения критерия сексуальности к софту.

    • faoriu
      /#20046260 / +1

      Там дальше ещё интереснее:


      в лида снова заходит руководитель отдела маркетинга

    • pehat
      /#20051366

      Вы, судя по профилю, менеджер, так ведь? Расскажите, как можно быть разработчиком (не техлидом) и при этом иметь inner locus of control.

  4. roscomtheend
    /#20046250 / +1

    Очень похоже на частный опыт. И перевод (все эти заходы в лиды и секусуальный код).
    Кому-то важно хлопание, кому-то оплата, за легаси платят и, бывает, платят хорошо, потому как мало кто может и «легко уволить» выглядит смешно, кто делать будет? фанаты фреймворков-однодневок? Там разбираться нужно.
    Больше похоже что автор пытался с наскока что-то вкорячить, всё поломалось (отсюда легко уволить и кричащие на продукты продакты) и его отправили править безопасные отчёты, что обидно и бесславно.

    • ghrb
      /#20046290

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

    • exception13x
      /#20047608

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

      Сам работаю в похожей команде, но нас считают какими-то «волшебниками», потому что лид активно «продает» труд коллег руководству, а следовательно и с премиями у нас все хорошо, и никого не пытаются уволить.

  5. 0serg
    /#20046282

    Если менеджмент идиоты то в компании и помимо легаси будет море проблем. Мне вот как то хватает ума понять что работа с легаси тяжёлая и быть благодарным к ребятам которые ее выполняют достойно. Ну и естественно пробивать замену той легаси которую поддерживать особенно сложно.

  6. Romario21
    /#20046300

    Я всегда приходил к владельцу бизнеса и говорил «Технологический стек устарел — поддержка и доработка не рентабельна… любо делаем нормально, либо занимаемся хней», после этого мы пилили новую систему. 2-6 месяцев работы, на выходе актуальная система покрывающая все текущие задачи компании. И этот подход отлично работал т.к было не посредственное общение с владельцем бизнеса, не было никакой прослойки вроде менеджмента. Разработчиков нас было 3 человека(все программисты, никаких тестировщиков, аналитиков и прочей лабуды)

    • MooNDeaR
      /#20046370 / +4

      Забавно и смешно) Вот в моей прошлой компании больше 500 разрабов, которые пилят около 50-ти продуктов и больше половины завязаны на общую кодовую базу, которой уже лет 17 минимум. Если с новыми продуктами ваш подход подойдет, то что делать для новых версий старых продуктов?

      • Romario21
        /#20046828

        Я поделился своим опытом, я не исключаю что ситуаций может быть много.
        У нас например в общей сложности было около 15 продуктов(GUI формы, бесконечная табличная часть, отчеты, разные платформы).

    • ghrb
      /#20046562

      Это что за бизнес-инструмент у вас был такой, лендинг плюс онлайн-калькулятор в котором каждый момент бизнес-логики документирован?

    • roscomtheend
      /#20048912

      2-6 месяцев — это небольшая система (или кусок большой, но только кусок). Тем более (вот сюрприз) легаси может развиваться и дорабатываться и взяв состояние на момент T, то в момент T+6 месяцев вы получите неактуальную систему. И в труЪ легаси у вас зачастую не будет документации (она даже могла быть где-то, лет 15 назад потерялась) на какую-то часть, может быть велосипед странной формы или ещё что и нужно понять как это работает, тут человекогода не хватит.


      и никаких тестировщиков, аналитиков и прочей лабуды

      Т.е. оно ещё и тяп-ляп и в продакшн.

  7. sergeyns
    /#20046840

    Если владельцы бизнеса/руководители говорят что это фигня

    >> они исправили формирования отчета для бухгалтерии, если шли невалидные данные от >> контрагентов (Всем пофиг).

    То бегите из этой компании. Хотя общий посыл статьи верен. Поддержку leegacy обычно оценивают по остаточному принципу. Так что лучше заниматься чем-нибудь «модным-молодежным»

  8. Druu
    /#20047040

    Легаси системы не дают тебе ценность

    Погодите, но ведь выше:


    Мы не можем так работать, «нам что зайти выше?!»

    Какая система может быть ценнее, чем та, без которой вообще нельзя работать?


    Разработчика с легаси систем легко уволить

    А кого вместо нанять? Ведь:


    Легаси системы недопускают ошибок

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


    Легаси системы не сексуальны

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

    блаблабла, выходит легаси-программист: "а в моих достижениях все вышесказанное в сумме, т.к. без меня ничего бы не было".

    • Eldhenn
      /#20047084 / +1

      > Какая система может быть ценнее, чем та, без которой вообще нельзя работать?

      Та самая бухгалтерия, которая сама работает, несмотря на то, что дурацкие IT-шники постоянно мешают работать и всё ломают.

  9. Aquahawk
    /#20047398

    Работаю с кодовой базой которой 8 лет, да не много по меркам некоторых легаси, но тем не менее. Проект переживает вторую смену движка и смену технологии, при почти полном сохранении кодовой базы. И вы знаете, огонь. Проект живёт, зарабатывает и каждую неделю катит новый функционал (контентная игра). Видеть как твои решения принятые много лет назад работают в деле спустя годы очень круто. Тут и начинается реальное понимание что GOF не всегда панацея, и есть вещи которые не принято считать хорошими которые блин работают. И да можно сказать залип в своём болоте, но нет, оно живёт и успешно развивается.

  10. noize
    /#20048162

    Разработчика с легаси систем легко уволить

    Вот с этим категорически не согласен. Скорее уволят разраба с продуктового проекта, чем того, кто поддерживает легаси. Потому что, скорее всего, на продуктовом проекте(тот, с которым непосредственно работают клиенты) используется довольно свежий стек и новых людей найти проще. На легаси может быть код, написаный много лет назад на чём-то, что уже практически не используется. И человек, поддерживающий это всё гораздо ценнее для компании.
    Попробуй найди норамльного разраба на перле в 2к19 на проект 10ти летней давности и чтобы он ещё не убежал посе знакомства с кучей г**на, который у вас называется легаси-проектом.

    • ukt
      /#20050566

      Сам программист со стажем на других, строготипизированных высокоуровневых языках. Пишу на пёрле, почти год.

      От заказчиков пришел проект, переданный в контору(куплен).
      Сам проект с историей почти в 10 лет.
      По факту примерно месяц ушло на построение в голове устройства проекта.
      Примерно ещё месяц на допиливание нужно функционала.

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

      Если по теме поддержки легаси, со своего опыта, двоякое ощущение.
      Из плюсов:
      + решение совершенно нестандартных задач, кто любит головоломки, например.
      Из минусов:
      — полученный опыт для будущего работодателя можно выкинуть, со всеми вытекающими проблемами.

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

  11. Igor_Shumilov
    /#20048178

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

    P.S. Я занимался легаси кодом на заре своей карьеры в текущей компании. И знаю каково это. Просто руководство моё более компетентное.

  12. ohtori_akio
    /#20048862 / +1

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

  13. Youfka
    /#20048864

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

  14. vilya_ya
    /#20048866

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

    • hatman
      /#20049188

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

    • sergeyns
      /#20049194

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

  15. Soo
    /#20048868

    Я думаю, это паблишить не сюда надо, а на zadolba.li

  16. hatman
    /#20049174

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

    Ибо большая часть комментариев именно про это идет.

  17. Stas911
    /#20050106

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

  18. fancy-apps
    /#20050178

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

    Но им по%$*&уй, они такие же наемные товарищи и плевать им на тебя, как ни разговор то импровизация. 90% Руководителей в ИТ в России сказочники! не согласитесь?

  19. YemSalat
    /#20055254

    Уже написали выше, но все-таки еще раз повторю — насчет того что людей, поддерживающих легаси, легко уволить — вы крайне не правы. Это же единственные люди, которые разбираются во всей этой непонятной фигне.
    Я как-то работал в компании, в которой одна из ключевых систем была написана на коболе, где работали дядьки по 50+ с зарплатами в два раза больше наших. За них держались как ни за кого другого.

  20. asm0dey
    /#20057502

    Я работаю над легаси-проектом и меня это устраивает. Это интересная работа.

    • hatman
      /#20057572

      Какой у вас язык программирования и версия языка

      • asm0dey
        /#20057872

        8 джава, планируем переход на 11.

  21. teemour
    /#20057576

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

  22. aivazovski
    /#20057728

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

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

    Поэтому кандидаты, мягко говоря, в очереди не стоят.

  23. thauquoo
    /#20064090

    Вы были в ситуации, когда вы поддерживали то, что не ценилось?

    Почему нет варианта «Да, и меня это устраивало.»? Опрос какой-то однобокий получился. Потому что у легаси-систем есть своё преимущество — более спокойный темп разработки, предсказуемость и намного лучшее планирование.

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