Это перевод статьи, написанной Джоном Оллспоу, который на данный момент является старшим вице-президентом технического отдела в Etsy.
В нашей сфере деятельности нам доступны огромные объёмы знаний, в особенности тех, которые позволяют разработчику стать эффективным. Но почему-то, несмотря на существование множества книг о специфических задачах и обязанностях менеджеров в нетехнических областях, я практически не вижу новых книг или статей о том, как стать хорошим ведущим разработчиком. Замечательным исключением, конечно, являются статьи Кейт Maцудайры [от переводчика: на фотографии, кстати, именно она], немало написавшей о культурных составляющих инженерии.
Но в то же время, все мои знакомые преуспевающие разработчики помнят своих наставников, которые научили их тому, что значит быть „ведущим“.
Я совершенно согласен в определении значения „ведущего“ с моим другом Тео. В своей главе в книге Web Operations издательства O'Reilly он пишет:
Поколение X (и в ещё большей степени поколение Y) — это культура немедленного удовлетворения. Я работал с поразительным количеством инженеров, рассчитывающих, что их „карьерный путь“ до высших инженерных должностей займёт не более пяти лет только потому, что они умные. Но это просто невозможно. Их слишком много. Не каждый может быть ведущим. Неужели, если через пять лет вы ведущий, значит вы на пике своего развития? Разве ещё через пять лет вы не получите ещё более ценный опыт? Что тогда? „Супер инженер“? А ещё через пять лет? „Супер-пупер инженер“. Думаю, проблема заключается в молодости нашей отрасли. И в самом деле, мало кто занимался веб-администрированием (web operations) на протяжении пятнадцати лет. Учитывая динамику развития индустрии, многие предпочитают управленческие позиции или риск предпринимательской гонки.
Он прав, сфера веб-администрирования пока ещё очень молода. И поэтому не стоит удивляться, когда люди со званием „ведущих“ демонстрируют незрелое поведение, как с технической, так и с человеческой точек зрения. Если вы не читали главу Тео целиком, я рекомендую вам это сделать.
Хорошо, но всё-таки, что для нас значит быть „ведущим“? Мне приходится нанимать, поддерживать и помогать разработчикам, которых считают „ведущими“, и у меня, безусловно, есть мнение по этому вопросу. Мысль, что есть некий порог в карьерном развитии, хороша, но я добавлю, что этот порог размыт — это не простой список поставленных задач. Вы не станете однажды утром „ведущим“ только потому, что об этом говорит новое название вашей должности после повышения. Ведущие разработчики не могут знать всё. Их технические знания не безукоризненны, но они не переживают из-за этого.
Чтобы избежать путаницы между званиями и размытыми ожиданиями, я буду говорить об инженерной зрелости.
Я предполагаю, что „ведущий“ инженер — это зрелый инженер.
Я опущу ту часть, где можно было бы перечислить технические области, которыми зрелый инженер должен так или иначе владеть или которые должен понимать (например, сети, файловые системы, алгоритмы и т. д.), и, вместо этого, выделю те личные качества, которые говорят мне, что человек сможет положительно повлиять на техническую сторону организации или бизнеса.
Мне задавали вопрос на Quora: «Какие отличительные черты (кроме технических умений и опыта) присущи лучшим управляющим технических отделов?». Ответив на вопрос, я понял, что и сам постоянно стремлюсь к обладанию упомянутыми в ответе качествами. Этот пост похож на тот ответ.
Стоит сказать, что ведущие инженеры в веб-разработке и администрировании обладают теми же чертами, что и ведущие инженеры в других сферах (в механике, электрике, химии и т. д.), для которых применимы «Неписаные законы инженерии». Опять-таки, если вы не читали эту книгу, рекомендую сделать это. Она была опубликована в 1944 году Американским обществом инженеров-механиков. Отрывок из книги можно прочитать здесь.
Несмотря на то, что структура книги и слог устарели («… воздерживайтесь от использования сквернословия за рабочим местом...» или «… мужчины должны обращать определённое внимание на бритьё и подравнивание бород и усов»), она даёт хорошее описание нетехнических ожиданий, обязанностей и внутренней работы технической организации в отношении того, как должны действовать менеджеры и зрелые инженеры.
Обязательные качества зрелых инженеров
Все статьи с попытками описать необходимые качества будут переполнены пунктами в своих перечислениях: в инженерии есть о чём поговорить. Я опишу только некоторые качества: до каких-то я дошёл сам, некоторые взял из разных источников, многие — из «Неписаных законов», упомянутых выше.
Зрелые разработчики рады конструктивной критике их идей
Все успешные инженеры, которых я встречал, по окончании разработки и планирования проекта постоянно задают коллегам подобные вопросы:
- Что я мог упустить?
- Почему это может не сработать?
- В чём я могу быть неправ?
- Если даже с технической точки зрения это звучит верно, будет ли это понятно всей организации настолько, чтобы управлять, поддерживать и расширять это?
Они знают, ничто, ими сделанное, не останется только в их руках, и хорошая проверка от коллег — это то, что сделает их продукт лучше. Как было где-то сказано, они „рады плохим новостям“.
Зрелые разработчики осознают, как их воспринимают в личностном плане
Недостаточно одного умения написать во сне фильтр Блума на Erlang или многопоточную программу на C. Всё это не имеет значения, если никто не хочет с вами работать. Зрелый инженер знает, что законченность, элегантность и превосходство его идей ничего не значат, если никто не хочет с ним работать из-за того, что он придурок. Снисхождение, недооценивание, самолюбование и самореклама отталкивают от вас (может только и на подсознании) других инженеров. Но радость от разработки в некотором смысле заключается как раз в наслаждении той компанией людей, с которыми вы проектируете и создаёте что-то новое. Инженер, который запросто называет другого дебилом, обречён на остановку в своём развитии.
Поэтому зрелые разработчики обдумывают то, как они взаимодействуют с другими. Да, не все зрелые инженеры умеют с лёгкостью общаться с людьми, но все знает, в чём они могут стать лучше, и постоянно просят своих коллег и менеджеров дотошно проверять, что и как они делает. Им важно быть напористыми в распространении своих идей, но не пассивными или агрессивными.
Я уже говорил, но стоит подчеркнуть это ещё раз: то, в какой степени другие люди хотят с вами работать, напрямую говорит о том, насколько успешны вы будете в своей карьере разработчика. Будьте человеком, с которым все хотят работать.
Это не значит, что вам не следует конструктивно критиковать работу (или выслушивать критику), проделанную другим человеком (но не его личность), боясь кого-то обидеть. Между обзыванием кого-нибудь дебилом и указыванием на недостатки его кода или продукта есть разница. В нашем разговоре Тео отметил другую область, в которой мы может измениться к лучшему:
Нам, как индустрии, не следует критиковать характер или внешний вид друг друга, но нам стоит критиковать результаты нашей работы. Нам необходимо обрасти толстой кожей и научиться воспринимать критику с той точки зрения, которая исключает фокус на личности.
Придурки были и будут всегда, и их стоит остерегаться. Но мы должны избавиться от отношения к чьему-либо коду, как к его ребёнку. Код ничего не чувствует, у него нет комплексов, и он, естественно, не проявит самого важного качества (способности размножаться), заложенного в ваши гены.
С этим, думаю, связан отрывок из «Неписаных законов» (выделение моё):
Внимательно следите за тем, кого вы отмечаете в качестве получателей писем, заметок и прочих документов, в которых могут быть затронуты интересы других отделов.
Много вреда было приченено молодыми работниками, которые распространяли документы, содержавшие вредную или неудобную информацию. Да, новичку не просто распознать в таком документе «бомбу», но, в общем-то, понятно, что могут возникнуть проблемы, если в записке притесняются чьи-то интересы или раскрываются чужие недостатки. Вам лучше посоветоваться со своим начальником, если документ будет широко распространён или если в нём обсуждаются проблемы производства или клиентов, и если вы не уверены полностью в своей правоте.
Эта цитата подчёркивает немалый возраст книги, но я считаю, что и сейчас суть этих слов актуальна. Ничто так не говорит о недальновидности и неосведомлённости, как плохо продуманный, неконструктивный, вбрасывающий ядовитые нападки твит. Новички совершают ошибку, наезжая в 140 символах на сложные технологии.
Я всегда обращаю внимание на подобного рода публичные заявления, когда сталкиваюсь с ними, и если такой человек придёт на собеседование к нам в Etsy, я хорошенько подумаю, прежде чем взять его на работу (Кристофер Браун говорил об этом же в своём докладе на Velocity London).
Зрелые разработчики не избегают прогнозов, а постоянно совершенствуются в них
Из «Неписаных законов»:
Обещания, расписания и прогнозы — необходимые и важные инструменты хорошо организованного бизнеса. Многие инженеры не понимают этого и увиливают от досаждающей ответственности за свои обязательства. Вы должны давать обещания, основываясь на своих прогнозах по той части работы, над которой вы ответственны, и на прогнозах тех отделов, с которыми вы связаны. Никто не должен задерживать работу с такой формулировкой: «Я не могу ничего обещать, моя работа связана с большим количеством неопределённых факторов».
Уклоненяться от ответственности за прогнозы — это всё равно, что говорить: «Я не готов, чтобы мне доверяли написание важных частей инфраструктуры». Все дела зависят от прогнозов, и все разработчики, вовлечённые в проект, заняты совместной деятельностью, а это значит, что каждый должен нести ответственность за свою предсказуемость. В целом же, зрелые инженеры могут спокойно работать с неким ненулевым уровнем неопределённости и риска.
Зрелые разработчики обладают врождённым чутьём, даже если не знают об этом
Этот код выглядит неплохо, я горжусь собой. Я попросил других людей проверить его и записал все отзывы. И как долго теперь у меня займёт переписывание и исправление? Как мой код повлияет на работу сервера, когда он там окажется? Как и насколько изменится использование ЦПУ/памяти/диска/сети? Смогут ли другие понять этот код? Достаточно ли прост мой код, чтобы другие смогли в него вникнуть и расширить?
Зрелые разработчики понимают, что не в каждом проекте будут хватать звёзды с небес
Какими бы бессмысленными или незначительными не казались ваши первые задания, приложите к ним все усилия.
Умение доводить дела до конца, значит делать то, что вам неинтересно. Не важно, насколько привлекателен проект, там всё равно будут скучные и утомительные задачи, задачи, которые новичками считаются ниже их достоинства или должности. Мой приятель, Келлан Эллиот-МакКри (CTO в Etsy), говорит об этом следующее:
Иногда спасение можно найти в простоте скучных задач. Зрелость говорит, что такие задачи нужно выполнять быстро и двигаться дальше. Иногда скучные задачи требуют предельной дисциплины и концентрации внимания. Как ни странно, наиболее скучные задачи, которые выполняются только ведущими инженеры, могут быть в то же время самыми необычными.
Зрелые разработчики прокачивают мастерство и квалификацию окружающих
Они осознают, что в какой-то момент их индивидуальный вклад перестанет соответствовать возможной скорости развития проекта. Они осознают, что ни один человек не может делать всё сразу, и что величайшие мировые подвиги были совершены командами, а не выдающимися одиночками. Том Лимончелли как следует доказывает это в своём блоге.
В Etsy мы называем это «щедростью ума». Щедрость ума — одна из наших важнейших инженерных ценностей, но, кроме того, это основная обязанность нашего инженерно-технического персонала. Эти люди вкладывают своё время в обучение младших и новых разработчиков, чтобы как можно больше сотрудников не только понимали, что они делают, но и почему. Способность «научить ловить рыбу» на этом уровне обязательна, а это требует как терпения, так и дальновидных вложений всей организации.
Поэтому, вместо того, чтобы говорить «Так, подвинься, давай я сделаю», мы говорим «Ясно, давай разберёмся с этим. Я покажу тебе, как пишу/отлаживаю/и т. п. Затем то же сделаешь ты, чтобы я убедился, что ты понимаешь как и почему мы делаем это именно так».
На этом первая часть перевода закончена. Буду рад конструктивной критике и советам. Я старался, но может быть, что-то понял и перевёл неправильно или коряво — предлагайте свои варианты. Принимаются пул-реквесты на GitHub.
Автор: skovorodkin
