Как стать ведущим разработчиком. Часть 2

Продолжение перевода ^[1] статьи Джона Оллспоу ^[2] о личных качествах ведущих разработчиков.

Зрелые разработчики не жалуются просто так

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

Зрелые разработчики открыто идут на компромисс в своих решениях и суждениях

Они понимают, что любые технические решения неоднозначны — мир не чёрно-белый. Они быстро могут определить, в каком случае удачное решение сработает, а в каком нет. Они знают, что невозможно быть результативным и педантичным одновременно (принцип ETTO ^[3]), знают, что приходится выбирать между качеством работы и скоростью, а проблемы, которые перед ними стоят, нужно было решить ещё вчера, или они вообще не имеют окончательного решения.

Они знают, что не вся их работа идеальна, но их это устраивает — они стремятся явно выделить идеальные и неидеальные части проекта. И потом, спустя некоторое время, когда изначальная архитектура упрётся в свой потолок расширяемости, они не будут с сожалением вспоминать о недальновидных решениях в прошлом, они не будут со злостью и неприязнью ^[4] оценивать всё задним числом, бросаясь фразами типа «Эти идиоты с самого начала делали всё неправильно!», или «Они схалтурили!», или «Я ЖЕ ГОВОРИЛ им, что это не сработает!». Вместо этого они скажут: «До сих пор старый код отрабатывал своё. Но мы знали, что рано или поздно нам придётся всё изменить, и, кажется, это время пришло. За работу!».

Известно немало лаконичных высказываний о таких компромиссах, и зрелые разработчики знают, что не всегда стоит доверять этим полным философии изречениям (моих слов это тоже касается):

• «Преждевременная оптимизация — это корень всех бед». Люди злоупотребляют этим принципом, и я уже писал ^[5] об этом. Из этого принципа вытекает следующий (взято отсюда ^[6]): «Ведущего разработчика от новичка отличает понимание того, что „преждевременно“, а что нет».
• «Для каждой задачи — свой инструмент» — ещё один злоупотребляемый принцип. Замысел понятен: кто захочет пользоваться неподходящим инструментом? Но этот принцип может стать вредным, если понимать его буквально. Несмотря на то, что плотник может столкнуться с задачами, которые легко решаемы каким-то конкретным молотком, он не станет вооружаться инструментами всех возможных видов и размеров, потому что содержать и таскать с собой кучу молотков дорого. Решение этого вопроса — также компромисс.

Вкратце по компромиссам: все срезают углы, в любом проекте [и в этом переводе :) рад любым исправлениям!]. У незрелых разработчиков это вызывает отвращение, а зрелые намеренно, в самом начале проекта, обозначают такие углы, допускают их и считают это частью хорошего дизайна.

(Сюда же: Твой код может быть изящным, но мой, сука, работает ^[7])

Зрелые инженеры не выгораживают себя

У вас проблемы, если кто-то не хочет понимать, что его код (или инфраструктура) может повлиять на другие части системы или бизнеса, и оправдывает это тем, что он чётко следует всем формальностям. Прикрывая свою задницу ^[8], вы неявно сообщаете окружающим, что готовы пожертвовать другими (своей командой? компанией? обществом?) под тем лишь предлогом, что в вашей работе нет никаких недостатков. Зрелые инженеры не уходят в сторону и берут возложенную на них ответственность. Если они понимают, что у них недостаточно полномочий, чтобы быть отвественными за свою работу, они ищут пути, чтобы это исправить.

Пример самовыгораживания: «Я не виноват, что у них всё сломалось. Что-то они сделали неправильно. У меня всё по спецификации, а если в ней были ошибки — я здесь не при чём».

Зрелые разработчики умеют сопереживать

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

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

Зрелые разработчики знают о ментальных ловушках ^[9]

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

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

На Википедии представлен обширный список ^[10] ловушек. Разработчики подвержены в основном следующим:

• Искажение в свою пользу ^[11] — если всё хорошо — значит, это я так постарался. Если плохо — значит, накосячил кто-то другой.
• Искажение авторства ^[12] — если плохой результат получил другой человек, значит, проблема в этом человеке: он тупой или неуклюжий, может неряшливый и т. д. Если плохой результат получил я, то проблема в моём окружении: так сложились обстоятельства.
• Ретроспективное искажения ^[13] — (говорят, это самое изученное явление в современной психологии) если произошло что-то неприятное (серьёзный баг, например), человек говорит «Я так и знал!». Люди склонны оценивать события прошлого проще, чем они были на самом деле. Если вы слышите «… они должны были...» или «… как они этого не учли, это же очевидно!», знайте — это ретроспективное искажение.
• Отклонение в сторону результата ^[14] — если результат разрушителен, то действия, которые к этому привели — глупые и необдуманные. Чем хуже результат, тем строже оценки.
• Ошибка планирования ^[15] — этот проект займёт у меня не больше недели!

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

Десять заповедей безличного программирования

Эти заповеди были описаны в книге «Психология компьютерного программирования ^[16]», написанной в 1971 году. Несмотря на возраст, слова до сих пор актуальны. Я не читал саму книгу, но нашёл пост ^[17] о ней в блоге Стивена Уайетта Буша ^[18]. Стивену её посоветовал перед смертью его отец. Вот эти заповеди:

