Писать код — несложно, сложно писать хороший код.

Когда мне было 19 лет, я бросила колледж и переехала в Сан-Франциско. Там я должна была выйти на работу сисадмином Unix в Taos Consulting. Но я не успела приступить — меня тут же переманил один стартап, где я стала работать разработчиком почтовых подсистем.

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

Была ли я гением, родившимся в обнимку с компьютерной клавиатурой? Конечно, нет. Я жила на задворках Айдахо и училась дома. Впервые прикоснулась к компьютеру в шестнадцать лет, когда пошла в колледж. Попала в университет благодаря стипендии по программе классического фортепиано, чуть позже разменяв его на вереницу гуманитарных дисциплин: классический греческий и латынь, теория музыки, философия. Всё, что я узнала о компьютерах, я узнала на работе, будучи системным администратором на кафедре информатики в университете.

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

ИТ взрослеет

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

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

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

Разработка ПО — это отрасль постоянного ученичества

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

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

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

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

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

Что значит быть сеньором

Часто слышу возмущённые возражения по поводу сроков, например:

«Семь лет?! Да мне хватило два года!»

«А я стал сеньором всего через четыре с половиной года!»

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

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

Для меня концепция сеньора в основном не завязана на способности писать код. Для сеньора скорее важно умение понимать, поддерживать, объяснять и управлять большим корпусом ПО в продакшне на протяжении долгого времени, а также способность трансформировать потребности бизнеса в технические решения. Огромная часть работы строится вокруг создания и поддержки больших, сложных социотехнических систем, а код — всего лишь одно из представлений этих систем.

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

И это плавно подводит нас к вопросу об ИИ.

Перестаньте разрушать собственное будущее

Очень, действительно очень трудно впервые устроиться на работу разработчиком. Я не осознавала, насколько это трудно, пока моя младшая сестра не начала искать работу. Недавней выпускнице, отличнице, с небольшим практическим опытом, трудолюбивой и дружелюбной, понадобилось два (!) года, чтобы закрепиться на работе в своей сфере. Это было несколько лет назад. Как ни парадоксально, с тех пор устроиться на работу стало ещё сложнее.

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

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

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

Не нанимая и не обучая джунов, мы разрушаем собственное будущее. 

Это надо остановить.

Писать код — это самое простое

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

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

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

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

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

Писать код — несложно, сложно писать хороший код

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

Правильнее было бы относиться к инструментам вроде Copilot, как к прикольной функции автодополнения или копипаста или как к детищу порочной страсти результатов поиска Stack Overflow и гугловского «Мне повезёт!». Каждый раз идёшь ва-банк.

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

Но сгенерированному коду нельзя доверять. Я не устаю повторять это снова и снова. 

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

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

Возможно, вам удастся сэкономить время, не создавая код с нуля. Но вам придётся проверить результат строчка за строчкой и только потом закоммитить его или отправить в продакшн. Во многих случаях это занимает времени не меньше, чем само написание кода — особенно в наши дни, когда у нас в распоряжении такие продвинутые возможности автодополнения. Чтобы код, сгенерированный искусственным интеллектом, привести в соответствие с остальной базой кода, иногда нужно проделать ОГРОМНУЮ работу. Откровенно говоря, часто овчинка выделки не стоит.

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

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

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

Например, можно попросить ChatGPT сгенерировать образец кода с использованием незнакомых API. Это проще, чем читать документацию по API — в конце концов, корпус обучался на репозиториях, в которых API использовались для реальных рабочих нагрузок.

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

Генеративный ИИ спокойно справится с задачей, если вам нужно эффективно копировать и вставлять данные в шаблон — как если бы вы каждый раз генерировали нужный код с использованием sed/awk или макроса vi.

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

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

Генеративный ИИ чем-то напоминает джуна

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

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

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

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

Одноразовый код — это редкость; код, который должен прослужить многие годы — норма. 

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

Но генеративный ИИ — не часть вашей команды

На код, который генерирует GenAI, нельзя положиться, в этом плане он действительно как джун. Но это единственный момент, в котором это сравнение верно. Потому что взять в команду человека, который пишет код — совершенно не то же самое, что создавать код автоматически. Такой код можно получить откуда угодно: из Stack Overflow, Copilot, мало ли откуда ещё. Да и это даже неважно. В таком случае у вас нет циклов обратной связи, на другом конце провода нет человека, который постепенно учится и работает над собой, нет влияния на вайб и культуру вашей команды.

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

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

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

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

