[Перевод] Миф о незаменимом разработчике
Давным-давно, в далекой-далекой галактике, жил да был старший разработчик, который считал себя незаменимым. А работал он в одной и той же компании со дня ее основания. Он разработал архитектуру главного веб-приложения и с нуля создал всю корпоративную инфраструктуру. При нём сменилось пять CTO, компания мигрировала с AWS на Azure и обратно. Он исправил бесчисленное количество багов и привел в компанию порядка 10 новых разработчиков. Работал он днями и ночами, чтобы система, не дай Бог, не вышла из строя. А еще он никогда не уходил в отпуск.
И вот однажды наш разработчик заболел. Да еще как! Ему пришлось взять отпуск на целый месяц, к тому же руководство запретило ему любое общение с компанией и коллегами. Сидя в заслуженном отпуске, разработчик продолжал тревожиться о судьбе компании, и когда пришло время вернуться в офис, он ожидал, что там воцарился хаос, всё сломалось, сгорело и вообще — без него не работает. И наш разработчик был крайне поражен, когда узнал, что всё в порядке и работает не хуже, чем раньше. А кое-где даже стало чуть-чуть получше. Он-то думал, что за долгие годы стал незаменим. Но оказалось, что мнимая незаменимость — всего лишь плод его воображения. Легенда, миф. Бабушкина сказка…
Источник: https://unsplash.com/@saytosid
Путь разработчика: искусство или ремесло
Нам, программистам, нравится думать о себе как о художниках, мастерах, выполняющих исключительно творческую работу. Не спорю, иногда так и есть. Но попробуйте-ка вспомнить, когда в последний раз лично вам приходилось придумывать новый паттерн разработки или самостоятельно писать улучшенную реализацию бинарного поиска?
Большая часть нашей работы — это CRUD с небольшой примесью интеграций cron-заданий.
Да, вам необходимо было освоить основы вычислительных наук, а профильное образование не раз и не два выручало в сложной ситуации. Тем не менее, нет ничего такого, что некоторые (способные) начинающие разработчики не освоили бы в буткемпе и не научились бы делать за пару лет на вашей работе.
Теперь у нас есть IDE, такие как Visual Studio, с IntelliSense, функцией дополнения кода и рефакторингом. Это позволяет нам создавать программное обеспечение гораздо быстрее, чем в прошлом. Если у вас возникли трудности или что-то непонятно, всегда можно пойти на StackOverflow или в Google Search. За пару-тройку кликов вы обязательно найдете ответ. Nuget и npm предоставляют тысячи пакетов, которые можно просто-напросто скачать и использовать.
Так что же все-таки делают разработчики? Большая часть работы нашей работы на самом деле уже сделана. И мы всего лишь собираем программное обеспечение из кусочков Lego.
Ценность разработчика
Вы знаете, что такое настоящий, дистиллированный Бред? Это когда во время ежегодного подведения итогов начальник на голубом глазу уверяет вас, что вы являетесь неотъемлемой частью команды и что он сделает все возможное, чтобы удержать вас в компании.
Независимо от того, насколько велика или мала ваша роль в команде технических специалистов, вас могут выбросить на улицу как щенка, если произойдет одно из следующих событий:
Компанию купят, и у покупателя будут свои собственные разработчики.
Штат сотрудников сократится из-за рецессии/падения выручки/пивота в деятельности компании.
Руководство примет решение об аутсорсинге в Индию/Мексику/Восточную Европу (да-да, это все еще актуально!).
Придет новый технический директор/руководитель группы, полный крутых идей и заранее решивший перетянуть за собой свою старую команду.
Эта история из начала статьи… В общем, она произошла со мной, и поначалу я был удивлен: как же так? Именно я был в компании с самого начала, я построил и многие годы развивал эту систему. Это мое детище, черт возьми, так каким же образом кто-то может просто прийти сюда с улицы и взять на себя мои отцовские обязанности? А вот запросто!
Да, какое-то время у него уйдет на изучение и адаптацию, но даже если вы вели дела из рук вон плохо, новый разработчик все равно во всем разберется, независимо от отсутствия документации или вашего дрянного кода. Процесс может занять пару недель или даже месяцев, но рано или поздно все вопросы решатся, и вы перестанете быть нужны.
В наше время существует немало компаний, которые функционируют по принципу «разработчик — это мелкая шестеренка в нашем большом механизме». Это возведено в ранг корпоративной культуры и, надо признать, приносит свои плоды. Все любят примеры из практики, так что давайте рассмотрим один из них…
Crossover
Есть такая компания под названием Crossover (поищите ее в Google). Они нанимают иностранных разработчиков и платят им по 10–15K в месяц (вернее, эквивалент этой суммы в местной валюте). Туда берут только лучших разработчиков, и чтобы попасть в Crossover, придется пройти множество проверок и интервью. Это как 36 ступеней Шаолиня, только еще сложнее. При этом они относятся к разработчикам как к легко заменяемым ресурсам. Конечно, менеджеры компании прожужжат вам все уши о том, что разработчики — важнейшая часть компании, что благодаря высокой корпоративной культуре они буквально пишут код и утирают слезы радости. Но в действительности они обращаются с разработчиками ничуть не лучше, чем Amazon с грузчиками на своих складах. Разработчиков постоянно выжимают досуха. За ними следят с помощью программного обеспечения, которое рандомно делает скриншоты их рабочих столов в течение дня. Их труд измеряется десятками метрик (да-да, прямо как в Amazon). Предполагается, что люди будут работать по 40 контролируемых и максимально сосредоточенных часов в неделю, но мы-то знаем, что такой труд отнимает все 60. Приблизительно через год-два люди полностью выгорают и… заменяются новым разработчиком, только что закончившим Crossover Bootcamp. И он приходит: весь такой блестящий, сверкающий и полный энергии, на самом деле, только чтобы через пару лет стены Crossover покинула его пустая оболочка.
И знаете, что — это работает. Ну, если не считать моральных проблем с высасыванием жизненной силы из живых людей. Но им платят огромные суммы (в 10+ раз больше средней зарплаты в их странах), и они знают, на что подписываются. Ну, или, по крайней мере, догадываются.
Подход «заменяемой шестеренки» жизнеспособен при соблюдении нескольких условий:
только проверенные старшие разработчики;
выверенный процесс собеседования и приема на работу;
оплата существенно выше рынка;
мануал, покрывающий до 90% того, чем занимаются разработчики: CRUD, интеграции, общие методы работы и т.д.
То, что касается мониторинга разработчиков, внедрять вовсе не обязательно. Чтобы достичь успеха, делайте только то, что позволяет вам делать совесть, и соблюдайте пару пунктов из списка выше.
10x разработчики
Есть одно небольшое исключение из правила о заменяемости: так называемые 10-кратные (10x) разработчики. Но их очень мало.
Они могут работают в 10 раз быстрее и эффективнее обычных программистов. Серьезные компании обычно держат их под замком и выпускают на задний двор погулять. Но не более часа в день.
Каждый раз, когда такой разработчик грозится уйти туда, где платят зарплату вдвое больше, компания просто дает ему тройной оклад.
Из примерно 100 человек, с которыми я работал, только двое могли называться »10x». Они действительно казались волшебниками от мира кодинга и их необходимо было сохранить в компании любой ценой. Но это скорее исключение из правил, чем норма.
К чему прибегают разработчики, чтобы их было труднее заменить?
Вот лишь некоторые вещи, которые, по мнению разработчиков, можно делать, чтобы сохранить за собой место в компании. Но они обманывают только себя.
Не писать документацию. Но даже без документации другой разработчик может просмотреть код и после долгих (и сердитых) размышлений понять, как все устроено и работает.
Писать дрянной код, который никто не захочет читать/поддерживать. Практические такой же глупый вариант, как в пункте 1. Другой человек поскрипит зубами, но справится.
Единолично владеть некой основной частью системы, не рассказывая другим разработчикам о том, что она делает или как работает. Этот вариант довольно хорош, но в случае чего с ним так же просто справиться. Пока код лежит в общем доступе, любой другой разработчик может потихоньку в нем разобраться. Пускай это и потребует от него массы нервных усилий.
Как видите, разработчики не так уж много могут сделать, чтобы стать незаменимыми.
Что компании могут сделать для того, чтобы разработчиков было легче заменить?
В наше время разработчики меняют компании как перчатки.
Поэтому компании должны быть готовы к тому, что любой разработчик может уйти в любой момент. Жужжание в уши и повышение зарплаты на 3% больше не работают. Хотя не факт, что они работали и раньше.
Итак, вот некоторые вещи, которые компаниям приходится делать, чтобы облегчить замену сотрудников:
Установить стандарт для кодирования;
Статический анализ кода;
Автоматическое тестирование;
CI/CD;
Dev WIKI.
Но и без всех этих штук любого разработчика можно исподволь заменить — это всего лишь вопрос времени и свободного бюджета.
Заключение
Незаменимых разработчиков не существует (за исключением крайне редких 10X покемонов). Таков уж современный корпоративный мир. Времена, когда люди работали в одной компании 20+ лет, канули в лету. Разработчики никогда не должны считать себя незаменимыми. А в идеале всегда стоит краем глаза поглядывать в сторону новых возможностей.