1. Пойми и свыкнись с тем, что ты будешь совершать ошибки. Суть в том, что их нужно находить до того, как они на что-то повлияют. В нашей индустрии, к счастью, ошибки редко могут привести к фатальным результатам (это не относится к тем, кто работает над ПО управления ракетами в Лаборатории реактивного движения ^[19]). Мы можем (и должны) учиться, смеяться над собой и двигаться дальше.
2. Твой код — это не ты. Весь смысл проверок — в поиске недочётов. И когда их найдут, не принимай это близко к сердцу.
3. Не важно, сколько хитрых приёмчиков ты знаешь, — всегда найдётся кто-нибудь круче тебя. И, если ты попросишь, этот человек может научить тебя парочке новых трюков. Слушай других, даже если тебе кажется, что это не нужно.
4. Не переписывай код без обсуждения. Между исправлением кода и его переписыванием лежит тонкая грань. Пойми разницу, не меняй всё самостоятельно, добивайся изменений в рамках анализа кода.
5. Относись к тем, кто знает меньше тебя, с уважением, терпением и пониманием. Почти все люди из нетехнического круга, которые постоянно взаимодействуют с разработчиками, считают нас, в лучшем случаем, самодовольными типами. В худшем — плаксами. Не укрепляй этот стереотип своей злостью и нетерпеливостью.
6. Всё течёт, всё меняется. Будь открытым для изменений, принимай их с улыбкой. Воспринимай каждое изменение в требованиях, смену платформы или инструмента не как существенное неудобство, с которым нужно бороться, а как новое испытание.
7. Настоящая власть исходит не из званий, а из знаний. Знания порождают власть, а власть порождает уважение — так что, если вы хотите уважения в безличном окружении, развивайте свои знания.
8. Борись за то, во что веришь, но достойно принимай поражение. Пойми, иногда твои идеалы могут быть отвергнуты. Даже если ты прав, не пытайся отомстить и не говори «Я вас предупреждал». Не делай уже мёртвую идею своим лозунгом.
9. Не будь «программистом в каморке». Не будь человеком, который выходит из своего тёмного офиса только за газировкой. Такой программист вне зоны видимости, взаимоотношений и контроля. Такой человек не имеет голоса в открытом окружении. Принимай участие в разговорах, участвуй в жизни своего офиса.
10. Критикуй код, а не человека, — будь добр к программисту, но не к коду. Пусть все твои комментарии будут положительными и направленными на улучшение кода. Указывай в комментариях на местные стандарты, спецификации, улучшение производительности и т. д.

От новичка к эксперту

Я уже почти не слежу за исследованиями в области приобретения знаний, но в размышлениях о развитии индустрии от этой темы уйти сложно. Одна из основных работ по этой теме — доклад ^[20] Стюарта Дрейфуса и Хуберта Дрейфуса «Пятиуровневая модель ^[21] умственных процессов, задействованных в целенаправленном получении навыков», в котором они описали характеристики разных уровней компетенции.

Новичок

• Твёрдое следование правилам;
• узкое восприятие ситуации;
• отсутствие суждений (или их ограниченность).

Продвинутый новичок

• Интерпретация правил по обстоятельствам;
• ограниченное восприятие ситуации.

Компетентный

• Сознательное обдуманное планирование;
• стандартные, привычные действия.

Специалист

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

Эксперт

• Не полагается на правила;
• интуитивное осознание ситуации;
• аналитический подход используется только в новых ситуациях.

В докладе говорится:

Новички действуют, исходя из правил и знаний. Они всё обдумывают и анализируют, поэтому они медленно работают, выбирают и принимают решения.

(то есть, новички сильно зависимы от частных законов)

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

(то есть, эксперты действуют по обстоятельствам)

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

От переводчика: не могу найти в интернете интересную работу Н. Н. Непейводы «Уровни знаний и умений», если кто найдёт, выложите в комментариях, пожалуйста.

Сенсация: зрелые разработчики знают о важности человеческих эмоций. (Невероятно!)

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

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

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

В качестве примера того, как эмоции заставляют людей принимать решения, почитайте какой-нибудь холивар ^[22] о чём угодно.

«Поразительно, чего можно добиться, если не задумываться о заслугах»

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

Это идея сделает нас свободными, и как только все поймут и усвоят её, расцветёт мир прогресса и передового мышления ^[23] — инженеры не будут озабочены приравниванием своей работы к личному карьерному успеху.

Это не конец

Мне повезло, что я работаю cо зрелыми инженерами в Etsy, для меня это очень почётно. Наша отрасль ещё молода, и, несмотря на то, что нам ещё многому предстоит научиться у инженеров из других областей, я думаю, у нас есть некоторое преимущество. Интернет неразрывно связан с распространением информации, и, если мы хотим вырасти в настоящую отрасль знаний, в дисциплину, мы должны постоянно обращать внимание на то, что значит быть „ведущим“ и „зрелым“ разработчиком.

Спасибо Серёге и Ренате за помощь в переводе. Спасибо моим наставникам, Андрею и Сергею, которые каждый день показывают мне, что значит быть „ведущим“ и как им быть.

Автор: skovorodkin

Источник ^[24]