Почему я до сих пор программирую как инженер-менеджер?
Быть активным программистом на моей текущей должности не требуется, но я все же планирую свою работу тратить не менее 20% времени на чтение/написание кода или поддержку инфраструктуры. Почему? Мои причины собраны ниже.
Я не утверждаю, что программирование является обязательным при работе менеджером или руководителем группы. Я знаю людей, занимающих аналогичную позицию и не практикующих все это, но все же отлично выполняющих свою работу. Я рассматриваю его как дополнительный инструмент, помогающий в таких вопросах, как планирование, понимание болевых точек команды или даже линейное управление.
Программирование позволяет вам быть ближе к проблемам или неудобствам команды. Наличие солидного опыта разработки программного обеспечения поможет вам найти слабые места или места, которые стоит улучшить, зная, что на горизонте в отношении предстоящих задач. Таким образом, работу можно лучше спланировать, например. избегайте неожиданного рефакторинга при реализации новой функции, критичной ко времени. Вы также будете сталкиваться с проблемами, с которыми ежедневно борются другие, такими как проблемы, связанные с инфраструктурой или техническим долгом, поэтому вам будет намного легче понять необходимость исправления или улучшения.
Я видел пару раз в своей карьере менеджера, продвигающего изменения с помощью рецепта, чтобы реализовать их наивным способом, поскольку последствия не влияют напрямую на его (или ее) повседневные задачи. Это снижает моральный дух, делает инженеров менее увлеченными тем, что и как строить, приводит к техническому долгу и отделяет менеджера от его команды. Дизайн и реализация должны быть предложены либо разработчиками, либо обсуждены вместе, чтобы выбрать правильное решение, тщательно взвесив компромиссы. Это лучше масштабируется — инженеры будут более автономны и будут заботиться обо всем стеке. Если все будет управляться централизованно, то реализация будет зависеть от человека, который будет кодировать либо время от времени, либо вообще не будет — вероятно, здесь не будет счастливого конца. Будучи активным программистом на ежедневной основе (это не обязательно каждый день, но мне удается делать это почти каждую неделю), вы сделаете себя неотъемлемой частью группы. Это освободит отношение командного игрока. Будут избегать таких вещей, как диктовать точный дизайн или реализацию задач — это убийца мотивации, который мешает другим расширять свои навыки и показывает отсутствие доверия.
Делайте то, что правильно, а не то, что легко.
Работа только частично с кодом имеет очень приятное преимущество — вы точно знаете (или, по крайней мере, более или менее), как все работает, но вы не настолько эмоционально привязаны к этому. Гораздо проще, чем принимать трудные решения, которые команда иначе считала бы невозможными. Взгляд в более широкой перспективе помогает обнаружить проблемы, о которых команда еще не знает (коллеги могут быть настолько поглощены работой над предстоящим релизом, что некоторые очевидные ошибки даже не замечаются).
Бывают случаи, когда даже небольшая помощь стоит золота. Это похоже на игрока, которого выводят на поле на последние пару минут во время игры и он забивает победный гол (или очко, или что-то в этом роде). Поэтому, когда сроки поджимают, наличие менеджера, владеющего кодовой базой, может быть ценным, особенно если трудно получить быструю помощь где-то еще.
Многие менеджеры имеют солидный технический опыт, поскольку раньше они были инженерами-программистами, devOps и т. д. Использование такого опыта и мудрости на ежедневной основе сделает команду более эффективной. Это также дает прекрасную возможность менее опытным коллегам узнать что-то новое и найти другие альтернативы для решения проблем — чем больше умных мозгов разгадает загадку, тем лучше.
Забота о мотивации, обучении и развитии членов команды требует многих действий. Участие в регулярных задачах, таких как проверка кода, — лишь одна из них в моем случае. Умение читать код коллег дает возможность увидеть слабые места или способности каждого, которые стоит развивать или продвигать — не так много других столь ценных способов оценить чьи-то навыки, как отношение к повседневным задачам.
Играя с кодом и наблюдая за изменениями в репозитории, можно сэкономить время, затрачиваемое на так называемые собрания по обновлению статуса. Вместо того, чтобы спрашивать о деталях или текущем прогрессе, можно просто украдкой просмотреть ветку задачи, запрос на извлечение или исходный код, чтобы получить ответ. Это не отменяет необходимости сидеть вместе и просто разговаривать, но если определенную информацию можно извлечь с помощью другого метода, почему бы не использовать ее? Я стараюсь избегать встреч, на которых все объясняют все последние задачи или исправления ошибок (по-прежнему необходимо время от времени, например, чтобы стимулировать поток информации внутри команды). Гораздо лучше работают менее формальные разговоры, когда каждый может поделиться самым интересным, над чем работал в последнее время — не всем, а чем-то полезным для других в виде презентации или мастер-класса.
Определенно непросто систематически распределять время на работу непосредственно с кодом и всеми нюансами под капотом. В любом случае, я все еще вижу много преимуществ, которые стоит попробовать. Это не всегда должна быть экстраординарная задача, сложная пропорционально годам, проведенным в ИТ. Важно выбрать что-то делимое для работы между другими обязанностями или просто сосредоточиться на более мелких вещах, чтобы не отвлекаться слишком часто.
