Никто об этом не предупреждает. Junior-разработчики тонут в неопределенности (и неизвестности); senior - в знании большего, чем им вообще следует нести на себе. Наша команда более десяти лет создает Android-приложения - от стартапов до закрытых команд уровня FAANG - и мы видели, как гениальные инженеры просто "выключаются". Не потому что им стало все равно. Потому что система никогда не переставала забирать.
67% 83% senior-разработчиков испытывают усталость от принятия решений каждую неделю
3× больше переключений контекста по сравнению с junior-коллегами
41% держат в голове, что через 2 года могут захотеть уйти с позиции senior IC
Проблема не в объеме работы. А в невидимой работе
Фичи - это "кошачья мята" для senior Android-инженеров, но именно релизы их выжигают. Эти эскалации в Slack в 21:00. Архитектурные решения, которые в итоге оказываются у вас, потому что "вы лучше всех знаете кодовую базу". Коварное предположение, что именно вы будете онбордить новичка, читать 14 PR и доводить KMP к пятнице.
Невидимое равно отсутствию velocity-поинтов. У него нет тикета в спринте. Но у него есть цена.
Каждый в инженерии знает: самая опасная фаза карьеры - когда инженер уже умеет делать почти все, но стал достаточно senior, чтобы от него это начали ожидать.
Цитата Jake Wharton, участника Android-экосистемы, с конференции 2023 года
Пять конкретных причин выгорания в Android-разработке
1. Бесконечная миграция на Compose
Jetpack Compose действительно хорош. Но перенос 300k строк кода с View на Compose при одновременной разработке новых фич - это работа в две смены. Вы создаете новый UI на Compose, поддерживаете старый XML и параллельно объясняете все это junior-разработчикам. Вы не находите устойчивой опоры - как и архитектура.
2. Накопление знаний (которое вам навязывают)
Вы знаете navigation graph, DI-настройки, кастомный Gradle-плагин и backend-контракты - и становитесь единой точкой отказа. Команды не делают это специально. Просто так происходит. И это значит, что ментальная нагрузка никогда не падает до нуля - даже в отпуске.
3. Экосистема Kotlin: нужно постоянно быть в курсе
Компиляторы, которые только начинают казаться стабильными - Kotlin 2.2 выводит K2-компилятор в стабильную ветку. KMP готов к продакшену. Compose Multiplatform быстро развивается. GraphQL и gRPC становятся базовым требованием для backend-контрактов. Объем знаний, которыми должен владеть senior Android-разработчик, удваивается каждые 18 месяцев - вместе с ожиданием, что вы знаете это глубоко.
Если вы только входите в профессию или хотите систематизировать знания, стоит обратить внимание на курс по Android-разработке с нуля, чтобы выстроить фундамент без перегрузки.
// Типичный код, который от вас ожидают: ревьюить, писать, объяснять,
// И оптимизировать — часто в один и тот же день
@Composable
fun OrderSummaryScreen(
viewModel: OrderViewModel = hiltViewModel()
) {
val uiState by viewModel.uiState.collectAsStateWithLifecycle()
when (val state = uiState) {
is OrderUiState.Loading -> FullScreenLoader()
is OrderUiState.Success -> OrderContent(state.order)
is OrderUiState.Error -> ErrorBanner(state.message)
}
}
// В это же время вы еще отлаживаете утечку корутин в
// легаси MVI-слое, к которому никто не прикасался с 2021 ¯\_(ツ)_/¯
4. Налог на архитектурные решения
MVVM или MVI? Hilt или Koin? Модульный монолит или feature-модули? За каждое архитектурное решение платится цена: вы его принимаете, несете последствия и заново объясняете его каждому новому разработчику. Выбор, который раньше казался свободой, начинает ощущаться как долг.
5. Карьерный тупик
Во многих компаниях трек senior IC никуда логично не ведет. Позиции staff-инженеров редки. Менеджмент воспринимается как предательство ремесла. В итоге высококвалифицированные инженеры застревают - выполняя senior-задачи без четкого карьерного сигнала. Стагнация ускоряет выгорание.
Что действительно работает (а не "панельные советы")
Практический anti-burnout playbook
Документируйте, чтобы делегировать. Пишите ADR для каждого значимого решения. Если junior спрашивает "почему" - отправляйте туда. Это не должно объясняться устно каждый раз.
Называйте невидимую работу. Начните ее фиксировать: "ответил на 3 архитектурных вопроса, разблокировал 2 PR, переписал CI". Убедитесь, что менеджер это видит.
Ограничьте очередь ревью. Установите потолок - например, 4 слитых PR в день. Все, что сверх - разрушает глубокую работу. Проговорите это явно.
Учитесь публично. Превратите налог на знания в карьерный капитал: пишите про Compose, Kotlin coroutines или KMP. Ведите блог, выступайте, публикуйтесь.
Присоединяйтесь к пир(такие же чуваки как вы)-группе вне работы. Это недооценено. Сравнивайте свою нагрузку с другими через Android-сообщество (AndroidDev Slack, Droidcon, KotlinConf и др.)
Разговор, который менеджеры должны начать
Если вы руководите командой с senior Android-инженерами - проанализируйте их невидимую нагрузку уже на этой неделе. Не спрашивайте, что они сделали по тикетам. Спросите, что бы они перестали делать, если бы могли. Ответы будут неудобными. Этот дискомфорт и есть сигнал.
Удержание senior Android-специалистов становится все дороже. Немного инженеров = Compose + KMP + serverless backend = требования к опыту растут. Потерю одного такого специалиста измеряют не спринтами, а кварталами - по времени онбординга, утрате знаний и влиянию на команду.
