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

Навыки есть? А если найду?

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

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

Как-то к нам пришел очень крутой разработчик физики, очень... его переманивали год на разные проекты и под разными предлогами, а физику на том проекте настраивали через таблицы в текстовых файлах и lua-скрипты, а не через движковые параметры (ну вот так исторически сложилось), и первые недели он все время пытался что-то переписать, исправить, доработать, и 90% его изменений заворачивали на ревью, что конечно не добавляло настроение ни ему, ни команде. И визуально он работал заметно медленнее джуна, который пришёл месяцам раньше и просто принял такое положение вещей как данность, но смог пофиксить пару сложных багов, которые висели в беклоге пару лет.

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

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

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

В качестве шутки в одной из студий существовала традиция проверять новых программистов вопросом "как включить wireframe?". Хм... задача очень не сложная, но опять же исторически в редакторе того движка (от известной синей компании) это делалось через три вложенных меню, названия которых не имели никакого отношения к wireframe. Поэтому надо было ручками покопаться немного в коде, погрепать нужные слова, а потом найти нужные пункты в меню... тот кто находил сам или почитал документацию, а там было описание трехгодовалой давности, явно умел читать чужой код. Большинство все-же находили, но один просто написал новую консольную команду, которой и пользовался, странно что у нас не было этой команды, а только хоткей и включение через менюхи.

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

Процессы есть? А если найду?

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

Классический случай с пайплайном, это когда новый сотрудник делает задачу, считает её готовой, закрывает тикет и идёт дальше наносить добро проекту. Но при этом не идёт к QA, не оставляет комментарий в задаче (хотя это прописано в доках на закрытие таски), не сообщает дизайнеру что его часть реализована. Просто потому что на прошлом месте это делал кто-то другой, или это было автоматически и он не задумывался об этом, а потом выясняется что фича висит три недели и никто её не тестировал.

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

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

Легаси есть? А если найду?

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

В другой студии был файл с историческим названием body_collision_final_v3_USE_THIS.cpp (v3 иногда менялся с выходом игры, капс в конце важен, потому что был файл без USE_THIS) , который никто не трогал, потому что он просто работал, а тот кто его написал давно уволился. Его, опять же, по традиции показывали новым программистам и просили предложить решения по модернизации. Реакций тоже было несколько: от ужас-ужас и "я туда не полезу", до философского принятия и "какие сроки", но самая частая быда "давайте напишем правильно". Был один случай на моей памяти, когда человек открыл файл и сказал "о, я знаю этот код, надо поменять тут и тут", - и "нет" - это был не автор. Файл мы конечно никому менять не давали, ибо не сломано - не чини.

В той же студии, для новых графических программистов был свой ритуал, когда им давали задачу добавить эффект в шейдерную систему, не объясняя, что система эта генерирует код во время компиляции из XML-описаний через кодогенерацию, но в принципе это можно было найти в вики, да ктож её читает-то. Первый признак того, что человек разобрался был переход от вопроса "где мне писать vashSL?" к вопросу "где мне писать xml, который напишет vashSL?".

Нормальные люди тут есть? А если найду?

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

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

Где-то нормально говорить напрямую если что-то сделано не так, где-то это воспринимается как агрессия или грубость, где-то ценится инициатива и предложения от нового человека, а где-то ждут что первые полгода он будет просто смотреть.

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

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

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

Готовые рецепты есть?

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

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

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

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

Про техлида Сашу

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

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

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

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

Я как-то завел разговор, "Ну Саш, ну как ты их терпишь, ведь видно же, что человек городит ерунду, проще сразу сказать". На что получил ответ: «мы же его взяли, значит не дурак, просто пока не знает как надо. Я тоже не знал. И ты не знал. Все не знали. Подожди неделю».

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

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

З.Ы. Александр все также работает в Питере, все также делает игры, и думаю все также учит новичков по правилу "подожди неделю"