Comments 20
Перед ответом добавлю немного контекста.
Найти хороший бекенд с опытом игровых проектов - сложно
Вакансия в компании очень долго была в подвешенном состоянии
Уровень зарплаты в студии для разработчиков был выше среднего по рынку
Общая стоимость техники: системник и 2 монитора была около 2000$. И конечно, это не было безвозвратно. Эта была самая рядовая процедура передачи техники на время работы.
Я ниже пытался ответить автору, но чуть промахнулся... Конечно же разница в стоимости техники (тем более если это стационар, у него даже внешний вид не так теряется как у ноутов) относительно зарплаты невелика. Но ведь финансовые решения это не зона ответственности сисадмина, если только не было явно ему передано, хотя и в этом случае получается что попытка перейти через голову привела к ожидаемому посылу на самую верхушку, к условному арбитру в лице CEO...
В общем, как ни пытаюсь найти оправдание наезду, не получается. Скорее выглядит как обычный рабочий конфликт на стыках зон ответственности.
Очень уж выглядит как попытка влезть в устоявшиеся процессы выдачи техники без учёта текущего положения дел. Хотя в последних абзацах написано что не надо ужасаться, а надо разобраться.
Кстати, это выглядит ещё и как факап HR отдела, которые были обязаны передать требования (а не пожелания) звезды сисадмину и/или отделу. Иначе с какой радости давать нестандартный комп? :) У него же первым могут спросить.
Найти хороший бекенд с опытом игровых проектов - сложно
я хороший бэкенд (15 лет .NET) с небольшим опытом игр (около года) и хочу перейти из корпоративной разработки в игровую. На сколько меньше платят в играх?
на HH вижу что вакансий раз в 6-8 меньше
Приходя на существующий проект, который уже разрабатывается какое-то время - никогда, не начинайте сразу ужасаться тому в каком он состоянии и пытаться переписать все, обвиняя попутно команду в некомпетентности.
Несколько раз такое было, когда получалось убедить - проект развивался и двигался вперед. Когда не получалось убедить - через полгода слышал "ты плохо тогда старался и не смог нас ВСЕХ убедить, насколько все плохо".
Дополню автора:
В “нашем” представлении руку к коду игры придется прикладывать везде и часто.
Честно говоря, очень странное представление о работе СТО в таких компаниях. Сам в геймдеве уже больше 9 лет, и на практике, уже на уровне лида с командой из 4-5 программистов, на написание кода остается меньше 10% времени.
Если же СТО садится писать код, то в процессах такой компании, на мой взгляд, такой бардак, что от туда нужно бежать как можно скорее. (Ну или это совсем небольшой стартап где каждый человек совмещает по несколько позиций)
Очень странное ожидание для CTO, что за него кто-то наладит процессы в его же отделе. Его для этого и берут - из хаоса делать порядок. Если в компании уже говны, то это просто значит, что работа сложнее будет, чем когда уже кто-то другой все выстроил.
так CTO и должен построить нормальные процессы, а не бежать, если до него никто их не выстроил
Как всегда не бывает только белого и черного. Ты прав в том, что в нашем понимании времени на код остаться не может или будет очень мало. Под исключения должны попадать разве что стартапы и небольшие проекты/команды, где СТО он и дев. лид и тех. лид и может даже ПМ. Буквально в этом году в одной из компаний ру пространства, где в проект было инвестировано очень и очень много у меня состоялся разговор с СЕО команды, который прямым текстом объяснял, что ждут они что код будет писаться руками СТО быстрее, чем кого-либо и это было требование. В результате оказалось, что все это требование в написании кода уходит корнями в состояние процессов. А процессы поставить на ноги придется:
1. Поменять часть команды, что на том этапе проекта надо было делать очень осторожно
2. Задать правила/стандарты/регламенты
3. Подтянуть общее состояние кода и стабильности. И вот тут на старте самому придется в это погрузиться очень глубоко и действительно писать код.
Я это к тому, что звучащие порой от бизнеса требования "будешь писать код", на самом деле уходят в состояние процессов, но чтобы их поправить, возможно действительно придется запускать руки очень глубоко.
А мне понравилась классификация. В ЕС действительно бывают очень бизнес-СТО, и также есть технические эксперты, между ними создаётся баланс. На мой взгляд, корнями это уходит в достижение баланса личной жизни и работы в культуре многих стран ЕС. В этой парадигме программирующий СТО – это совмещение 2-3 ролей в одной, что подразумевает отказ от остальной жизни, не говоря уже о том что это может разрушить процессы. Конечно, всегда есть исключения – компания из 3 человек, или гений-whizkid.
Самым недавним событием стало собеседование за партией в League of Legends
ЗП зависела от фарма/кда? А вообще, инетерсный способ проверить навыки коммуникации и лидерские качества, особенно в затяжных матчах.
Довелось пошерстить рынок некоторое время назад. Действительно, небольшие компании под CTO (Head of Development, VP Engineering, ...) подразумевают старшего программиста. При этом всё же подразумевая, что он будет и CTO одновременно :) Иногда не предлагается даже опцион, то есть на зарплату на такую тяжелую роль. Хороший ответ им, на мой взгляд, таков: в этом случае вам нужно искать кофаундера-старшего-программиста-станет-впоследствии-CTO, с долей вполть до равной с текущими сооснователями. Так как перемалывать здоровье нужно с каким-то понятным резоном, а не потому что "крутая технология" и "перспективный продукт".
Со своей колокольни кажется, что позиция СТО возможна только во время роста компании. Брать со стороны такого человека - очень большая редкость. Примерно как с лидами команд. Эти должности подразумевают управление ресурсами и хорошую ориентацию в текущем ландшафте, а человек со стороны будет вьезжать достаточно долго.
Поэтому и откат после увольнения куда то в районе ведущего инженера/менеджера. Да и стремиться на такую должность - надо очень хорошо представлять будущее компании, которая это предлагает.
2022. Год из жизни CTO в GameDev