Мы недооцениваем стоимость найма сеньоров и переоцениваем стоимость найма джунов

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

Вот упрощённый взгляд на вещи вашего бухгалтера: «Зачем платить $100k джуну и снижать общую скорость работы, если можно платить $200k сеньору, чтобы дела шли быстрее?» Это же бессмыслица!

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

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

Каждому разработчику, которого вы берёте на работу, нужно время и помощь с адаптацией, прежде чем его работа начнёт приносить ощутимый вклад в общее дело. Нанимать и обучать разработчиков — дорого, независимо от их уровня. Любому сеньору нужно время, чтобы сформировать в уме представление о системе, ознакомиться с инструментами и технологиями и выйти на нужную скорость. Сколько времени? Это зависит от наличия у сеньора опыта работы с вашими инструментами и технологиями, от того, насколько хорошо и понятно организована ваша база кода, налажен процесс онбординга, и от других факторов. В целом эта адаптация растягивается на 6–9 месяцев. Не исключено, что сеньор выйдет на свою полную мощь только где-то через год.

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

Необязательно быть сеньором, чтобы создавать ценность

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

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

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

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

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

Аргументы в пользу найма джунов в долгосрочной перспективе

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

1. Нам нужно больше сеньоров в отрасли.

2. И кто-то должен их вырастить.

3. Работа джунов дешевле.

4. Они могут привнести столь необходимое разнообразие.

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

6. Мы уже упоминали, что кто-то должен взять это на себя?

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

Аргументы в пользу найма джунов в краткосрочной перспективе

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

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

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

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

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

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

В здоровой высокоэффективной команде есть сотрудники разных уровней

Здоровая команда — это экосистема. Вы же не составляете команду по разработке продукта из шести спецов по БД и одного мобильного разработчика. Не стоит также формировать команду из шести сеньоров и одного джуна. Хорошая команда включает специалистов с разными навыками и грейдами.

Вы когда-нибудь работали в команде, состоящей исключительно из ведущих или главных инженеров-программистов? Не то чтобы там было весело. Это неэффективная команда. Объём работы по созданию и планированию высокоуровневой архитектуры ограничен, как и количество больших решений, которые нужно принимать. Ведущие инженеры бо́льшую часть времени занимаются скучной и рутинной работой, так что они склонны слишком усложнять решения либо, наоборот, слишком всё упрощать, а иногда и то и другое одновременно. Они соревнуются друг с другом ради фана и придумывают поводы для технических стычек. Они вечно что-то не задокументируют и недостаточно вкладываются в то, что делает системы простыми и управляемыми.

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

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

Узкое место компании — это наём, а не обучение сотрудников

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

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

После первого места работы разработчику, как правило, несложно трудоустроиться. Но найти первую работу — это смертоубийство. Это почти невозможно. Если только вы не окончили один из лучших вузов страны и не попали на стажировку в Big Tech, то это лотерея чистой воды, вопрос удачи или личных связей. Это было тяжело ещё до того, как химера «искусственный интеллект может заменить джунов» вылезла из болота. А уж теперь-то... Вообще ужас.

Где бы вы были, если бы не попали в ИТ в своё время?

Я знаю, где была бы я, и это точно не здесь.

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

Никто не считает, что нам нужно меньше сеньоров

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

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

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

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

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

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

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

Должна ли каждая компания брать на работу джунов

Нет. Компания должна быть в состоянии обеспечить джунам успех. 

Признаки, которые говорят о том, что вашей компании НЕ нужно нанимать джунов:

• Вы существуете меньше двух лет.

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

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

• В компании нет графика разработки продукта.

• У вас в команде никто не хочет отвечать за джунов и быть их наставником.

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

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

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

Никто не придёт и не решит за нас наши проблемы

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

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

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

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

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

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

---

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

• Как начать работать с нейросетями и создать свой ChatGPT;

• За кем будут охотиться работодатели: профессии, актуальные в 2030 году;

• Делегирование: как руководителю научиться ставить задачи;

• 5 шагов, которые помогут найти работу после обучения;

• Soft skills: ключевые навыки для успешной карьеры.

Или открыть перспективы и получить повышение с профессиональным обучением и переподготовкой:

• Нейросети для каждого: как решать рабочие задачи быстрее;

• DevOps-инженер;

• Mini-MBA: Управление проектами и командами в IT;

• HR-аналитика и автоматизация;

• Deep Learning.