Хорошие программисты редко также хорошо управляют большими командами, люди, спроектировавшие крупнейшие онлайн-миры, обычно неизвестны никому за пределами профильных конференций, а самые крупные игровые студии построили люди, которые и в игры то не играли. Если вам кажется, что эти три факта между собой не связаны, дочитайте до конца, потому что связаны, и ещё как.
Разговор о карьере программиста часто скатывается либо в обсуждение грейдов «чем L6 отличается от L7», либо в спор «менеджмента команды против экспертной стези», как будто путей всего два. Расскажу про разработку игр и примеры моих знакомых, потому что они прямо сейчас у меня перед глазами.
У сеньора в геймдеве есть минимум три принципиально разных направления роста, каждый отличается не только строчкой в названии должности, но и вообще пониманием мира и проекта в этом мире. Один видит систему систем, второй работает с подсистемами, а третьему уготована встреча с продуктом, рынком и людьми, для которых всё это вообще затевалось.
Программист первые лет пять-семь набирает массу, т.е. учит язык, движок, отладчик, хардвару и этот.участок пути обычно хорошо размечен предшественниками в виде туториалов, курсов, менторов, код-ревью и грейдов. А потом разметка заканчивается и человек становится сениором, и выясняется что указателей дальше нет, и большинство узнаёт о существовании развилки уже после того, как случайно свернуло на одну из дороже. Проблема в том, что пути часто требуют противоположных навыков, и прокачка одного будет идти за счёт других.
Архитектор учится не писать код сам, и даже не ревьювать решения команды, а принимать решения куда вообще этой команде идти. Техлид учится не отвлекаться на людей, как в плане задач, так и в плане принимаемых решений, потому что любое решение может быть реализовано десяться разными способами и какое будет верное может ответить, разве что архитектор, но ему должно быть пофиг.
Продюсер учится не думать о коде вообще, это бывает тяжко, потому что за десять пятнатдцать лет код настолько вьедается в образ мыслей, что не думать категориями проекта и задач уже становится сложно, если не сказать больно. Карьерное дерево после сеньорской позиции не умеет в «иногда», а попытка идти по всем трём, или хотя бы по двум веткам одновременно обычно даёт человека, который посредственно делает три работы. Как в том анекдоте про целовать девушку и управлять авто, и если попробовать делать их вместе, то обе получаются плохо.
text Junior ──► Middle ──► Senior ──► ???
│
┌──────────────┼──────────────┐
▼ ▼ ▼
Архитектор Техлид Продюсер
(система (технология (продукт
систем ) и глубина) и рынок)Но все три дороги просто разные ответы на один и тот же вопрос о том, куда девать накопленную инженерную массу, когда писать код быстрее уже не получается, потому что знаний накоплено уже на двух-трех, иногда больше человек, а писать в два-три-десять раз кода физически не получается.
Архитектор
Можно уйти в архитекторы и начать проектировать масштабные системы, масштабные в том плане, что один, и два и три человека её не напишут за обозримое время. Тут соотношение программирования и управления болтается в районе фифти-фифти, но по большей части архитектор не пишет код вообще. Либо в одиночку делает шаблоны и каркасы систем, а весь объём работы, который в любом случае превышает возможности нескольких человек, приходится отдавать привлеченным человеческим ресурсам… со всеми вытекающими.
Область интереса архитектора это не всегда отдельная система, а часто взаимосвязи систем между собой: что с чем общается, где границы, кто кого может уронить и почём обойдётся договориться об интерфейсе. Ключевое отличие от техлида, что архитектор оперирует горизонтами, планами и вопросами «как это будет ломаться, когда станет в десять раз больше».
Это не делает его умнее, просто нужен другой склад ума, и хороший архитектор может откровенно плавать в деталях конкретного лок-фри контейнера, но “инженежрно чувствует” (не ошибка, просто термин tendergineering [ спроектировал систему технически выверенно, но при этом изящно ] не переводится нормально), что вот эту подсистему через год придётся переписывать, потому что она завязана на предположение и не переживёт рост онлайна.
Примеры из игрового мира, Максим Барышников, который шесть лет архитектурно развивал движок BigWorld для World of Tanks и с командой дотащил проект до состояния, когда инфраструктура держит миллион, если мне не изменяет память, пользователей онлайн. Это тот случай, когда архитектура держится на одном человеке.
Цена пути в том, что архитектор постепенно теряет чувсто кода. Не потому что глупеет, просто час, потраченный на код, это зря потраченный час архитектора на код, а написанные несколько строчек кода оставят команду без нормальных интерфейсов между тремя системами.
Техлид/Техдир
Этот человек очень хорошо разбирается в технологиях и вероятно больше всех в команде программирует, больше всех исследует, и область его интереса подсистемы или подсистема, которой он занят прямо сейчас, плюс её связи с соседями. Не «система систем», как у архитекта, а конкретный кусок реального кода: может рендер, может сеть, или физика, или интерпретатор скриптов. Неважно что, важно докопаться до дна, а если дно оказалось фальшивым, то и до следующего.
Тут даже примеры подбирать не надо, Джон Кармак, человек , который десятилетиями делает одно и то же, берёт область (софтверный рендер, OpenGL, VR, сеть, физика) и вгрызается в неё до уровня, на котором с ним становится не о чем спорить.
Характерно, что Кармак при всей своей известности почти никогда не управлял большими командами и не строил процессов, но зато строил технологии, а процессы вокруг него строили другие.
Или Роберт Найстром, другой типаж техлида с его «Game Programming Patterns» и «Crafting Interpreters». Это книги человека, которому интересно не просто сделать, а понять до конца и объяснить так, чтобы поняли остальные в команде. Техлиду хорошо, потому что он единственный из всех, кто продолжает идти по дороге приключений разработки руками, за что когда-то полюбил профессию.
За все приходится платить… Хм… где-то я уже это писал. Цена пути в высоте потолка влияния, потому что технический человек, пусть даже гениальный и с кучей влиятельных друзей и коллег, упирается в размер того, что можно удержать в одной голове.
Индустрия полна примеров, когда блестящая технология умерла, потому что её автор не смог или не захотел объяснить её ценность тем, кто распределяет бюджеты. Да, обычно это самая низкооплачивамая позиция из всех, потому что деньги обычно достаются продюсеру, а слава уходит архитектору. Техдир без влиятельного продюсера и толкового архитекта рискует всю жизнь точить идеальную подсистему для продукта, которую никто не увидит и не оценит. Кармак и Найстром скорее всего исключения.
Продюсер
Или Founder, если со своим капиталом, находится дальше всех от программистов и разрабоки, потому что уже давно делает не игры, а делает деньги. Ему важнее знать о продукте, рынке, работе с людьми и производственных пайплайнах, чем о новом стандарте C++.
И почти всегда он больше не программирует, потому что область его интереса уже готовая игра целиком, и мысли про то, что увидит игрок, и сойдётся ли юнит-экономика. Продюсер это уже не «бывший программист, который сдался», а человек, который однажды заметил, что баги проекта живут не в коде и игра с идеальным движком и непонятной целевой аудиторией умирает так же надёжно, как и игра с багами и кривым кодом. В конечном счете, самый качественный инструментарий бесполезен, если он не служит цели создать законченную игру, которая не просто работает, а еще продается и находит отклик в руках игрока. Не ждите от продюсера понимания программерских проблем, он уже не с нами, но бывает и другому.
Джонатан Блоу один из примеров тру-инди-продюсера, который, правда, периодически надевает то шляпу архитектора (свой язык Jai это больше про архитектурный слой), то шляпу техлида, с выступлениями на GDC. Или Ник Атамас, который по профессии скорее техлид, потому что запили фактически в одиночку Slate для Unreal, но по типу общения и кругу рассматриваемых проблем был больше продюсерем, и его переход в стартап был только вопросом времени.
Цена пути очевидна и она самая высокая из трёх дорог, вы больше не будето кодить. Код уходит насовсем, вместо кода будут орг вопросы, деньги, привлечение инвесторов и отчет перед акционерами. Через пять лет продюсер открывает свой старый репозиторий с чувством фоточек из школьного альбома, узнавания без малейшего желания вернуться. Деньги? Деньги есть… а вот счастье.
Гибриды
В реальности все приведенные выше типы скорее не клетки, а аттракторы, точки притяжения. Человека тянет к одному из них, но в течение карьеры он может дрейфовать, а в маленьких студиях вынужден тянуться в разные стороны по очереди, иногда в течение одного рабочего дня. Тот же Блоу (Braid и The Witness) вылитый продюсер, который вечерами пишет компилятор, а Кармак явный техлид, чьи технологические решения определяли архитектуру целых поколений движков, но вынужден решать с командой какую игру строить вокруг новой технологии. Но такие люди скорее исключения, чем правило.
Любой архитектор успешной MMO неизбежно начинает рассуждать про возврат игроков, потому что архитектура шардинга и монетизация связаны очень тесно, и хочешь не хочешь, а приходится идти к маркетингу и решать совместные вопросы, или рекламщикам и согласоывать время и бюджеты. Да и выходя за пределы уютной студии начинаешь видеть как эта градация протекает в названия вакансий.
Подозрение, что эта развилка не есть болезнь одного только геймдева. В книга-лицо конторе, когда инженеров стало не сотни, а тысячи, выяснилось, что мерить всех по скорости написания буковок больше не выходит, и кто-то решает сложное медленно, пишет мало, зато умножает выхлоп целых команд. Пришлось формализовать архетипы сеньоров, которых вдруг оказалось целых шесть: Generalist, Specialist, Coding Machine, Tech Lead, Fixer и Product Hybrid (последний «Coding Machine», к слову, описали под конкретного человека, годами бывшего топ-коммиттером всей компании). Один в один на мою тройку это не ложится и у них Tech Lead так и зовётся Tech Lead, безо всякого корпоративного диалекта, но грабли те же и тот же набор “склада ума” и та же оговорка, что архетип не клетка и можно «мультиклассить», переходя между ролями. Так что есть основания полагать, что эта градация свойственна не только игровым конторам, просто в геймдеве она виднее, потому что студии мельче и шляпы приходится менять чаще.
Переходы между архетипами возможны, но очень несимметричны. Техлид спокойно может вырасти в архитектора, и это скорее естественный рост, когда накопленная глубина знаний конвертируется в широту. Или архитектор может уйти в продюсеры, тут тоже понятный маршрут, потому что от системы систем до системы «продукт-рынок» всего несколько шагов и другие паттерны применения. А вот обратный ход почти не встречается и продюсер, возвращающийся в техлиды или архитекты, персонаж примерно той же байки, что генерал, возвращающийся в снайперы. Теоретически руки помнят, а практически за время отсутствия поменялись и винтовки, и война.
Здесь, однако, стоит рассказать про супер-продюсеров и факты, что я обещал в начале статьи, про студии, которые построили люди, в игры толком не игравшие. Боб Котик выкупил почти банкротную Activision в начале девяностых, и он не был фанатом, по собственному признанию, не был заядлым игроком или хорошим программистом. Точнее, он вообще не был программистом. В студенчестве он подержал в руках Arktronics и продавал игры для Apple II, но писал их его друг Говард Маркс, не он, так что «стартовым капиталом» код для него и правда был.
Зато увидел “новую нефть”, где остальные видели выжженые поля и привёл в разработку менеджеров из мира стирального порошка и консервов. Вынул из процесса разработки всю романтику, превратив выпуск игр в предсказуемый конвейер, и тридцать лет спустя Microsoft купила этот конвейер за $69 миллиардов. Это тип супер-продюсера, для которого код никогда не был ни любовью ни средством заработка, а в лучшем случае стартовым капиталом, но чаще даже им не был. Архитектор и техлид строят системы, маленькие или большие, свои или дорабатывая чужие, потому что им интересно как устроен и работает код.
Продюсер и супер-продюсер строят компанию, потому что ему интересно как работают деньги и мы подходим к пониманию, почему хороший программист редко хорошо управляет большой командой. Не потому, что глуп и нет навыков, а потому что управление командой держится на вопросах про деньги, людей и рынок, от которых хороший программист сбегает в код и разработку. Наивно ждать, что он вдруг эти вопросы полюбит, когда команда вырастет.
Мистер тостер
Есть, впрочем, еще один типаж, которого ни в одной карьерной схеме не нарисуют, потому что рисовать неловко. Он не лучший архитектор, не самый глубокий техлид и не самый крутой продюсер, зато он всегда оказывается за столом, где после третьего тоста решается, какому проекту урезать денюжку и куда её передать. Он может писать код, или чертить схемы или считать юнит-экономику, но лучше всего он умеет вовремя оказаться рядом, к месту пошутить и расположить к себе тех, кто держит банк. Технически он может не уметь ничего, но обладает редчайшим в инженерной среде навыком “запоминаться”. И его помнят и любят люди, принимающие решения.
И на длинной дистанции карьеры это нередко бьёт и архитектуру, и глубину, и продуктовое чутьё, потому что блестящая подсистема, о которой никто наверху не знает, проигрывает посредственной, у которой нашёлся веселый и шумный защитник за нужным столом. Цена пути? Её платят остальные… Назову этот архетип уклончиво “человек-коннектор” или “человек-тостер”, и сделаю вид, что речь про нетворкинг.
Ориентиры
Если попробовать собрать единое видение, то примерно понять куда вас тянет можно по вопросу “а чего вы делаете в прокте первым делом?”. Архитектор будет рисовать схемы связей и искать проблемы под нагрузкой. Техлид пойдет ковырять самую интересную подсистему и читать код, пока не поймёт, как она работает. Продюсер пойдет мучать людей вопросами, ну или петь тут должно быть другое слово с начальством, что тоже решает много вопросов, просто уже в другом плане.
Если этот вариат не сработал, то надо смотреть от чего вы устаёте меньше. Архитектор не устаёт от разборов полетов и ревью, техлида не тошнит от документации, а продюсер может часами зависать на митингах с неопределенными задачами. От чего устаёте меньше всех, значит туда и дорога, потому что на дистанции в десять лет выигрывает уже не талант и знания, а низкая стоимость ежедневного существования в роли.
А можно не выбирать… Это тоже можно, но тогда выбор сделают за вас, потому что сеньор, который не выбрал направление, не останется универсалом, он становится тем, кого можно назначить по обстоятельствам, обычно в момент очередной реорганизации. Весь вопрос в том, выбрали это место вы сами, или оно выбралось само, пока вы закрывали спринт.
Автор: dalerank
