Что значит быть старшим инженером

25 октября 2012 года

Автор: John Allspaw

I am currently a co-founder of Adaptive Capacity Labs, LLC. Previously, I was Chief Technology Officer at Etsy

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

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

Я полностью согласен с мыслями моего друга Тео о том, что значит быть «старшим», которые он изложил в своей главе книги Web Operations издательства O'Reilly:

Поколение X (а поколение Y тем более) привыкло к мгновенному удовлетворению своих желаний. Я работал с невероятным количеством инженеров, которые считают, что должны дорасти до высших позиций в инженерной команде за 5 лет только потому, что они умны. Когда таких людей столько, сколько я видел, это просто невозможно. Не все могут быть старшими инженерами. Если через пять лет ты стал старшим инженером, означает ли это, что ты достиг пика своего мастерства? Неужели еще через пять лет ты не наберешься бесценного опыта? И что тогда? «Супер-инженер»? А еще через пять лет? «Супер-пупер-инженер»? Я виню в этой проблеме молодость нашей профессии. Дело в том, что очень мало людей проработали в веб-операциях пятнадцать лет. С учетом динамики нашей индустрии многие предпочли перейти на управленческие позиции или попробовать себя в предпринимательстве.

Он прав: веб-операции как область деятельности всё ещё довольно молоды. Поэтому неудивительно, когда люди с должностью «старший инженер» ведут себя на удивление незрело — как в технических, так и в нетехнических вопросах. Если вы ещё не читали главу Тео, очень рекомендую.

Так что же на самом деле значит быть «старшим» в нашей профессии? У меня есть своё мнение на этот счёт, ведь я занимаюсь наймом, поддержкой и удержанием инженеров, которых мы считаем старшими. Идея о том, что в карьерном развитии есть определённая планка, которую нужно преодолеть, — правильная. Но я бы добавил, что эти критерии существуют скорее в виде спектра, а не списка галочек для проставления. Ты не просыпаешься однажды утром старшим инженером только потому, что получил повышение с соответствующей должностью. Старшие инженеры не всезнайки. Их технические знания не идеальны, и они спокойно с этим живут.

Чтобы не путать должности с размытыми ожиданиями, иногда я буду говорить об инженерной зрелости.

Иными словами: я ожидаю, что «старший» инженер будет зрелым инженером.

Я не буду сейчас перечислять технические области, в которых зрелый инженер должен обладать определённым уровнем мастерства или понимания (такие как «Сети», «Файловые системы», «Алгоритмы» и прочее). Вместо этого я хочу выделить личные качества, которые, на мой взгляд, показывают, что человек способен положительно влиять на организацию или бизнес в области инженерии.

На Quora меня однажды спросили: «Какими качествами (помимо технических способностей и опыта) должен обладать отличный вице-президент по техническим операциям?». Список качеств в моём ответе я привёл с пониманием того, что сам постоянно к ним стремлюсь. Эта статья похожа на тот ответ.

Я мог бы начать с утверждения, что старшие инженеры в веб-разработке и операциях обладают теми же характеристиками, что и старшие инженеры в других областях (механике, электротехнике, химии и т.д.), к которым применимы Неписаные законы инженерии. Если вы ещё не читали эту книгу, пожалуйста, прочитайте. Она была написана в 1944 году и опубликована Американским обществом инженеров-механиков. Хороший отрывок из книги можно найти здесь.

Хотя структура и стиль книги кажутся устаревшими («...воздерживайтесь от ненормативной лексики на рабочем месте...» или «...мужчинам следует уделять особое внимание бритью и уходу за бородой и усами...»), она даёт хороший обзор нетехнических ожиданий, обязанностей и внутреннего устройства инженерной организации в отношении того, как должны вести себя менеджеры и зрелые инженеры.

Типичные характеристики зрелых инженеров

