Продолжение перевода статьи Джона Оллспоу о личных качествах ведущих разработчиков.
Зрелые разработчики не жалуются просто так
Вместо этого они рассуждают, основываясь на наблюдениях, и предлагают варианты решения найденной ими проблемы. Один опытный менеджер сказал мне: «Никогда не приходи к своему начальнику с жалобами, если у тебя нет готового решения проблемы. И лучше, если решений будет несколько». Но даже если у вас не получилось найти ни одного решения — это уже лучше, чем жаловаться просто так.
Зрелые разработчики открыто идут на компромисс в своих решениях и суждениях
Они понимают, что любые технические решения неоднозначны — мир не чёрно-белый. Они быстро могут определить, в каком случае удачное решение сработает, а в каком нет. Они знают, что невозможно быть результативным и педантичным одновременно (принцип ETTO), знают, что приходится выбирать между качеством работы и скоростью, а проблемы, которые перед ними стоят, нужно было решить ещё вчера, или они вообще не имеют окончательного решения.
Они знают, что не вся их работа идеальна, но их это устраивает — они стремятся явно выделить идеальные и неидеальные части проекта. И потом, спустя некоторое время, когда изначальная архитектура упрётся в свой потолок расширяемости, они не будут с сожалением вспоминать о недальновидных решениях в прошлом, они не будут со злостью и неприязнью оценивать всё задним числом, бросаясь фразами типа «Эти идиоты с самого начала делали всё неправильно!», или «Они схалтурили!», или «Я ЖЕ ГОВОРИЛ им, что это не сработает!». Вместо этого они скажут: «До сих пор старый код отрабатывал своё. Но мы знали, что рано или поздно нам придётся всё изменить, и, кажется, это время пришло. За работу!».
Известно немало лаконичных высказываний о таких компромиссах, и зрелые разработчики знают, что не всегда стоит доверять этим полным философии изречениям (моих слов это тоже касается):
- «Преждевременная оптимизация — это корень всех бед». Люди злоупотребляют этим принципом, и я уже писал об этом. Из этого принципа вытекает следующий (взято отсюда): «Ведущего разработчика от новичка отличает понимание того, что „преждевременно“, а что нет».
- «Для каждой задачи — свой инструмент» — ещё один злоупотребляемый принцип. Замысел понятен: кто захочет пользоваться неподходящим инструментом? Но этот принцип может стать вредным, если понимать его буквально. Несмотря на то, что плотник может столкнуться с задачами, которые легко решаемы каким-то конкретным молотком, он не станет вооружаться инструментами всех возможных видов и размеров, потому что содержать и таскать с собой кучу молотков дорого. Решение этого вопроса — также компромисс.
Вкратце по компромиссам: все срезают углы, в любом проекте [и в этом переводе :) рад любым исправлениям!]. У незрелых разработчиков это вызывает отвращение, а зрелые намеренно, в самом начале проекта, обозначают такие углы, допускают их и считают это частью хорошего дизайна.
(Сюда же: Твой код может быть изящным, но мой, сука, работает)
Зрелые инженеры не выгораживают себя
У вас проблемы, если кто-то не хочет понимать, что его код (или инфраструктура) может повлиять на другие части системы или бизнеса, и оправдывает это тем, что он чётко следует всем формальностям. Прикрывая свою задницу, вы неявно сообщаете окружающим, что готовы пожертвовать другими (своей командой? компанией? обществом?) под тем лишь предлогом, что в вашей работе нет никаких недостатков. Зрелые инженеры не уходят в сторону и берут возложенную на них ответственность. Если они понимают, что у них недостаточно полномочий, чтобы быть отвественными за свою работу, они ищут пути, чтобы это исправить.
Пример самовыгораживания: «Я не виноват, что у них всё сломалось. Что-то они сделали неправильно. У меня всё по спецификации, а если в ней были ошибки — я здесь не при чём».
Зрелые разработчики умеют сопереживать
Как правило, за сложные проекты ответственность несут сразу несколько человек. В любом проекте все: проектировщики, руководители, инженеры по эксплуатации, разработчики и ребята из отдела развития бизнеса ответственны за свои задачи. И зрелые разработчики осознают, что эти задачи, как и восприятие целого, у всех могут быть разными. Это позволяет им быть эффективными в своих делах. Умение сопереживать — значит, умение поставить себя на место другого человека в проекте и учитывать его точку зрения в своей работе.
В инженерии не избежать конфликтных ситуаций, и недовольство ими, вместо их принятия, как составляющей успеха, — признак незрелого разработчика.
Зрелые разработчики знают о ментальных ловушках
Нет, диплом по философии получать не обязательно, но ментальные ловушки это то, что в определённый момент может затормозить карьерный рост разработчика. Большинство зрелых разработчиков, с которыми я знаком, может и не понимают деталей того, как возникают ловушки, или как с ними бороться, но они понимают, что, как и все люди, они могут в них попасться.
Как правило, разработчикам ежедневно приходится обрабатывать большие объёмы новой информации. Но, попав в одну из ловушек, мы начинаем интерпретировать данные таким образом, что наши выводы противоречат реальному положению вещей. Это может неожиданным образом повлиять на всю последующую работу и итоговый результат.
На Википедии представлен обширный список ловушек. Разработчики подвержены в основном следующим:
- Искажение в свою пользу — если всё хорошо — значит, это я так постарался. Если плохо — значит, накосячил кто-то другой.
- Искажение авторства — если плохой результат получил другой человек, значит, проблема в этом человеке: он тупой или неуклюжий, может неряшливый и т. д. Если плохой результат получил я, то проблема в моём окружении: так сложились обстоятельства.
- Ретроспективное искажения — (говорят, это самое изученное явление в современной психологии) если произошло что-то неприятное (серьёзный баг, например), человек говорит «Я так и знал!». Люди склонны оценивать события прошлого проще, чем они были на самом деле. Если вы слышите «… они должны были...» или «… как они этого не учли, это же очевидно!», знайте — это ретроспективное искажение.
- Отклонение в сторону результата — если результат разрушителен, то действия, которые к этому привели — глупые и необдуманные. Чем хуже результат, тем строже оценки.
- Ошибка планирования — этот проект займёт у меня не больше недели!
Кроме этих ловушек есть немало других, и все настолько интересные, что я могу утонуть в их изучении. Категорически рекомендую ознакомиться с нимип подробнее, если вам интересно увеличить свою эффективность.
Десять заповедей безличного программирования
Эти заповеди были описаны в книге «Психология компьютерного программирования», написанной в 1971 году. Несмотря на возраст, слова до сих пор актуальны. Я не читал саму книгу, но нашёл пост о ней в блоге Стивена Уайетта Буша. Стивену её посоветовал перед смертью его отец. Вот эти заповеди:
- Пойми и свыкнись с тем, что ты будешь совершать ошибки. Суть в том, что их нужно находить до того, как они на что-то повлияют. В нашей индустрии, к счастью, ошибки редко могут привести к фатальным результатам (это не относится к тем, кто работает над ПО управления ракетами в Лаборатории реактивного движения). Мы можем (и должны) учиться, смеяться над собой и двигаться дальше.
- Твой код — это не ты. Весь смысл проверок — в поиске недочётов. И когда их найдут, не принимай это близко к сердцу.
- Не важно, сколько хитрых приёмчиков ты знаешь, — всегда найдётся кто-нибудь круче тебя. И, если ты попросишь, этот человек может научить тебя парочке новых трюков. Слушай других, даже если тебе кажется, что это не нужно.
- Не переписывай код без обсуждения. Между исправлением кода и его переписыванием лежит тонкая грань. Пойми разницу, не меняй всё самостоятельно, добивайся изменений в рамках анализа кода.
- Относись к тем, кто знает меньше тебя, с уважением, терпением и пониманием. Почти все люди из нетехнического круга, которые постоянно взаимодействуют с разработчиками, считают нас, в лучшем случаем, самодовольными типами. В худшем — плаксами. Не укрепляй этот стереотип своей злостью и нетерпеливостью.
- Всё течёт, всё меняется. Будь открытым для изменений, принимай их с улыбкой. Воспринимай каждое изменение в требованиях, смену платформы или инструмента не как существенное неудобство, с которым нужно бороться, а как новое испытание.
- Настоящая власть исходит не из званий, а из знаний. Знания порождают власть, а власть порождает уважение — так что, если вы хотите уважения в безличном окружении, развивайте свои знания.
- Борись за то, во что веришь, но достойно принимай поражение. Пойми, иногда твои идеалы могут быть отвергнуты. Даже если ты прав, не пытайся отомстить и не говори «Я вас предупреждал». Не делай уже мёртвую идею своим лозунгом.
- Не будь «программистом в каморке». Не будь человеком, который выходит из своего тёмного офиса только за газировкой. Такой программист вне зоны видимости, взаимоотношений и контроля. Такой человек не имеет голоса в открытом окружении. Принимай участие в разговорах, участвуй в жизни своего офиса.
- Критикуй код, а не человека, — будь добр к программисту, но не к коду. Пусть все твои комментарии будут положительными и направленными на улучшение кода. Указывай в комментариях на местные стандарты, спецификации, улучшение производительности и т. д.
От новичка к эксперту
Я уже почти не слежу за исследованиями в области приобретения знаний, но в размышлениях о развитии индустрии от этой темы уйти сложно. Одна из основных работ по этой теме — доклад Стюарта Дрейфуса и Хуберта Дрейфуса «Пятиуровневая модель умственных процессов, задействованных в целенаправленном получении навыков», в котором они описали характеристики разных уровней компетенции.
Новичок
- Твёрдое следование правилам;
- узкое восприятие ситуации;
- отсутствие суждений (или их ограниченность).
Продвинутый новичок
- Интерпретация правил по обстоятельствам;
- ограниченное восприятие ситуации.
Компетентный
- Сознательное обдуманное планирование;
- стандартные, привычные действия.
Специалист
- Восприятие ситуации, как единого целого, а не как набора отдельных аспектов;
- осознание отклонений от нормальной модели;
- использование контекстно-зависимых принципов.
Эксперт
- Не полагается на правила;
- интуитивное осознание ситуации;
- аналитический подход используется только в новых ситуациях.
В докладе говорится:
Новички действуют, исходя из правил и знаний. Они всё обдумывают и анализируют, поэтому они медленно работают, выбирают и принимают решения.
(то есть, новички сильно зависимы от частных законов)
Эксперты действуют интуитивно, исходя из зрелого, целостного проверенного понимания, без сознательного размышления. В этом весь смысл опыта. Они не рассматривают проблемы и решения по отдельности. Они действуют.
(то есть, эксперты действуют по обстоятельствам)
Я не совсем согласен с таким чётким разделением уровней. Мне кажется, на самом деле, всё несколько более размыто. Но, тем не менее, даже такая упрощённая классификация может быть полезной.
От переводчика: не могу найти в интернете интересную работу Н. Н. Непейводы «Уровни знаний и умений», если кто найдёт, выложите в комментариях, пожалуйста.
Сенсация: зрелые разработчики знают о важности человеческих эмоций. (Невероятно!)
Отношение людей к технологиям и техническим решениям не менее важно, чем подробности об этих технологиях. Зрелые разработчики знают это и подстраиваются соответствующим образом. Умение сопереживать помогает им понять, как их коллеги относятся к техническим решениям, даже если им самим не так просто выразить своё отношение.
Доверие людей к программам, архитектурам или шаблонам в большой степени зависит от прошлого опыта, который может привести как к положительному, так и к отрицательному отношению. Если вам приходилось работать с интернет-магазином на mod_perl, который постоянно падал в совершенно загадочых обстоятельствах, то неудивительно, что и в другой компании вам не захочется с работать с этой технологией даже в абсолютно иных условиях. Вы просто знаете, что с mod_perl связаны большие проблемы, и будете избегать его использования в любом случае.
Зрелые разработчики понимают это, когда делают выбор в пользу технологии с подобным, пускай абсурдным, багажом. Убедить группу использовать инструменты и шаблоны, которые их не устраивают, — непростая задача. Принцип «для каждой задачи — свой инструмент» должен принимать во внимание и этот, не всегда количественный, параметр.
В качестве примера того, как эмоции заставляют людей принимать решения, почитайте какой-нибудь холивар о чём угодно.
«Поразительно, чего можно добиться, если не задумываться о заслугах»
Эту цитату обычно приписывают Гарри Трумэну, но у меня такое чувство, что это слова какого-то иезуитского священника. Так или иначе, ещё один признак того, что вы работаете со зрелым инженером, — это если он ценит успех проекта выше, чем возможную личную выгоду, которую он может получить за работу над этим проектом.
Это идея сделает нас свободными, и как только все поймут и усвоят её, расцветёт мир прогресса и передового — инженеры не будут озабочены приравниванием своей работы к личному карьерному успеху.
Это не конец
Мне повезло, что я работаю cо зрелыми инженерами в Etsy, для меня это очень почётно. Наша отрасль ещё молода, и, несмотря на то, что нам ещё многому предстоит научиться у инженеров из других областей, я думаю, у нас есть некоторое преимущество. Интернет неразрывно связан с распространением информации, и, если мы хотим вырасти в настоящую отрасль знаний, в дисциплину, мы должны постоянно обращать внимание на то, что значит быть „ведущим“ и „зрелым“ разработчиком.
Спасибо Серёге и Ренате за помощь в переводе. Спасибо моим наставникам, Андрею и Сергею, которые каждый день показывают мне, что значит быть „ведущим“ и как им быть.
Автор: skovorodkin
