Преамбулка


Эта статья является анализом другой статьи: Если вы не нанимаете джунов, то не заслуживаете сеньоров


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


Я оставил по возможности оригинальное оформление, а свои комментарии отметил отдельно.


Ну и желтый заголовок тоже оставил, немного видоизменив.


Поехали.



Позвольте рассказать вам историю об одной очень успешной компании, совершившей большую, глупую ошибку:


Мы не нанимаем младших программистов и интернов… Если не заводить щенка, не придётся убирать лужи.
--Netflix

Комментарий. Заголовок желтый и введение говорит о том, что дальше будет раскрыта суть ошибки и стремительное падение этой компании. На самом деле нет.


Я был совершенно поражён, как некое корпоративное нечто умудрилось представить щенков в отрицательном свете, да ещё кого-то этим убедило. Щенки — самые чистые создания на Земле, живая пушистая радость! Лучики света в одиноком мире. Но перейдём к сути.


Комментарий. Щенки не могут поддерживать сами себя в чистоте и самостоятельно питаться.


Многие компании последовали данной стратегии «нанимать только сеньоров». Они обосновывают это так:


  • У нас нет времени и ресурсов нанимать младших программистов; мы слишком быстро развиваемся.
  • Наша компания может себе позволить сеньоров, так что в джунах нет необходимости.
  • На текущем этапе мы не можем позволить себе ошибки. Ставки слишком высоки.
  • Наш процесс предоставляет сотрудникам большую автономность. Мы не готовы держать джунов за ручку, как они в том нуждаются.
  • Мы хотим заложить фундамент продукта прежде, чем начнём нанимать неопытных сотрудников.

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


Комментарий. Всегда было интересно, из какого пальца высасывается то, чего не было в оригинальной фразе. Где было про долг и про бюджет? Речь идет про отвлечение старших разработчиков: вместо создания продукта они будут обучать (ревьюить, объяснять, направлять, подфикшивать и проч) младших разработчиков. Т.е. тупо экономия времени старших разработчиков.


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


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


Кстати говоря, в США более 100 000 IT-компаний, и что-то я не слышал, чтобы хоть один CEO сказал «подумаешь, ошибки!» или «надо бы спустить куда-нибудь лишний бюджет». Так что внимание, организации, где «джунам вход воспрещён»! Какими бы вы ни видели свои выгоды, как бы вы ни обосновывали свой лайфхак, реальность такова, что вы всё это себе выдумали. Нет никакого конкурентного преимущества в избавлении от джунов. И вы только что продемонстрировали миру свой проблемный менеджмент.


Комментарий. Пока не видно доказательств, что эти 100 000 IT компании представляют собой эффективную среду для разработки, более эффективную, нежели у Netflix. Все это — жонглирование домыслами и эмоциями.


Hostility to junior developers is an easy way to spot a toxic company culture.
— April Wensel (@aprilwensel) 1 августа 2017 г.

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

Комментарий. Где тут враждебность? Никто не говорит, что джуниоры — враги. Их просто не нанимают. А еще не нанимают, например, слесарей и художников. Тоже проявляют враждебность? Это называется "подмена понятий".


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


Комментарий. Давайте применим эту логику к библиотекарям, которых не нанимают, и поймем всю абсурдность логических умопостроений.


Предотвращение проблем


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


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


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


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


А что насчёт ошибок, которые пробивают все установленные подстраховки? Думайте о них как о ценных возможностях укрепить вашу защиту. Младшие программисты, следует признать, обычно вскрывают подобные возможности быстрее, чем сеньоры. Так что встаёт вопрос: вы предпочтёте отладить свои процессы раньше или позже? «Никогда» не годится, как подтвердит любой опытный программист. Если что-то может пойти не так, рано или поздно оно пойдёт. Никакой запас опыта не предотвратит человеческой ошибки.


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


Само собой, вам понадобится несколько старших программистов и ops-лидов, чтобы заложить фундамент и создать прецеденты для отказоустойчивого цикла разработки. Никто не предлагает нанимать только младших программистов. Но если ваш офис действительно серьёзно относится к ошибкам — другими словами, ошибки отлавливаются рано и часто — то младшие программисты как раз пригодятся. И все уровни программистов будут больше удовлетворены своей работой, поскольку отказоустойчивость освобождает их для создания хорошего софта (вместо постоянного тушения пожаров) и охраняет их вечера и выходные.


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


Экономия денег


Согласно Indeed, средний Junior Software Engineer получает $55 394 в год, в то время как Senior Software Engineer — $117 374 в год. Сеньоры стоят более чем в два раза дороже, чем джуны.


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


Комментарий. Известно, что разница в продуктивности между разными программистами может достигать до 25 раз. Поэтому 2 раза просто ни о чем.


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


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


Не весь код приложения требует многих лет опыта для своего написания или даже для качественно выполненной работы. В каждой программе есть «программный клей», который соединяет различные входы и выходы вполне обыкновенным образом. В сущности, не важно, кто это напишет. Вы можете заплатить $28 в час за написание этого кода — или вы можете заплатить $59 в час написание того же кода. Так или иначе, результат будет мало отличаться. Если вы нанимаете только сеньоров, то вы платите втридорога за существенный объём простой работы.


Комментарий. Если в компании существенный объем работы достаточно тривиален, то тогда да. Но вряд ли тогда компания может считаться высокотехнологичной. Сложность инфраструктуры задает серьезный первоначальный барьер, с которым может не справиться (или справиться с трудом) младший разработчик.


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


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


Ранее упомянутый программный клей и предметно-ориентированный (domain-specific) код составляют по меньшей мере половину всей разработки. Оставшееся — тот код, который действительно нуждается во внимании старшего специалиста с пользой для результата. Но даже с этим кодом младший программист может проделать впечаляющую работу при достаточном доступе к образовательным ресурсам и советам опытного наставника.


Комментарий. Бывает, что на луне растут грибы. Аргументация в стиле "а может быть и так", она, конечно, может иметь место, но основание для этого я не вижу никаких.


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


Комментарий. А может и не стать.


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


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


Развитие карьер


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


Sometimes when companies say they're not hiring junior developers I want to shake them by their hoodies and yell, where do you think senior developers come from?!
— Kate Heddleston (@heddle317) 13 сентября 2018 г.

Иногда, когда компании говорят, что не нанимают младших программистов, мне хочется схватить их за грудки и закричать: а откуда, по-вашему, берутся старшие программисты?!

Комментарий. Если в компании нет младших разработчиков, то как им можно посылать сигнал? Посылать сигнал в таком случае можно лишь вовне. У автора имеются многочисленные проблемы с получением и интерпретацией сигнала. Я вот почему-то получаю сигнал такой: "рядом с тобой будут работать крутые специалисты, ты сможешь научиться очень многому, и тебе не нужно будет объяснять очевидное."


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


Комментарий. Без базара. Только за!


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


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


Но не замыкайтесь на этих ребятах. Их меньшинство. Большинство тружеников IT не собираются 40 лет оставаться старшими программистами. Они мечтают стать программными архитекторами, тимлидами, техническими директорами и основателями студий. А компания, которая кичится своим безразличием к росту карьеры, обнаружит себя внизу списка перспективых работодателей.


Комментарий. "Обнаружит себя внизу списка" — это про Netflix? Netflix topped a new list of “50 Best Places to Work for New Dads,” with several other Silicon Valley tech firms landing on the lineup and offering stiff competition to woo working fathers.


I only recruit senior devs.

The trick is, I recruit some of them earlier in their career.
— Reginald Braithwaite (@raganwald) 17 сентября 2018 г.

Я нанимаю только старших программистов.
Хитрость в том, что некоторых из них я нанимаю в начале карьеры.

