Таня Рейли – Карьера разработчика. Стафф – круче, чем senior (страница 6)

Программное обеспечение влияет на жизнь каждого из нас. Системы, которые мы разрабатываем, напрямую затрагивают благосостояние и доходы людей: почитайте список багов, приведенный в Википедии (https://oreil.ly/eNIXO), впечатляет? Крушения самолетов (https://oreil.ly/iJgF2), сбои в системах скорой помощи (https://oreil.ly/s9GQf), неисправности в медицинском оборудовании (https://oreil.ly/fr7Dj) – ошибки и сбои в программах могут привести к фатальным последствиям, и наивно думать, что в будущем таких трагедий станет меньше.[15] Поэтому к разработке ПО нужно подходить со всей серьезностью.

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

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

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

Стафф-разработчик – это пример для подражания. Менеджеры формируют культуру общения в команде, призывая к взаимоуважению и обеспечивая соблюдение социальных норм. А вот технические стандарты задаются самыми авторитетными инженерами. Неважно, что говорят инструкции: если самый опытный разработчик не пишет тесты, все остальные тоже не будут. Это социокультурный феномен, и никакими нравоучениями его не изменить. Когда вышестоящие сотрудники во всеуслышание хвалят чужую работу, относятся друг к другу с уважением, задают уточняющие вопросы, остальные с легкостью делают то же самое. Когда молодые программисты видят в ком-то «разработчика, которым они хотели бы стать», они стремятся работать так же, как этот специалист. (В главе 7 мы рассмотрим, как с помощью личного примера вывести организацию на новый уровень результативности.)

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

Хватит рассуждать. Что делать-то?

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

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

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

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

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

Лидерство может быть разным, и иногда его видно не сразу. Разработать «счастливый путь», который защитит программистов от общих ошибок; сделать ревью кода и проектных решений других участников команды, чтобы они стали увереннее в себе и развили свои навыки; показать, что проектное предложение не соответствует истинным потребностям бизнеса, – все это виды лидерства. Обучение – это лидерство. Планомерное повышение уровня каждого разработчика – тоже лидерство. Выбор технологического направления – лидерство. И наконец, репутация выдающегося технического специалиста, который может вдохновить других людей на реализацию своих планов просто потому, что они ему доверяют, – это тоже особый вид лидерства. Если вы нашли у себя эти черты, то вы – лидер.

Многих людей пугает идея лидерства. Но не волнуйтесь: не все стафф– и принципал-разработчики работают по схеме «человек – человек». Среди стафф-разработчиков найдется место для интровертов: даже самые скромные люди могут задать технологическое направление компании благодаря своим знаниям и авторитету. Чтобы стать лидером, не обязательно находиться в центре внимания. Достаточно подавать положительный личный пример и хорошо относиться к людям.

Многие из нас слышали истории про «одного программиста», которого все сторонились, потому что с ним было слишком трудно общаться. Этот типаж, описанный Саймоном Травальей (Simon Travaglia) (https://en.wikipedia.org/wiki/Bastard_Operator_From_Hell), был широко известен в 80-х и 90-х годах. В Usenet[16] и других подобных ресурсах есть множество подтверждений того, что таких людей вполне можно встретить в реальной жизни. Коллеги этого программиста не только терпели его поведение, но и принимали его странные технические решения, только чтобы с ним не связываться. Однако сегодня такой разработчик станет обузой для всех. Какова бы ни была его производительность, сложно представить, что инженер, который не хочет работать в команде, может стоить проваленных проектов, а также результатов и карьеры других программистов. Если такой человек станет еще и примером для подражания в организации, то ее ждут большие проблемы.

Если вы думаете, что этот абзац про вас, зайдите на сайт Kind Engineering (https://kind.engineering/), где Эван Смит (Evan Smith), SRE-менеджер в Squarespace, дает конкретные рекомендации, как стать по-настоящему доброжелательным коллегой. Вы удивительно быстро сможете избавиться от репутации человека, с которым трудно работать.

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