Избавьтесь от технической ржавчины, когда вы чувствуете себя занятым графиком менеджера, не затрагивая свои управленческие обязанности
Ирония того, что я инженер-программист, заключается в том, что в какой-то момент я хотел попасть в менеджмент. Однако, когда я, наконец, перешел к руководству, я стал меньше выполнять техническую «создательскую» работу, которую раньше выполнял как инженер-программист. Этот сдвиг меня обеспокоил. Как я могу с полной уверенностью признать, что являюсь менеджером по разработке программного обеспечения?
Как менеджер, ваша организация по большей части имеет другой набор ожиданий от вас по сравнению с тем, когда вы были инженером. Ваша организация ожидает, что вы будете управлять людьми и делать все понемногу. В ваши обязанности могут входить коучинг и наставничество вашей команды, управление людьми, управление проектами, планирование технической дорожной карты, постановка целей, оценка, управление заинтересованными сторонами, найм, планирование бюджета, планирование численности персонала и т. Д. Вы можете почувствовать, что ваша управленческая роль уводит вас от причина, по которой вы в первую очередь стали инженером-программистом, - чтобы писать код и создавать программы.
Много раз за свою карьеру в качестве технического менеджера я чувствовал себя неважно как технический сотрудник. Ржавчина стала для меня более очевидной, когда я начал ходить на технические собеседования. Мне жаль, что я не разобрался с этим раньше. Я преимущественно отмечал свои недели графиком менеджера и крошечным блоком графика производителя. Были длительные периоды, когда мне нужно было уделять немного больше времени управлению людьми. В эти периоды я перестал вносить свой вклад в основной код моей команды, поэтому я потенциально не блокировал прогресс команды. Таким образом, я почти не внес в команду ничего технического.
Работа инженером-менеджером - это постоянный баланс между «проектированием» и «менеджментом». Это может дать вам гибкость в принятии решения о том, на чем сосредоточить внимание в зависимости от потребностей вашей организации. Сама по себе гибкость также является его ловушкой. Если вы не будете действовать сознательно, вы в конечном итоге пренебрежете «инженерной» стороной своей роли.
Хорошая новость заключается в том, что существуют высокопроизводительные задачи, которые помогут вам оставаться технически точным, не пренебрегая своими управленческими обязанностями. Я расскажу вам об этих разных способах без определенного порядка.
Некоторый контекст
То, что я расскажу в этой статье, также применимо к:
- Инженеры любого уровня
- Первоклассные инженерные менеджеры
- Технические лидеры
Это задачи, которые вы можете разделить на более мелкие части, чтобы они могли вписаться в расписание вашего менеджера. Они не должны мешать вашей команде вносить свой вклад в ваш основной код. Мне жаль, что я намеренно заблокировал больше времени для таких задач раньше в своей карьере.
Откуда я:
- Я основывал эту статью на своем опыте работы менеджером по проектированию первого уровня. Я управлял от 4 до 6 инженеров-программистов (отдельных участников) разного уровня более трех лет.
- Компании, в которых я работал, требуют, чтобы инженерные менеджеры первого уровня в определенной степени вносили технический вклад в команду. Однако приоритетом этой роли по-прежнему остается управление людьми и лидерство.
- Роль «технического менеджера» не одинакова для каждой компании. Некоторые компании требуют, чтобы их инженерные менеджеры управляли группой или командой менеджеров.
1. Технические интервью
Как менеджер, ваша роль требует, чтобы вы принимали участие в найме своей команды, от планирования численности персонала до проведения собеседований для принятия решений о найме. Кроме того, вы, скорее всего, уже проводите собеседование на соответствие культурным особенностям. Поскольку вы уже участвуете в этом, выделите в своем календаре время для проведения некоторых технических собеседований - будь то собеседование по кодированию или проектированию систем.
Подготовка задач к собеседованию требует исследования, а также отзывов других инженеров. Процесс подготовки позволяет вам изучить различные технические темы, которые могут включать алгоритмы и проектирование систем. Кроме того, собеседование поможет вам узнать больше о конкретной технической проблеме, которую вы представляете кандидату. Вы также узнаете от кандидатов различные способы решения проблем. Продолжайте повторять технические вопросы, которые вы задаете, чтобы они оставались актуальными. Представьте себе преимущества непрерывного цикла обучения и поиска лучших кандидатов.
2. Обзоры инженерного проектирования
Проектные документы служат планом услуг, которыми владеет ваша команда. Они содержат подробные технические характеристики ваших услуг. Ваша помощь в подготовке и проверке этих проектных документов будет ценна для вашей команды. Вы предоставляете команде «взгляд со стороны» на систему. У вас будет уникальный ввод, потому что вы не так привязаны к задействованным сервисам, как ваша команда.
Содействовать общему процессу обзора дизайна. Примите участие в мозговом штурме по дизайну. Погрузитесь в подробности, чтобы лучше понять архитектуру программного обеспечения, компоненты, из которых состоят службы вашей команды, и то, как они взаимодействуют друг с другом. Выявите возможные улучшения в конструкции ваших систем и обсудите их со своей командой. Если вы уже работали над подобным сервисом раньше, поделитесь своими ошибками, чтобы ваша команда их избегала.
Дайте понять своей команде, что вы здесь не для того, чтобы подписать проект. Здесь вы являетесь соавтором и фасилитатором. У вас нет намерения блокировать дизайнерские решения, которые должна принять ваша команда.
3. Ведение журнала, отчеты и аналитика
Принятие решений на основе данных включает в себя сбор данных, извлечение общих тем и закономерностей из ваших данных, а затем принятие мер на основе извлеченных результатов (при условии, что ваш сбор данных находится в нужном месте). Ваша команда не будет полагаться на интуицию. Они будут принимать более обоснованные решения, используя собранные фактические данные.
Для сбора данных необходимо правильно настроить ведение журнала в ваших сервисах. Обеспечение того, чтобы эти регистраторы были в нужном месте, является важным шагом. Вы можете помочь своей команде, просмотрев базу кода и определив, где эти журналы должны быть записаны или отсутствуют. Убедитесь, что ведение журнала правильно реализовано во всей базе кода. Если ваша команда ничего не отслеживает и не регистрирует, это ваш шанс возглавить эту инициативу.
Ведение журнала также просто реализовать. Если у вас уже есть оболочка или SDK, который вызывает службу ведения журнала, вам нужно только выяснить, где вызывать вызовы регистрации. Когда вы сами пишете эти вызовы журнала, вы знакомитесь с кодовой базой своей команды, обеспечивая при этом надлежащий сбор данных.
Эти журналы хранятся в хранилище данных для запроса к ним в конце конвейера (например, Databricks или Redshift). Напишите запросы SQL (или скрипт Python) для значимого извлечения данных. Используйте извлеченные данные, чтобы помочь вашей команде принимать решения на основе данных (например, стоит ли рассматривать новую функцию или успешен ли эксперимент).
4. Незначительные исправления с обновлениями документации
Документация обычно отстает от кода, который мы пишем. Обновляются библиотеки и добавляется код. Однако документ остается неизменным. Я всегда испытываю это, когда присоединяюсь к новой команде или принимаю участие в новом проекте. Я бы следил за шагом в файле README, который не работает. Оказалось, что инструкция устарела.
Помогите своей команде обеспечить синхронизацию вашего кода и README.md. Начните с выбора «небольшого» тикета, который является либо ошибкой, либо рутиной из вашего невыполненного задания. Чтобы закрыть этот тикет, вам нужно будет настроить один из репозиториев вашей команды для локального запуска. Если у вас нет времени работать над заявкой, сразу переходите к локальному запуску репо. Представьте, что вы новый инженер, присоединяющийся к команде, выясняющий, как запускать свои сервисы локально. Чаще всего (особенно для неактивных репозиториев кода) вы сталкиваетесь с недокументированными «подводными камнями». Задокументируйте эти ошибки и внесите необходимые изменения, пока вы не будете удовлетворены README.
Поднимите запрос на перенос вашего «обновления документа» или патча. Продолжайте проделывать это с репозиториями под присмотром вашей команды.
5. Инструменты мониторинга и оповещения
Ваша команда будет нести ответственность за круглосуточную работу ваших служб, в зависимости от вашей организации. Службы вашей команды должны поддерживать высокий стандарт наблюдаемости. Я руководил командами, в которых мы отвечали за круглосуточную доступность наших услуг. Инструменты мониторинга и оповещения могут повлиять на:
- Жизнь вашей команды вне работы
- Ваши сервисные и бизнес-показатели
Должны быть панели мониторинга, содержащие достаточно информации, которая поможет вам следить за состоянием вашего сервиса. Критерии оповещения должны быть настроены так, чтобы ваш дежурный по вызову предупреждался, если образец отказа соответствует пороговому значению (например, обратитесь к дежурному инженеру, если ошибки 5xx достигли x%).
Регулярно оценивайте наблюдаемость ваших услуг. Ознакомьтесь с инструментами наблюдения, которые использует ваша команда. Помогите создать информационные панели Grafana, которые ваша команда сможет использовать для отслеживания количества ошибок в вашем сервисе. Помогите своей команде установить правильные критерии оповещения с помощью Bosun. Управляйте круглосуточной сменой вызовов и политиками эскалации вызовов, используя такие сервисы, как VictorOps и PagerDuty.
Пробелы в вашем мониторинге и предупреждении неизбежны. Услуги будут развиваться и масштабироваться. Следовательно, ваши инструменты наблюдения должны быть адаптированы. Осведомленность о ваших услугах помогает вашей команде эффективно контролировать ваши услуги в режиме 24/7.
6. Создание прототипов клиентов API
Зависимости внешних сервисов неизбежны в мире микросервисов. Служба вашей команды будет потреблять услуги другой команды. Применимы зависимости - особенно для веб-приложений или мобильных приложений.
Я бы посмотрел на нашу дорожную карту продукта или задачи для предстоящих спринтов и определил, какие функции будут зависеть от сервисов. Затем я следую документации API (если она есть). Иногда, если мне повезет, могут быть включены тестовые ремни. Моя цель - сделать потребление API максимально понятным. Затем я бы создал прототип клиента API, если будет много неизвестных.
Мой любимый инструмент для этого - iPython Notebook. Использую с Библиотекой запросов. Синтаксис Python также похож на псевдокод, поэтому создание прототипов похоже на ведение заметок. iPython Notebook также позволяет писать заметки и блоки кода, что делает его полезным инструментом для создания прототипов. Когда ваши прототипы блоков кода с примечаниями будут готовы, поделитесь ими со своей командой. Они могут использовать эти заметки в качестве справочника в своей задаче, которая требует от них использования API.
Вы пишете здесь некоторый клиентский код, в то же время позволяя своей команде, предоставляя им фору в том, как они могут написать клиента для зависимости службы.
7. Проекты выходного дня с открытым исходным кодом
Написание проектов с открытым исходным кодом - очевидное дело, если вы серьезно относитесь к оттачиванию своего мастерства в качестве инженера-программиста. Если вы не один из тех удачливых разработчиков, у которых есть проект с открытым исходным кодом, поддерживаемый вашей компанией, создание программного обеспечения с открытым исходным кодом (OSS) требует времени, выходящего за рамки вашей постоянной работы.
В идеале ваш проект OSS на выходных дополняет то, что вы делаете на работе. Например, если ваша команда использует TypeScript, имеет смысл написать OSS на TypeScript, чтобы узнать больше о языке. Было бы даже лучше, если бы ваш OSS был чем-то, что могла бы использовать ваша команда (конечно, без раскрытия какой-либо интеллектуальной собственности).
Например, я создал библиотеку Python под названием APIWrapper для одной из моих предыдущих компаний. Это простая библиотека, написанная на Python, с универсальной функциональностью, повторно используемой в любом приложении Python, без раскрытия какой-либо интеллектуальной собственности.
Если все сделано правильно, преимущества этой задачи огромны и даже усугубляются в долгосрочной перспективе:
- Вы повышаете уровень языка / языков программирования или технологий, которые могут помочь повысить уровень вашей команды.
- Ваш OSS потенциально может быть полезен вашей команде.
- Ваш OSS потенциально может помочь сообществу, которому может понадобиться такое же программное обеспечение.
Обратите внимание, как я использую слово «потенциально». Написание открытого исходного кода - самая простая часть. Создание чего-то полезного для других разработчиков - сложная часть.
8. Хакатоны.
Выделите время для хакатонов со своей командой. Мне повезло, что у предыдущего работодателя один рабочий день отводился на хакатон каждые шесть месяцев.
Заранее спланируйте, чего вы хотите достичь на хакатоне со своей командой. Не планируйте во время хакатона. Я уже совершал эту ошибку раньше, и она отнимала четверть времени, которое нам следовало бы потратить на написание кода. Три основных критерия того, над чем работать, будут:
- Что принесет наибольшую пользу?
- Чего можно достичь за день?
- Что будет держать команду в восторге?
Менеджеры первого уровня или лидеры должны использовать хакатоны для написания кода без каких-либо других перерывов. Вместе со своей командой вы создаете потенциально полезную функцию или инструмент. Написание кода на целый день - роскошь, если вы менеджер или руководитель.
9. Обзор кода
Проверка кода - еще один продуктивный способ быть в курсе последних событий в репозитории вашей команды. Проверка кода не о том, кто самый старший, лучший или самый опытный «обезьяна кода рок-звезды». Опыт действительно помогает. Однако проверка кода - это поддержка друг друга, чтобы мы не попадали в плохие практики, ведущие к нежелательным краткосрочным и долгосрочным результатам.
Используйте свое «время создателя» или выделите время в своем календаре для проверки кода. Сообщите своей команде, что вы собираетесь это сделать. Назначьте себе пул-реквесты, которые, как вы уверены, вы сможете адекватно рассмотреть и уложить в отведенное время.
Подавайте хороший пример с точки зрения лучших практик программирования. Как и при проверке дизайна, используйте свой опыт, чтобы помочь своей команде избежать тех же ошибок, которые вы совершали в прошлом. Покажите своей команде, как выглядит полезный комментарий при проверке кода (например, четкие и конструктивные комментарии), и отметьте, является ли он nit.
Делая это, вы помогаете своей команде поддерживать определенные стандарты кодирования, сохраняя при этом как можно более точные навыки кодирования.
10. Внутренние инструменты
Создавайте или адаптируйте внутренние инструменты, которые могут повысить продуктивность вашей команды.
Например, есть повторяющиеся ручные задачи, которые служба поддержки просит вашу команду выполнить. Эти ручные задачи отнимают у ваших инженеров немало времени. Кроме того, у вашей команды недостаточно возможностей для создания инструмента для автоматизации задачи. Помогите своей команде создать внутренний инструмент для решения этой проблемы, если в вашем календаре есть свободные блоки времени.
Бывают случаи, когда вам не нужно создавать свои внутренние инструменты с нуля, если есть бесплатные инструменты с открытым исходным кодом, которые вы можете использовать повторно. Некоторые примеры - инструменты повышения производительности труда разработчиков (анализ кода, рутинная проверка кода и автоматические сквозные тесты.
Поскольку это внутренние инструменты и их приоритет ниже, чем у других сервисов, которыми вы владеете, здесь у вас есть небольшая свобода действий. Сосредоточьтесь на том, чтобы инструмент заработал на первых нескольких итерациях. Поделитесь прототипом со своим внутренним клиентом, чтобы узнать его мнение. Если все в порядке, доработайте инструмент в несколько итераций после получения отзывов от вашей команды.
Вы помогаете повысить продуктивность своей команды, автоматизируя ручные задачи, которые они выполняют при написании кода. Попутно вы также можете изучать что-то новое (например, новый веб-фреймворк или библиотеку).
Заключение
По-прежнему важно в определенной степени оставаться техническим. Вам необязательно выполнять все перечисленные выше задачи. Ваш пробег может отличаться. Выбери и выбери то, что подходит твоей текущей ситуации. Например, если вы новый менеджер, вы можете выбрать два или три пункта выше. С другой стороны, если вы опытный инженер и менеджер, пять или более пунктов из списка подойдут.
Примеры, которые я привел, по-разному влияют на то, как вы инженер и менеджер. Вам решать, какие из них вы ставите в приоритет. Все дело в исполнении. Поместите их в свой календарь, сделайте их и продолжайте повторять.
Следите за пунктами №3, №5 и №6, потому что они могут быть кандидатами на автоматизацию. Часть пункта №9 уже автоматизирована, например, с Опасностью.
Посмотрите мою другую статью:
