Позвольте рассказать вам историю об одной очень успешной компании, совершившей большую, глупую ошибку:
Я был совершенно поражён, как некое корпоративное нечто умудрилось представить щенков в отрицательном свете, да ещё кого-то этим убедило. Щенки — самые чистые создания на Земле, живая пушистая радость! Лучики света в одиноком мире. Но перейдём к сути.
Многие компании последовали данной стратегии «нанимать только сеньоров». Они обосновывают это так:
Посыл состоит в том, что младшие программисты представляют собой риск, некий шаг, на который компания идёт либо из чувства общественного долга, либо из-за нехватки бюджета. Получается, что другие компании, должно быть, могут позволить себе корпоративную благотворительность и второсортные результаты, но уж точно не мы.
Кстати говоря, в США более 100 000 IT-компаний, и что-то я не слышал, чтобы хоть один CEO сказал «подумаешь, ошибки!» или «надо бы спустить куда-нибудь лишний бюджет». Так что внимание, организации, где «джунам вход воспрещён»! Какими бы вы ни видели свои выгоды, как бы вы ни обосновывали свой лайфхак, реальность такова, что вы всё это себе выдумали. Нет никакого конкурентного преимущества в избавлении от джунов. И вы только что продемонстрировали миру свой проблемный менеджмент.
То, как вы нанимаете и обращаетесь с младшими программистами — важный косвенный показатель здоровья вашей организации, вашей линейки продуктов и вашей внутренней культуры. Сеньоры обращают на это внимание. И если одно это не звучит достаточно убедительно, то найм взвешенного количества младших программистов также даёт финансовые преимущества.
Если вы отказываете младшим программистам потому, что они «создают проблемы», то вы также машинально посылаете сотрудникам важное сообщение насчёт корпоративной культуры: ошибки недопустимы. Вы создаёте образ компании, которая увольняет кого-нибудь всякий раз, когда ложится сервер. Сколько бы вы ни платили, никто не хочет работать в среде, которая не даёт уверенности в завтрашнем дне. И попытки запугать программистов, чтобы те не совершали ошибок, множит культуру страха и угроз, что катастрофически сказывается на психологическом здоровье и продуктивности.
Вы можете возразить, что такое отношение побуждает программистов проявлять осторожность и создавать процессы, защищающие от ошибок: например, автоматическое тестирование, QA, аварийное переключение, защита доступа и обратимые правки кода. Но данная теория ставит телегу впереди лошади. Если политика компании побуждает создание подобных подстраховок и компания сама предоставляет программистам достаточно времени и ресурсов для этого, тогда культура недопустимости ошибок не нужна и бесполезна; большинство проблем будет отловлено задолго до продакшена. И каждый программист, будь он младший или старший, предпочитает среду, где надёжные процессы защищают от катастрофических ошибок.
А что насчёт ошибок, которые пробивают все установленные подстраховки? Думайте о них как о ценных возможностях укрепить вашу защиту. Младшие программисты, следует признать, обычно вскрывают подобные возможности быстрее, чем сеньоры. Так что встаёт вопрос: вы предпочтёте отладить свои процессы раньше или позже? «Никогда» не годится, как подтвердит любой опытный программист. Если что-то может пойти не так, рано или поздно оно пойдёт. Никакой запас опыта не предотвратит человеческой ошибки.
Само собой, вам понадобится несколько старших программистов и ops-лидов, чтобы заложить фундамент и создать прецеденты для отказоустойчивого цикла разработки. Никто не предлагает нанимать только младших программистов. Но если ваш офис действительно серьёзно относится к ошибкам — другими словами, ошибки отлавливаются рано и часто — то младшие программисты как раз пригодятся. И все уровни программистов будут больше удовлетворены своей работой, поскольку отказоустойчивость освобождает их для создания хорошего софта (вместо постоянного тушения пожаров) и охраняет их вечера и выходные.
Согласно Indeed, средний Junior Software Engineer получает $55 394 в год, в то время как Senior Software Engineer — $117 374 в год. Сеньоры стоят более чем в два раза дороже, чем джуны.
Эти затраты часто оправданы. От старших программистов ожидается бОльшая продуктивность, чем от младших. Но этим картина не исчерпывается, и вам встанет в копеечку бездумное и ленивое обосновывание повышенных затрат как издержек ведения дел.
Не весь код приложения требует многих лет опыта для своего написания или даже для качественно выполненной работы. В каждой программе есть «программный клей», который соединяет различные входы и выходы вполне обыкновенным образом. В сущности, не важно, кто это напишет. Вы можете заплатить $28 в час за написание этого кода — или вы можете заплатить $59 в час написание того же кода. Так или иначе, результат будет мало отличаться. Если вы нанимаете только сеньоров, то вы платите втридорога за существенный объём простой работы.
Кроме того, кодовая база значительно разнится между приложениями, и знакомство с ней — ключевой фактор в продуктивности. В большинсте случаев младший программист, проработавший в команде полгода, будет эффективней справляться с задачами, чем только что нанятый старший программист — просто из-за степени знакомства с логикой проекта.
Ранее упомянутый программный клей и предметно-ориентированный (domain-specific) код составляют по меньшей мере половину всей разработки. Оставшееся — тот код, который действительно нуждается во внимании старшего специалиста с пользой для результата. Но даже с этим кодом младший программист может проделать впечаляющую работу при достаточном доступе к образовательным ресурсам и советам опытного наставника.
Ввиду этого пара из младшего и старшего программиста обычно работает с эффективностью двух старших программистов и менее чем за 75% стоимости. Если ваша цель — максимальная продуктивность с минимальными затратами, то такая пара джун+сеньор должна стать фундаментальной молекулой вашей организации.
Стоит отметить ещё один, неизмеримый фактор: тенденцию старших программистов к постоянным спорам на темы, которые в конечном итоге ничтожны — про алгоритмы, микрооптимизации и стиль кода. Если компания нанимает только сеньоров и не имеет при этом жёсткого процесса принятия решений, то сотни рабочих часов могут уйти на подобные споры. Младшие разработчики обычно лишены такой проблемы.
Если вы не нанимаете младших программистов, то посылаете ещё одно сообщение сотрудникам — что вы не знаете, как устроено развитие карьеры.
Опять же, речь не об исполнении корпоративного гражданского долга и не об «участии в развитии» IT-сообщества. Речь о превращении вашей компании в достойное рабочее место, куда программисты захотят устроиться и остаться достаточно надолго, чтобы внести ощутимый вклад.
Мне случалось слышать от программистов: «Надоело менять названия должностей. Я просто хочу навсегда уже остаться старшим программистом.» Однако никто ещё мне не говорил: «Надеюсь, я больше никогда не получу прибавку к зарплате, не узнаю ничего нового и не буду признан за свои заслуги». И, как ни странно, ресурсы, необходимые для поддержания и амбициозных карьеристов, и усидчивых, но увлечённых старших программистов примерно одинаковы. Необходимы способы изменения и признания хорошо сделанной работы, достаточный объём образовательных ресурсов и разнообразие проектов разного возраста в пайплайне разработки. Вам нужно создать чувство развития, даже для тех, кого продвижение по службе не интересует.
Но не замыкайтесь на этих ребятах. Их меньшинство. Большинство тружеников IT не собираются 40 лет оставаться старшими программистами. Они мечтают стать программными архитекторами, тимлидами, техническими директорами и основателями студий. А компания, которая кичится своим безразличием к росту карьеры, обнаружит себя внизу списка перспективых работодателей.
Одна из самых впечатляющих фраз, которые программист может услышать на собеседовании — «Здравствуйте, я тимлид, проработал здесь восемь лет, начав с интерна». Очень впечатляет и очень большая редкость. Такой человек чрезвычаяно важен для компании — он знает всё о продуктовой линейке, он видел код всех проектов в радиусе ста метров, и он поработал со всеми сотрудниками компании. Он способен предлагать нововведения в рамках компании как никто другой. А компания зарабатывает несчётные дивиденды от труда этого человека, потому что смогла понять, как удержать его интерес восемь лет — примерно 1/10 средней продолжительности жизни. Это свидетельство успеха корпоративной культуры. Это признак офиса, в котором царит боевой дух, в котором признание находит всякую хорошо выполненную работу, а интересные проекты ждут за каждым поворотом.
Заявлять «мы не нанимаем джунов» — это, напротив, открытое признание, что компания не готова сыграть роль в чьей-либо карьере. Это фактически демонстрация стагнации: компания хочет привлечь опытных и талантливых программистов, которые будут совершать свой вклад ради одного лишь оклада. Некоторые согласятся на такие условия, но их лучшей работы вы так и не увидите.
Однако если ваша компания действительно серьёзно относится к карьерному росту, то искусственное ограничение на младших программистов лишь сужает пайплайн найма и укорачивает время сотрудников в вашей компании.
У младших программистов есть ряд уникальных черт, которые их более опытные коллеги обычно утратили. Одна из них — незамутнённый оптимизм. Другая — готовность идти за лидером. Но, возможно, самая важная черта, которую предлагают младшие программисты — это отсуствие багажа. Старшие программисты видели восход и закат технологий, провалы проектов, команды, раздираемые внутренними конфликтами, и прочий быт IT-отрасли. Они накопили строгие убеждения и часто делают чересчур далекоидущие выводы, предполагая, что один сценарий успеха (или провала) развернётся точно так же и для другого проекта или команды. Что может привести к нежеланию разбираться в нюансах нового поля проблем.
Иногда задача проект-менеджера — это сказать «Я знаю, что это не сработало там, но, может, сработает у нас». А младший программист — обычно лучший кандидат, чтобы проверить такую теорию: он может собрать пробу идеи или прототип, не втягивая в это предрассудки, накопленные старшим программистом за годы. В качестве младшего программиста я часто выполнял такую работу, проверяя новые инструменты и технологии, переписывая фрагменты кода альтернативным образом, испытывая идеи, которые другие сотрудники поспешно отмели. Я часто открывал улучшения архитектуры, и софт компании становился осязаемо лучше. В некоторых случаях удавалось ускорить загрузку страницы на порядок; или несколько страниц соединить в одну, избежав недель поддержки в будущем; или избавиться от неэффективных технологий, которые привели бы к потере времени. Подобные преимущества неотягощённого, свежего взгляда нельзя упускать.
Многие компании могут позволить себе такую расточительность, как решение проблемы или написание кода методом запирания нескольких старших программистов в переговорке, чтобы к чему-нибудь пришли. Но если туда добавить несколько джунов — то есть разработчиков, чьё время допустимо потратить на разовые эксперименты и необычные идеи — то можно убедиться, какие улучшения это даст вашим продуктам.
Что касается качества софта, младшие программисты обычно выполняют важную работу, которую мало кто замечает: они сдерживают заумный, перемудрённый код, который склонны писать их старшие коллеги.
Если заменить «средний или посредственный» на «младший», то сразу увидите систему. Кодовая база — абстрактный отпечаток критического мышления своих авторов. Здравое сочетание младших и старших программистов создаёт возможность для упрощения кода, которое ускоряет написание фич с течением времени.
Подводя итог: широко распространённый в IT принцип «только сеньоры» недооценивает младших программистов. Это плохо сказывается на всех, особенно когда организация считает, что без начинающих специалистов всё будет даваться легче. Хотя некоторые подобные компании финансово успешны, можно представить себе колоссальные растраченные суммы которые приходится сносить их бюджету из-за такого подхода.
Если ваша компания обгоняет конкурентов по данному вопросу — то есть знает, как нанимать, обучать и удерживать младших программистов — то вы сами уже ощущаете все те преимущества, которые я лишь поверхностно описал в данной статье. У вас ниже текучка, выше разнообразие специалистов и меньше оверхеда, чем у конкурентов. В вашем софте меньше багов и больше радости. Есть, конечно, и другие факторы. Но положительный подход к младшим программистам — важный знак качества офиса на всех уровнях.
Мы не нанимаем младших программистов и интернов… Если не заводить щенка, не придётся убирать лужи.
--Netflix
Я был совершенно поражён, как некое корпоративное нечто умудрилось представить щенков в отрицательном свете, да ещё кого-то этим убедило. Щенки — самые чистые создания на Земле, живая пушистая радость! Лучики света в одиноком мире. Но перейдём к сути.
Многие компании последовали данной стратегии «нанимать только сеньоров». Они обосновывают это так:
- У нас нет времени и ресурсов нанимать младших программистов; мы слишком быстро развиваемся.
- Наша компания может себе позволить сеньоров, так что в джунах нет необходимости.
- На текущем этапе мы не можем позволить себе ошибки. Ставки слишком высоки.
- Наш процесс предоставляет сотрудникам большую автономность. Мы не готовы держать джунов за ручку, как они в том нуждаются.
- Мы хотим заложить фундамент продукта прежде, чем начнём нанимать неопытных сотрудников.
Посыл состоит в том, что младшие программисты представляют собой риск, некий шаг, на который компания идёт либо из чувства общественного долга, либо из-за нехватки бюджета. Получается, что другие компании, должно быть, могут позволить себе корпоративную благотворительность и второсортные результаты, но уж точно не мы.
Кстати говоря, в США более 100 000 IT-компаний, и что-то я не слышал, чтобы хоть один CEO сказал «подумаешь, ошибки!» или «надо бы спустить куда-нибудь лишний бюджет». Так что внимание, организации, где «джунам вход воспрещён»! Какими бы вы ни видели свои выгоды, как бы вы ни обосновывали свой лайфхак, реальность такова, что вы всё это себе выдумали. Нет никакого конкурентного преимущества в избавлении от джунов. И вы только что продемонстрировали миру свой проблемный менеджмент.
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 в год. Сеньоры стоят более чем в два раза дороже, чем джуны.
Эти затраты часто оправданы. От старших программистов ожидается бОльшая продуктивность, чем от младших. Но этим картина не исчерпывается, и вам встанет в копеечку бездумное и ленивое обосновывание повышенных затрат как издержек ведения дел.
Не весь код приложения требует многих лет опыта для своего написания или даже для качественно выполненной работы. В каждой программе есть «программный клей», который соединяет различные входы и выходы вполне обыкновенным образом. В сущности, не важно, кто это напишет. Вы можете заплатить $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 лет оставаться старшими программистами. Они мечтают стать программными архитекторами, тимлидами, техническими директорами и основателями студий. А компания, которая кичится своим безразличием к росту карьеры, обнаружит себя внизу списка перспективых работодателей.
I only recruit senior devs.
— Reginald Braithwaite (@raganwald) 17 сентября 2018 г.
The trick is, I recruit some of them earlier in their career.
Я нанимаю только старших программистов.
Хитрость в том, что некоторых из них я нанимаю в начале карьеры.
Одна из самых впечатляющих фраз, которые программист может услышать на собеседовании — «Здравствуйте, я тимлид, проработал здесь восемь лет, начав с интерна». Очень впечатляет и очень большая редкость. Такой человек чрезвычаяно важен для компании — он знает всё о продуктовой линейке, он видел код всех проектов в радиусе ста метров, и он поработал со всеми сотрудниками компании. Он способен предлагать нововведения в рамках компании как никто другой. А компания зарабатывает несчётные дивиденды от труда этого человека, потому что смогла понять, как удержать его интерес восемь лет — примерно 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 г.
Компании, жаждущие нанимать только старших специалистов, часто упускают из виду, что забыть лишнее — зачастую сложнее, чем выучить нужное.
Иногда задача проект-менеджера — это сказать «Я знаю, что это не сработало там, но, может, сработает у нас». А младший программист — обычно лучший кандидат, чтобы проверить такую теорию: он может собрать пробу идеи или прототип, не втягивая в это предрассудки, накопленные старшим программистом за годы. В качестве младшего программиста я часто выполнял такую работу, проверяя новые инструменты и технологии, переписывая фрагменты кода альтернативным образом, испытывая идеи, которые другие сотрудники поспешно отмели. Я часто открывал улучшения архитектуры, и софт компании становился осязаемо лучше. В некоторых случаях удавалось ускорить загрузку страницы на порядок; или несколько страниц соединить в одну, избежав недель поддержки в будущем; или избавиться от неэффективных технологий, которые привели бы к потере времени. Подобные преимущества неотягощённого, свежего взгляда нельзя упускать.
Многие компании могут позволить себе такую расточительность, как решение проблемы или написание кода методом запирания нескольких старших программистов в переговорке, чтобы к чему-нибудь пришли. Но если туда добавить несколько джунов — то есть разработчиков, чьё время допустимо потратить на разовые эксперименты и необычные идеи — то можно убедиться, какие улучшения это даст вашим продуктам.
Что касается качества софта, младшие программисты обычно выполняют важную работу, которую мало кто замечает: они сдерживают заумный, перемудрённый код, который склонны писать их старшие коллеги.
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 принцип «только сеньоры» недооценивает младших программистов. Это плохо сказывается на всех, особенно когда организация считает, что без начинающих специалистов всё будет даваться легче. Хотя некоторые подобные компании финансово успешны, можно представить себе колоссальные растраченные суммы которые приходится сносить их бюджету из-за такого подхода.
Если ваша компания обгоняет конкурентов по данному вопросу — то есть знает, как нанимать, обучать и удерживать младших программистов — то вы сами уже ощущаете все те преимущества, которые я лишь поверхностно описал в данной статье. У вас ниже текучка, выше разнообразие специалистов и меньше оверхеда, чем у конкурентов. В вашем софте меньше багов и больше радости. Есть, конечно, и другие факторы. Но положительный подход к младшим программистам — важный знак качества офиса на всех уровнях.
