Spiiin's blog

Адаптация в новой компании

2026/02/21
Tags: dev_evolution

Год назад сменил место работы, подумал написать немного на тему адаптации на новом месте в общем.

Адаптация навыков#

Программист в геймдеве — ёмкая по количеству навыков профессия.

С этим связаны проблемы как при устройстве на работу, так и при адаптации и планировании собственного развития.

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

📍 Из-за специализации возникает проблема, что разбираешься в какой-то одной части технологий, и не особо занимаешься и разбираешься в других.

https://x.com/CaptainGPU/status/2024210673996034427 - пример проблемы, “Разработчику физики в GTA” сложно найти работу в студиях, которые используют Unity/Unreal.
С одной стороны — разработчик физики с большой долей вероятности понимает математику обработки столкновений и основные алгоритмы, которые общие. Отличия на более высоком уровне — “какую галочку нажать в редакторе, чтобы баг ушёл”. Обучиться этому намного проще, если есть база. Но, во-первых — всё равно требует времени, во-вторых — нужно прорваться через рекрутеров, в третьих — доказать, что ты действительно разбираешься в алгоритмах, а не просто пользовался только верхний слоем.

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

Джентльменский набор программиста UE4, ч. 1 - проблемы программистов Unreal, разбираются только в конкретных надстройках движка

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

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

В итоге создается ситуация, когда программистам, с одной стороны, приходится:

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

У программиста с 10-15 летним опытом возникает ситуация, когда на практике на работе он использует 25-50% от того, что знает.
Вдобавок, из-за прогресса получается, что знания устаревают лет за пять (а рекрутерам и компаниям хочется знаний вообще не позднее, чем за последний год-два).

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

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

Адаптация под процессы#

Это относят к широкой категории “софт-скиллов”, но выделил бы тут “процессы” как пайплайн производства фич.

📍 Порядок передачи при производстве фичи. Кто отвечает за передачу готового куска дальше. Нужно ли программисту искать QA, который проверит его код, ревьюера кода, продюсера, от которого получить утверждение? Нужно ли организовывать встречи? Какой уровень необходимого отражения своей активности в таск-трекере? Если к тебе приходят 3 менеджера, с разными запросами, кто разруливает приоритетность их запросов?

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

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

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

Один из путей — “делаем свой конструктор”. Игровая логика либо настраивается через таблицы/продвинутые редакторы (unity-like), либо визуальным программированием (unreal-like), либо блочным программированием (blockly-like). Другой — programming-oriented way (Gaijin, Naughty Dog, Id, Hazelight). Здесь двигаются в сторону создания DSL или языков программирования.

В играх-сервисах, существующих лет десять, можно найти в разных местах остатки нескольких используемых ранее технологий. Использование готовой технологии или движков также может диктовать свою архитектуру. Какая-нибудь “своя Unity” может радикально отличаться в рекомендуемых подходах от самой Unity. Вероятно, в больших проектах, например, на Unreal, также модифицируют движок настолько, что он может серьёзно отличаться для двух различных игр.

Эта часть адаптации под процессы заключается в умении правильно провести границу между используемыми технологиями. “Что делаем на C++, а что вытаскиваем в lua/blueprint/редакторы данных”. В принципе, практически не вызывает проблем, если привык к нужной парадигме и понимаешь, для чего именно делается разделение. Хотя редко увидишь, например, хороший хот-релоад, или действительно быстрое построение удобного редактора данных на лету. И чаще — какой-нибудь монструозный табличный редактор с симуляцией передачи аргументов и данных из внешних контекстов, и ограничения по количеству нод в визуальном редакторе в пару десятков, потому что при увеличении начинаются тормоза.

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

Адаптация под людей#

Ну и наконец, навыки взаимодействия с людьми. Понять, как мыслят люди здесь, что приветствуется и не приветствуется. Модель поведения что ли. Требуется определенный уровень гибкости, чтобы уметь работать в отличающихся коллективах. Это диапазон, в котором работать комфортно. Также с определенного момента формируется твоя роль в команде. Здесь, как и с навыками, существует определенный зазор между всем, что ты можешь делать или делал в предыдущей компании, и что реально будешь делать на своей должности. Также так или иначе, требуется подстройка под конкретных людей, просто чтобы научиться немного считывать их. Существуют ли в компании ценности, которых придерживаются работники? Что абсолютно неприемлемо? Есть ли “особое” начальство, под которое нужно подстраиваться? Культурные или национальные особенности? О чем идут разговоры на кухне? Как попасть на другую должность или другой проект? Где узнавать официальные или неофициальные новости компании? Есть ли неформальные активности?

Что могло бы упростить жизнь всем#

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

К сожалению, в компаниях с внутренними технологиями оунеры часто рассматривают открытие кода с позиции “а что у нас от этого заколосится?” или “а будет ли нам имиджевая польза от этого?”. А также с позиции “если я занимался на этой должности 5 лет созданием этого движка, но в новой смогу заниматься еще 5 лет таким же для них”. С позиции бизнеса пользы нет, но с позиции программиста как наемного работника было бы лучше иметь возможность пользоваться открытыми технологиями в разных компаниях, а не отбрасывать свои навыки, и тратить время на изучение/пересоздание других закрытых технологий.

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

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

📍 Обучение. Симбиоз компаний и университетов. А также выделяемое бизнесом время на обязательное обучение. Сейчас правда качество конференций и курсов часто выглядит сомнительно, как будто этим занимаются те, кто не может найти себе место в разработке. Как будто был взрыв количества доступной информации в период 2005-2010. Книги, блоги, конференции. Дальше почему-то многое замолкло.

📍 Майнд-сет. Желание улучшить свою жизнь и жизнь окружающих. Не софт- и не хард-скилл, а этика, определение правильного и неправильного.

  • Мотивация "честного" программиста — написано красиво, но откровенно говоря, далеко не в каждой компании есть возможность работать так. И не всегда есть силы. Но возможно.
    How To Become A Hacker — хакерская этика, ни одна проблема не должна решаться дважды.

📍 Преемственность.