Все статьи, которые пытаются описать желаемые характеристики, переполнены маркированными списками, и область инженерии не исключение. Поэтому вот вам несколько пунктов — некоторые мои собственные, некоторые взяты из разных источников, многие из упомянутых выше Неписаных законов.

Зрелые инженеры ищут конструктивную критику своих решений.

Каждый успешный инженер, которого я встречал, после завершения проекта или при подготовке к нему постоянно задаёт коллегам такие вопросы:

• «Что я мог упустить?»
• «Где это может не сработать?»
• «Пожалуйста, найдите как можно больше дыр в моих рассуждениях»
• «Даже если это технически верно, достаточно ли это понятно для остальной команды, чтобы использовать, диагностировать проблемы и развивать дальше?»

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

Зрелые инженеры понимают нетехнические аспекты того, как их воспринимают.

Умение написать фильтр Блума на Erlang или писать многопоточный код на C во сне — этого недостаточно. Всё это не имеет значения, если никто не хочет с тобой работать. Зрелые инженеры знают: неважно, насколько полными, элегантными или превосходными будут их решения, если никто не хочет работать рядом с ними из-за того, что они м---ки. Высокомерие, унижение, нарциссизм и самолюбование посылают другим инженерам сигнал (возможно, неявный) держаться подальше. Радость от инженерной работы во многом связана с удовольствием от общения с людьми, с которыми ты проектируешь и строишь что-то. Инженер, который быстро называет кого-то идиотом, обречён на застой в карьере.

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

Я упоминал об этом ранее, но должен подчеркнуть: степень желания других людей работать с вами напрямую влияет на успех вашей карьеры инженера. Станьте тем инженером, с которым все хотят работать.

Это не означает, что нужно избегать конструктивной критики работы, созданной в процессе разработки (в отличие от критики самого инженера как личности), из страха кого-то обидеть. Есть разница между тем, чтобы назвать кого-то идиотом, и тем, чтобы указать на недостатки в его коде или продукте. В разговоре с Тео он отметил ещё одну область, в которой наша отрасль может повзрослеть:

Нам как индустрии нужно (конечно же) воздерживаться от критики человеческого характера и личности, но не уклоняться от критики результатов работы. Нам нужно стать менее чувствительными и уметь воспринимать критику так, чтобы она не была направлена на личность. Да, м---ки будут всегда — их следует избегать. Но отношение к своему коду как к своему ребёнку должно уйти в прошлое. У кода нет чувств, он не получает комплексов и точно не обладает самой важной чертой (способностью к размножению) того, что несёт ваши гены.

См. также пункты №2 и №10 в Десяти заповедях программирования без эго ниже.

Мне кажется, это связано с цитатой из Неписаных законов (выделено мной):

Будьте осторожны, кому вы отправляете копии писем, служебных записок и т.п., когда затрагиваются интересы других отделов. Много проблем было вызвано молодыми людьми, рассылающими служебные записки с вредными или компрометирующими заявлениями.

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

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

Я определённо (так же, как Кристофер Браун упомянул в своём выступлении на Velocity London) обращаю внимание на такие публичные высказывания, чтобы запомнить, кого я бы дважды подумал нанимать, если они когда-нибудь подадут заявку на работу в Etsy.

Зрелые инженеры не боятся давать оценки и постоянно стараются в этом совершенствоваться.

Из Неписаных законов:

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

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

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

Этот код выглядит хорошо, я собой горжусь. Я попросил других людей его проверить и учёл их замечания. А теперь: как долго он проживёт, прежде чем его перепишут? Когда он попадёт в продакшн, как его выполнение повлияет на использование ресурсов? Насколько, по моим ожиданиям, вырастет или снизится нагрузка на CPU/память/диск/сеть? Смогут ли другие понять этот код? Делаю ли я его максимально простым для расширения и анализа другими людьми?

Зрелые инженеры понимают, что не все их проекты полны звёздной работы на сцене.

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

