Книга "Карьера разработчика"

Сегодня у меня на обзорчике книга "Карьера разработчика: стафф - круче, чем senior", в оригинале она называется "The Staff Engineer's Path: A Guide for Individual Contributors Navigating Growth and Change". Я точно не являюсь стафф-разработчиком, да и вообще я не особо разработчик, но это одна из самых содержательных и полезных книг, прочитанных мной за последнее время. Она актуальна и для техлидов, и для тимлидов, ну и для самих разработчиков тоже. В ней мало воды, много конкретных советов и какой-то оптимистичный, добрый взгляд на нашу профессию.

Читал я её на русском на бумаге (спасибо издательству Питер), за техническую редактуру отвечали ребята из Крока. В целом я приятно удивлён. Профессиональную литературу я всегда читаю исключительно на английском, один раз решил сделать исключение и купил "Элегантную головоломку" на бумаге - хуже я в своей жизни перевода не видел. Тут же всё красиво с точки зрения русского языка, сохранена точность терминов и IT-специфика. Придраться могу только к нескольким местам, где, на мой взгляд, перевод терминов ухудшает восприятие - "переключатели функций" вместо фича-тогглов, "пространства имён" вместо неймспейсов и "дежурства на телефоне" вместо он-колл. Мне кажется, что сильно устоявшиеся термины переводить не стоит - явно такую книгу не будет читать человек из совсем другой сферы. А если и будет, то перевод ему ничем не поможет.

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

Составляем топографическую карту

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

• Открытость - доступ к информации максимально ограничен или у всех есть доступ ко всем документам и обсуждениям?
• Способы коммуникации - большинство решений принимается устно или документируется?
• Сверху вниз или снизу вверх - приоритеты и задачи спускаются от руководства или любой сотрудник может запустить свой проект?
• Скорость изменений - стартам любых проектов предшествуют длительные обсуждения или всё стартует молниеносно и решается на ходу?
• Каналы коммуникации - вся рабочая коммуникация идёт через формальные каналы типа тикетов или очень много неформальной коммуникации через личные связи?
• Загруженность - все перегружены текущими задачами или много свободных рук на новые проекты и идеи?
• Структура организации - команды фиксированные, сложно перейти куда-то ещё или можно постоянно менять карьерную траекторию?
• Ошибки и ответственность - после каждой ошибки ищется ответственный и наступают последствия или ошибки воспринимаются исключительно как способ учиться?

Тут нет правильных и неправильных ответов, у всего есть обратная сторона. К примеру, хорошо работать в "no blame" культуре, но когда можно постоянно ошибаться и косячить совсем без личных последствий - долго ли протянет такая компания?

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

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

Написание технической стратегии

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

• Будь морально готов к скучным решениям - в начале всегда хочется предложить какую-нибудь гениальную идею. По факту в большинстве случаев переиспользовать уже существующие и проверенные решения. Прикольный совет, которым сам иногда пользуюсь - выписать все первые супер-идеи в документ, удалить их и начать заново с чистого листа.
• Проверь, что никто больше не работает над той же проблемой - в больших (и не только) компаниях часто бывает, что две группы людей решают одну и ту же проблему, не зная друг о друге. Если кто-то уже решает ту же проблему можно присоединиться к существующему проекту. Часто мы склонны переоценивать свои собственные идеи по сравнению с чужими, поэтому очень редко хорошим решением будет захватить лидерство над существующим проектом, хотя и такое может быть - если работа идёт откровенно плохо или медленно.
• Найди спонсора - вероятность успеха очень мала, если у тебя не будет поддержки среди топ-менеджмента. К тому же, спонсор сможет помочь решать ситуации, когда у двух людей в рабочей группе будут кардинально разные мнения по какому-то вопросу. Помни, что менеджеры - люди занятые, ты должен уметь объяснить и защитить свой проект буквально в 50 словах.
• Выбери ключевую рабочую группу - в группе меньше вероятность забить, плюс у каждого будет свой взгляд на проблему. Но группа должна быть маленькая, 2-4 человека, иначе развитие наоборот будет тормозиться - обсуждения, согласования. Подтверждаю своим опытом - начать всегда лучше в маленькой группе, пошарить документ на обсуждение широкому кругу всегда успеете. Это не значит, что не нужно собирать мнения и общаться с людьми вне группы - просто не привлекайте их пока к работе над самим документом.
• Установи масштабы проекта - если замахнуться на слишком большой кусочек, он может не поместиться в рот. Определи границы проекта и не опирайся на невозможные сценарии - например, если успех идеи зависит от смены CEO, наверное, что-то идёт не так.
• Убедись, что цель достижима - можно поговорить с кем-то внутри или извне компании, кто занимался похожим по масштабу и сути проектом.

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

Жизненный дашборд

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

• Энергия - у тебя может быть свободный час, но сил только на то, чтоб открыть описание задачи и сидеть в него пялить. Самое главное - это иметь достаточно энергии, чтоб вообще начать делать задачу.
• Качество жизни - мы хотим наслаждаться тем, что мы делаем - желательно и процессом, и ценностью результата для компании и мира в целом.
• Авторитет - для стафф-инженера и любого технического руководителя в целом важно сохранять технический авторитет. Его можно заслужить решением сложных задач, принятием правильных решений, техническими выступлениями. Без такого авторитета будет очень сложно выполнять свою работу, особенно на технически сложных проектах. Да тебе их просто и не поручат.
• Социальный капитал - авторитет отражает, верят ли люди, что ты можешь что-то сделать. Социальный капитал показывает, хотят ли они помогать вам что-то делать. Это микс доверия, дружбы, он увеличивается, когда ты помогаешь людям или делаешь одолжение.
• Навыки - это твои реальные технически навыки в разных областях. Их можно развивать обучением, практикой или работой с людьми, которые обладают нужными навыками.

Основная идея дашборда в том, что каждый проект

• требует каких-то входных значений этих показателей
• увеличивает или уменьшает тот или иной показатель

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

Если на пути встречается важный проект, который не матчится с текущим дашбордом, можно:

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

Что ещё интересного есть в книге?

Несколько больших частей, которые я здесь не покрыл:

• Что вообще такое стафф-инженер?
• Как начинать большие технические проекты? Как собрать команду и зафиксировать в ней роли? Что такое RFC и как их писать?
• Какие есть причины пробуксовки проектов? Спойлер, их миллион - другая команда является блокером; кто-то не может принять важное решение; кто-то не может нажать одну кнопку; важная часть работы ни на кого не назначена; ты не знаешь, куда и зачем вообще движется проект; ты не знаешь, как достичь цели; код написан, но результатом никто не пользуется и многое другое. Для каждой причины приведены советы по их решению. Изначально хотел в обзор добавить и эту часть книги, но уж очень она длинная!
• Что входит в обязанности стафф-инженера с точки зрения обучения и продвижения других людей? Как и куда расти самому?

В общем и целом рекомендую книгу:

• Разработчикам от уровня миддл+ и выше
• Техлидам
• Тимлидам и менеджерам, кто работает со старшими разработчиками