Что такое архетип? Это — образец набора вариантов поведения или поведенческих сценариев, типичных для определённой роли. Уилл Ларсон, который сейчас занимает должность главного технического директора в Carta, определил четыре архетипа для должности «ведущий инженер‑программист» (Staff Engineer). Это — «техлид» (Tech Lead), «архитектор» (Architect), «решатель задач» (Solver) и «незаменимый помощник» (Right Hand).

Я работаю над новой книгой, которую планируется опубликовать этой осенью. Она называется «The Software Engineerʼs Guidebook». Когда я писал в ней об архитектуре ПО, меня зацепила идея существования «архетипов» программных архитекторов, которые могут сочетаться друг с другом либо хорошо, либо плохо. Речь идёт о людях, работающих бок о бок друг с другом, вклад каждого из которых в общее дело отличается чем‑то особенным. Разбираться с тем, какие архетипы лучше всего описывают коллег — это интересное занятие, которое может привести к ценным открытиям. И вполне возможно, что вы, задумываясь об этом, поймёте, какой из архетипов лучше всего описывает вас самих.

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

Сегодня мы поговорим о 12 архетипах программных архитекторов, все из которых, за исключением двух, выявлены мной. Первый — «архитектор в башне из слоновой кости» (The Ivory Tower Architect). Этот архетип часто встречается в технических компаниях. Второй — «архитектор-машина для программирования» (The Coding Machine), о котором я впервые узнал, исследуя особенности корпоративной культуры Facebook^*.

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

Люди, кроме того, меняются со временем. «Архитектор в башне из слоновой кости», воспринимаемый коллегами как человек, с которым тяжело установить контакт, может профессионально вырасти и перейти в архетип «архитектор, открытый для контакта» (The Approachable one). А теперь — к делу!

Да, ещё одно: рассматривайте эти «архетипы» как нечто вроде черт характера человека. Дело в том, что люди могут одновременно демонстрировать (и демонстрируют!) многие из нижеописанных архетипов. Благодарю читателя Drew Miller, указавшего на это в комментариях.

1. Архетипы, больше ориентированные на теорию, а не на практику

1. «Архитектор в башне из слоновой кости» (The Ivory Tower Architect)

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

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

2. «Болезненно точный архитектор» (The Painfully Precise)

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

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

3. «Архитектор-приверженец теории» (The Theory Addict)

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

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

4. «Архитектор-философ» (The Philosopher)

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

В чём тут подвох? Дело в том, что после того, как к дискуссии подключается «философ», возникает такое ощущение, что эта дискуссия может никогда не кончиться. Хлеб этого архетипа — исчерпывающие, всеобъемлющие обсуждения. А такой подход к делам может привести к конфликтам с представителями более практических архетипов. Их устраивают решения, которые можно оценить как «приемлемые», а всё, к чему они стремятся — делать дело. Благодарю Ebi за упоминание этого архетипа!

5. «Архитектор-блестящий лингвист» (The Superior Linguist)

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

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

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

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

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

6. «Архитектор-уходящий советчик» (The Walk-Away Advisor)

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

Если команда зайдёт в тупик — что ей делать? Придерживаться позиции «уходящего советчика» даже в том случае, если эта позиция всё сильнее расходится с реальностью? Или найти этого «советчика» и попросить у него нового совета? А может просто взять дело в свои руки, учитывая то, что «уходящий советчик» не играет в проекте никакой роли?

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

2. Архетипы, больше ориентированные на практику, а не на теорию

7. «Архитектор-машина для программирования» (The Coding Machine)

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

В Meta «Coding Machine» — это архетип, расширяющий должность Senior Staff Engineer, изначально созданный для Майкла Новати. Сейчас он — сооснователь платформы Formation, где программисты могут улучшать свои навыки, занимаясь с наставниками. Он рассказал мне о том, как появился этот архетип, о чём я писал в статье об инженерной культуре в Facebook:

В Facebook главное — это справедливость. Я был «самым крупномасштабным» коммиттером в проекты компании, но когда меня откалибровали по уровню E7 в других областях — а такой уровень давали очень немногим людям, всего их около 100 — оказалось, что моё воздействие на компанию ещё недостаточно велико, не соответствует такому уровню.

Я очень старался, чтобы мои усилия заметили. Я, кроме того, провёл в это время более 300 собеседований, работал и над другими важными сторонними проектами. Я так понимаю, что мой технический директор в то время описал архетип «Coding Machine» и представил его калибровочной группе, которая занималась рассмотрением всех сотрудников уровня E7 в компании. Эта группа приняла его материала и добавила этот архетип в список других архетипов.

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

8. «Архитектор-интегратор» (The Integrator)

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

«Интеграторы» — люди, приносящие огромную пользу компаниям, в которых имеется множество сложных систем. Это может быть стартап, скейлап или Big Tech-компания. Благодаря своим практическим знаниям, «интеграторы» часто могут предложить компании изящные «обходные пути» и красивые «хаки», которые позволяют избегать возникновения ситуаций, требующих внесения больших неуклюжих правок в проекты. Напомню, что в Big Tech-компаниях тоже может встречаться низкокачественная инженерная культура.

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

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

Но эти архетипы обычно, в больших компаниях, сталкиваются со сложностями при продвижении по корпоративной лестнице на должности выше уровня Staff Engineer. Дело в том, что на такие должности обычно попадают люди, которые ближе к теории, а не к практике. Но это не так в компаниях, где руководство сознательно продвигает людей, относящихся к подобным архетипам. Так было сделано в Meta, где в систему карьерных уровней компании ввели архетип «Coding Machine».

9. «Архитектор, открытый для контакта» (The Approachable one)

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

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

10. «Архитектор-любитель подробной документации» (The Detailed Documenter)

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

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

11. «Архитектор-охотник за новым и ярким» (The New and Shiny Chaser)

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

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

12. «Олдскульный архитектор» (The Old Schooler)

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

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

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

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

Если подойти к разработчику и спросить: «Привет! Что тебя осчастливит?», — во многих случаях на этот вопрос будет дан очень особенный ответ. Например — «Я был бы счастлив, если бы мог писать на работе на Clojure. Поэтому вам надо позволить мне решать рабочие задачи на этом языке». Я не сбрасываю со счетов то, что, давая такой ответ, разработчики искренне описывают некий опыт, который они когда-то пережили, опыт, который переполнил их счастьем.

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

Правда, и я когда-то был таким же.

Он рассказал и о том, как эволюционировало его мышление:

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

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

Но программное обеспечение, которое существует уже достаточно длительное время, обычно нуждается в меньшем «уходе», оно «потребляет» меньше «пищи», чем ПО, которое только что вышло.

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

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

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

Продолжение следует...