Добиваться результатов — значит делать то, что может быть вам неинтересно. Неважно, насколько захватывающим или привлекательным кажется проект, в нём всегда есть скучные задачи. Утомительные задачи. Задачи, которые менее зрелый инженер может счесть ниже своего достоинства или должности. Мой хороший друг Келлан Эллиот-МакКри (технический директор Etsy) сказал об этом так:

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

Зрелые инженеры повышают навыки и экспертизу окружающих.

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

В Etsy мы называем это «щедростью духа». Щедрость духа — одна из наших основных инженерных ценностей, а также ключевая обязанность должности Staff Engineer, карьерного уровня. Эти инженеры тратят время на то, чтобы младшие или новые инженеры, незнакомые с нашими технологиями или процессами, не только понимали, что они делают, но и почему они это делают. «Научить ловить рыбу» — обязательный навык на этом уровне, и он требует и терпения, и понимания ценности инвестиций в развитие всей организации.

То есть вместо: «Ладно, отойди, дай я сам сделаю» должно быть: «Ладно, давай сделаем это вместе. Я покажу тебе, как я пишу/отлаживаю/и т.д. Потом ты сделаешь это сам, чтобы я убедился, что ты понимаешь, почему и как мы делаем это именно так».

См. также: ниже о получении признания.

Зрелые инженеры понимают разницу между наставничеством и спонсорством, и вырабатывают привычку ко второму.

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

Развить это как привычку требует усилий, но преимущества многочисленны: инженер оттачивает навыки критического мышления («о, то, что мы обсуждаем на этой встрече, было бы отличной возможностью для $ИМЯ поработать над…»), а спонсируемый инженер получает возможности, которых у него иначе могло бы не быть.

Статья Лары Хоган на эту тему — обязательна к прочтению:

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

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

Что на самом деле чаще всего нужно представителям недопредставленных групп в технологиях — это возможности и видимость, а не советы. Им приходится работать невероятно усердно и быть невероятно хорошими в том, что они делают, чтобы бороться с системными привилегиями и бессознательными предубеждениями в наших рабочих средах. Их постоянно недооценивают при повышении и недоплачивают за их работу, хотя она превосходна.

Лара приводит примеры, демонстрирующие, как это может выглядеть:

Вот реальные примеры спонсорства, которые, как я видела, работают:

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

Зрелые инженеры делают свои компромиссы явными при принятии решений.

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

Они знают, что работают в спектре между идеальным и неидеальным, и спокойно к этому относятся. Они спокойны, потому что стремятся сделать идеальное и неидеальное в проекте явным. Позже, когда первоначальное решение перестанет масштабироваться или потребует замены или переписывания, они смогут оглянуться не с позиции «какими же недальновидными были те ранние решения», а вместо этого сказать: «Да, мы дошли до этого момента, и знали, что в какой-то момент придётся расширять или менять это. Похоже, этот момент настал, приступим к работе!» — вместо ворчливого, пассивно-агрессивного замечания, наполненного искажением ретроспективы и альтернативными сценариями (например: «эти идиоты не сделали правильно с первого раза!», «они срезали углы!», «Я ЖЕ им говорил, что это не сработает!»)

Существует множество ёмких цитат, проливающих свет на эту идею компромиссов, и зрелые инженеры знают, что у любых философских цитат есть ограничения (включая те, что я пишу здесь):

• «Преждевременная оптимизация — корень всех зол» — сильно избитая максима, о которой я писал ранее. Следствием может быть (взято отсюда): «Понимание того, что является, а что не является "преждевременным", отличает старших инженеров от младших».
• «Правильный инструмент для работы» — ещё одна избитая фраза. Идея разумная: кто захочет использовать неподходящий инструмент? Но редко встречается понимание, что это может быть вредно, если довести до крайности. Плотник не берёт с собой все возможные варианты и размеры молотков, хотя может столкнуться с задачами по забиванию гвоздей, для которых идеально подошёл бы каждый из них. Почему? Потому что носить с собой (и обслуживать) миллион молотков — дорого. Таким образом, решения на этой оси имеют компромиссы.

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

