[Перевод] Разработчики программного обеспечения скоро перестанут писать код
Размышления о том, куда ведет карьерная лестница современных программистов.
Путь джуна
С чего начинается путь младшего разработчика? Итак, представьте: вот он делает свои первые шаги в профессиональном программировании — сидя за рабочим столом, наколачивает тысячи строк кода в месяц.
Он хорошо справляется с работой, пишет неплохой код и начинает завоевывать доверие коллег. Спустя некоторое время его уже приглашают на совещания по проектам. Руководитель поручает ему все более комплексные и масштабные задачи.
Тут-то и начинаются первые серьезные изменения. Вместо того, чтобы давать четко сформулированные и точно очерченные задачи, ему делегируют написание проектной документации с описанием проблемных областей и возможных решений. Постепенно время, которое он тратит на кодинг, сокращается с 90% до 80–70%.
И вот наш паренек встал на крыло. Он ведет множество собственных проектов и принимает все большее участие в работе коллег. С ростом его профессиональных навыков список предлагаемых им фич растет быстрее, чем он успевает их реализовать. Заметивший это начальник предлагает взять в помощь еще кого-нибудь из команды. Но есть нюанс: проработать и спланировать все будущие задачи необходимо заранее. Наш герой с радостью соглашается, расписывает и передает дюжину задач своему коллеге.
А как обстоят дела с кодингом?
Несмотря на то, что ему по-прежнему нравится кодить, он начинает все реже открывать VSCode и все чаще — Google Docs. Хорошо это или плохо, но он повторяет путь многих программистов, и мой в том числе. По мере накопления опыта моя производительность стала измеряться не столько строчками кода, сколько навыками управления крупными проектами и командой.
Даже если я каким-то чудом избавлюсь от руководительских обязанностей, вряд ли мне когда-нибудь снова удастся посвящать кодингу 90% своего времени. Жонглирование обязанностями неизменно увеличивает потребность в совместной работе и тотальной прозрачности процесса для всех членов команды, партнеров и других заинтересованных сторон. Ни у кого не хватит времени, чтобы делать все самостоятельно.
Что я могу с этим поделать?
Когда мне на работе предлагают дополнительные обязанности, я вижу два варианта развития событий: либо оседлать эту новую волну и постараться ее обуздать, либо вернуться к уютному рабочему месту VSCode. Ни один из этих вариантов не является по своей сути правильным или неправильным. Только вы сами можете сделать выбор, опираясь на свои опыт и зрелость. Лично мне в прошлом году пришлось чередовать первый и второй варианты.
Мой путь
В первый рабочий день 2022 года я присоединилась к новой команде в Meta (признана экстремистской организацией и запрещена в РФ). Я четко заявила своему новому руководителю, что хочу развивать навыки, выходящие за рамки моей области знаний (UX). Я хотела глубже погрузиться в бэкэнд и развивать новые скиллы. Признаюсь честно, помимо всего прочего так я планировала побороть синдром самозванца, который появился у меня после работы на столь высоком технологическом уровне.
Через шесть месяцев работы в новой команде руководитель поручил мне критически важный внутренний проект, связанный с обеспечением конфиденциальности, который нужно было реализовать к концу этого года. Не буду углубляться, но вскоре после моего прихода произошла поломка, и у команды ушло два месяца на отладку сквозных зависимостей. Однажды мне пришлось на целый день нырнуть в C++ только для того, чтобы отправить запрос на внесение изменений в кодовую базу другой команды.
Затем, во время дебаггинга в рамках проекта по конфиденциальности, команда партнеров подала приоритетный тикет в отношении нашего пользовательского интерфейса. Функция, которую я поддерживала, вылетала с out of memory ошибкой. Поскольку оба проекта были на грани, моя зона комфорта сказала «прости-прощай».
После того, как с проблемой было покончено, я объяснила своему техническому руководителю, что в течение последних нескольких недель занималась оптимизацией запросов пользовательского интерфейса. У меня было понимание, что нужно сделать, но тем не менее я не могла найти времени, чтобы довести все до конца.
Он предложил мне возглавить работу по устранению оставшихся проблем с производительностью UI. Однако я отказалась. Я хотела сосредоточиться на внутреннем проекте, который мне доверили. Даже несмотря на то, что план проекта по конфиденциальности был составлен с большим запасом, я опасалась, что, взяв на себя большую ответственность, я подведу его под большой риск. Я боялась, что в случае неудачи я навсегда останусь в роли «простого» UX-специалиста.
Когда босс предложил мне взять на себя работу по созданию нового пользовательского интерфейса, я снова отказалась. Я уже понимала проблему UI и хотела расти в техническом направлении. Фактически мой отказ означал бы, что вместо меня проект возьмет кто-то другой. И он воспользуется им для повышения квалификации и получит «галочку» в портфолио. Что ж, почему бы и нет.
Да, в тот день я предпочла уютное офисное кресло надвигающейся волне. У меня были причины отказаться от возросшей ответственности. Отчасти это был страх, а отчасти — непонимание, чего от меня добивался мой начальник.
Да, я могла простыми словами описать проблему, первопричину и даже обозначить решение для большинства вопросов, связанных с производительностью пользовательского интерфейса. В них была определенная закономерность. Поэтому я решила, что справедливо будет позволить кому-то другому решить оставшиеся задачи. Я окажу своему преемнику услугу. «Научу человека ловить рыбу», как говорится.
Несколько месяцев я осознала, что начальник хотел, чтобы я без фактического внедрения исправлений продемонстрировала, что разбираюсь в своей области знаний. Я могла бы расписать ряд задач и с определенной периодичностью публиковать внутренние сообщения о ходе работы над пользовательским интерфейсом.
Босс был прекрасно осведомлен о моих карьерных целях, лежащих за пределами расширения технического кругозора. Поэтому он хотел получить подробный письменный отчет о проблеме. Работа над UI отняла бы еще больше моего времени (которого, к слову, и так было немного). С другой стороны, эта работа позволила бы мне почувствовать хоть какую-то отдачу, пока проект по конфиденциальности вовсю буксовал.
О чем я думаю, оглядываясь назад? Если бы можно было вернуться в прошлое, я бы взяла на себя дополнительные задачи по UI, чтобы увеличить свои шансы на повышение. Но в то же время я чувствовала бы себя не в своей тарелке. Признаюсь, вовремя сказать «нет» — это важный навык, который требует определенной тренировки. Однако ни в коем случае нельзя жалеть о том, что ты вовремя отказался и сумел позаботиться о своем психическом здоровье.
Через несколько месяцев после моего, признаюсь, обескураживающего решения в команде появился новичок — девушка пришла к нам сразу после колледжа. Босс попросил меня ввести ее в курс дела, чтобы я могла высвободить часть своего рабочего времени, поручив ей некоторые задачи.
Сейчас, когда задачи по обеспечению конфиденциальности закрыты в срок, я с нетерпением жду, когда возглавлю еще более масштабный проект по бэкенду, где будет еще больше нового и неизведанного. На сей раз под моим руководством будут работать два человека. И снова моя зона комфорта останется где-то далеко позади. Однако я смирилась с тем, что жить с определенным дискомфортом — это часть моего пути.
Почему вы не пишете код
Написание кода никогда не будет занимать 100% вашего времени. Даже у начинающих программистов будут встречи, на которых им придется присутствовать, и задачи, не связанные с непосредственно с кодом. По мере того, как вы будете продвигаться по карьерной лестнице, работы, не связанной с программированием, будет становиться все больше. И это не только совещания и звонки.
Написание проектной документации
По мере того как задачи, которыми вы занимаетесь, становятся все более масштабными, сложными и многогранными, вам придется начать работать с проектной документацией. Там вы будете собирать требования, проводить анализ или исследования и делиться своими выводами с другими участниками проекта и коллегами.
Джуниоры: не пренебрегайте этим шагом. Заманчиво сразу погрузиться в код, но иногда нужно сбавить обороты, чтобы потом разогнаться. Иными словами, «два часа планирования могут сэкономить вам две недели кодинга».
Примерить чужую роль
Команды разработчиков ПО будут регулярно сталкиваться с нехваткой каких-либо навыков. Например, вам будет не хватать межфункционального сопровождения в формате менеджмента проектов, дизайна продуктов и т.д. Скорее всего, вам понадобится овладеть необходимыми навыками в смежных областях, например, в управлении, — это поможет грамотно устанавливать сроки и выполнять другие задачи, связанные с контролем реализации проекта.
Например, в Meta (признана экстремистской организацией и запрещена в РФ) существует культура «снизу вверх»: решения о том, какие задачи будут реализованы, принимаются непосредственно инженерами. Как правило, мы сами являемся руководителями проектов. Например, я провела последнюю неделю, сводя воедино заметки, результаты проведенных ранее исследований и поставленные цели в новый план работы над проектом на 2023 год.
Наставничество в команде
Когда вы наберетесь опыта, вас попросят взять на себя работу с новыми сотрудниками, включая менторство над младшими специалистами. Работа в качестве наставника улучшит ваши коммуникативные навыки и повысит шансы на продвижение по службе.
Советы, как стать толковым наставником в области разработки ПО, были подробно описаны в других статьях, поэтому здесь я приведу лишь некоторые из них.
- Делегируйте — дайте новичкам или младшим сотрудникам возможность учиться под вашим руководством. Создавайте четко определенные и хорошо спланированные задачи, исключая любую неопределенность (но только на первых порах).
- Поощряйте — примите тот факт, что новый сотрудник не будет писать код точно так же, как это сделали бы вы. Оставьте пространство для творчества, при этом не забывая про командные стандарты. Соблюдайте баланс между позитивной и конструктивной обратной связью в их код-ревью.
- Регулярно встречайтесь 1 на 1 — в течение первых нескольких месяцев беседуйте по 15–30 минут еженедельно или раз в две недели, в зависимости от потребностей нового сотрудника. Фиксируйте любые возникающие у новичка сложности и при необходимости сообщайте о них своему руководителю или техническому директору.
Заключение
Недавний успех ChatGPT заставляет программистов снова рассуждать о том, заменят ли их ИИ и когда это случится. Однако мы, разработчики, уже заменяем сами себя в рамках цикла развития карьеры программиста. С каждой новой должностью программист все дальше уходит от редактора кода, приближаясь к конференц-залу.
Молодые разработчики программного обеспечения находятся всего в нескольких годах от того, чтобы почти полностью отказаться от написания кода. Такое изменение должностных обязанностей может вызвать недовольство и ностальгию по более простым временам, но карьера программиста развивается так, чтобы освободить место для тех, кто находится ниже. Другими словами, карьерный цикл естественным образом расширяет возможности следующего поколения разработчиков программного обеспечения. Это счастье — развиваться в профессии, которая позволяет мне наставлять молодые умы, ожидая, что со временем они вас превзойдут.
По мере роста обязанностей я стала еще сильнее ценить время, когда я делала первые шаги. Благодаря вкладу моих более опытных коллег я могла ни о чем не волноваться и концентрироваться на деталях реализации.
Прогресс никогда не бывает линеен. Однако если вы будете настроены на рост, смена поколений не застанет вас врасплох.