Комментарий. Это самая офигенная хитрость. И я только за. Эти люди действительно решают и могут сделать многое для компании. Однако тут есть маленькая проблемка: как их найти? Примерно понятно, как увидеть в программисте "старшего": объем знаний у него в наличии. В перспективном начинающем программисте ты должен заглянуть в хрустальный шар и увидеть будущее. Я не встречал, чтобы такой подход хорошо масштабировался и работал в рамках большой компании. Это всегда риск и можно легко попасть в молоко.


Одна из самых впечатляющих фраз, которые программист может услышать на собеседовании — «Здравствуйте, я тимлид, проработал здесь восемь лет, начав с интерна». Очень впечатляет и очень большая редкость. Такой человек чрезвычаяно важен для компании — он знает всё о продуктовой линейке, он видел код всех проектов в радиусе ста метров, и он поработал со всеми сотрудниками компании. Он способен предлагать нововведения в рамках компании как никто другой. А компания зарабатывает несчётные дивиденды от труда этого человека, потому что смогла понять, как удержать его интерес восемь лет — примерно 1/10 средней продолжительности жизни. Это свидетельство успеха корпоративной культуры. Это признак офиса, в котором царит боевой дух, в котором признание находит всякую хорошо выполненную работу, а интересные проекты ждут за каждым поворотом.


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


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


Комментарий. Заявлять "Заявлять «мы не нанимаем джунов» — это, напротив, открытое признание, что компания не готова сыграть роль в чьей-либо карьере." — это открытое признание, что у автора проблемы с логическими цепочками и взаимосвязями.


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


Комментарий. Интересно, почему гугл и фейсбук имеют высокую планку? Наверно, они "сужают пайплайн (?) найма и укорачивают время сотрудников в компании".


Написание отличного софта


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


Комментарий. То ли дело "джуниор". Может наговнякать тонну неработающего бажного кода с незамутненным оптимизмом и отсутствием багажа без далекоидущих выводов. Просто мечта!


Companies so eager to only hire senior people often forget that unlearning what doesn't apply can take longer than learning what does.
— DHH (dhh) 31 июля 2017 г.

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

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


Иногда задача проект-менеджера — это сказать «Я знаю, что это не сработало там, но, может, сработает у нас». А младший программист — обычно лучший кандидат, чтобы проверить такую теорию: он может собрать пробу идеи или прототип, не втягивая в это предрассудки, накопленные старшим программистом за годы. В качестве младшего программиста я часто выполнял такую работу, проверяя новые инструменты и технологии, переписывая фрагменты кода альтернативным образом, испытывая идеи, которые другие сотрудники поспешно отмели. Я часто открывал улучшения архитектуры, и софт компании становился осязаемо лучше. В некоторых случаях удавалось ускорить загрузку страницы на порядок; или несколько страниц соединить в одну, избежав недель поддержки в будущем; или избавиться от неэффективных технологий, которые привели бы к потере времени. Подобные преимущества неотягощённого, свежего взгляда нельзя упускать.


Комментарий. Зависит от многих обстоятельств. Автору просто повезло самому с собой. По опыту могу сказать, что часто это не работает.


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


Комментарий. Также можно убедиться в том, как легко отличный продукт превращается в помойное ведро. Достаточно вспомнить про Borland.


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


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


One underrated programmer attribute is the ability to write code that average or mediocre engineers can easily read, modify, and extend.
— Jamon Holmgren (@jamonholmgren) 17 сентября 2018 г.

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

Комментарий. Во истину!


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


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


Подводя итог: широко распространённый в IT принцип «только сеньоры» недооценивает младших программистов. Это плохо сказывается на всех, особенно когда организация считает, что без начинающих специалистов всё будет даваться легче. Хотя некоторые подобные компании финансово успешны, можно представить себе колоссальные растраченные суммы которые приходится сносить их бюджету из-за такого подхода.


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


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


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



Выводы


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


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


Я не против джунов. Сам когда-то был таким. Джуны офигенны. Иногда смотришь на начинающего программиста и понимаешь, что тебе тут будет делать нечего после того, когда он подрастет. Ну а пока поработаю немножко.


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


P.S. Заметили большую и глупую ошибку, о которой говорил автор в начале статьи?