(См. также: Ваш код может быть элегантным, но мой гребаный код работает)

Зрелые инженеры не практикуют CYAE («Прикрытие своей задницы в инженерии»)

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

Пример CYAE: «Это не моя вина. Они сломали это, они использовали это неправильно. Я построил согласно спецификации, я не могу нести ответственность за их ошибки или неправильную спецификацию».

Зрелые инженеры эмпатичны.

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

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

Они не жалуются впустую.

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

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

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

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

Отличный список существует в Википедии, но вот некоторые из тех, жертвами которых я видел инженеров (включая себя):

• Эгоцентрическая атрибуция — в основном: если что-то хорошее, это, вероятно, благодаря чему-то, что я сделал или придумал. Если плохое — вероятно, это дело рук кого-то другого.
• Фундаментальная ошибка атрибуции — в основном: плохие результаты, которые кто-то другой получил от своей работы, должны быть связаны с тем, какой он есть лично (глупый, неуклюжий, небрежный и т.д.), тогда как если я получаю плохие результаты, это из-за контекста, в котором я находился, давления, которое на меня оказывалось, ситуации, в которой я был, и т.д.
• Искажение в ретроспективе — (говорят, это самый изученный феномен в истории современной психологии) в основном: после неблагоприятного или негативного события (серьёзный баг, сбой и т.д.) «Я знал это с самого начала!». Это очень сильная тенденция рассматривать прошлое более просто, чем оно было на самом деле. Вы можете определить искажение в ретроспективе, когда в описаниях фигурируют альтернативные сценарии, или «...им следовало бы...», или «...как они могли не увидеть — это же так очевидно!».
• Искажение результата — как и выше, это проявляется после неожиданного или негативного события. Если событие было очень разрушительным, дорогим в устранении или серьёзным, то решения или действия, которые к нему привели, оцениваются как очень глупые, безрассудные или небрежные. Суждение пропорционально серьёзности события.
• Ошибка планирования — (связана с пунктом о составлении оценок в условиях неопределённости выше) в основном: быть более оптимистичным в прогнозировании времени, которое займёт конкретный проект.

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

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

Уместно, даже если и старо... Я видел ссылки на это как на выдержку из книги Психология программирования, написанной в 1971 году, но на самом деле не вижу этого в тексте. В любом случае, вот Десять заповедей программирования без эго, найденные в блоге @wyattdanger в посте о совете от его отца:

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

Новички против экспертов

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

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

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

(что означает, что новички глубоко подвержены локальной рациональности)

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

(что означает, что эксперты ориентированы на контекст)

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

Грязный секрет: зрелые инженеры знают важность (иногда иррациональных) чувств людей (ооххх!)

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

Уверенность людей в программном обеспечении, архитектурах или паттернах сильно зависит от прошлого опыта и может привести к положительным или отрицательным реакциям на их использование. Работали раньше в компании с mod_perl, где было много загадочных сбоев? Тогда неудивительно, что вы неохотно будете использовать его в другой компании, даже если поддерживающая экспертиза и сценарии использования совершенно другие. Всё, что вы помните — это mod_perl = серьёзные головные боли, так что вы будете опасаться использовать его снова в любом контексте.

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

Для иллюстрации того, как эмоции людей управляют техническими решениями и мнениями, прочитайте любой флейм о чём угодно, когда угодно.

«Удивительно, чего можно достичь, если вам всё равно, кто получит признание»

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

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

Не конец

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

Огромная благодарность членам операционной команды Etsy, Майку Бриттейну, Келлану Эллиоту-МакКри, Марку Хедлунду и Тео Шлосснагле за рецензирование черновиков этой статьи. Все они делают меня более зрелым инженером.