Этот вопрос задают мне поголовно все работодатели. С первого взгляда ответ кажется очевидным, но… Всегда есть это “но”. Если рассматривать вопрос в лоб, то очевидно: предлагать “покодить” человеку, который более 15 лет работает менеджером, практически с нуля поставил ряд технологических и бизнес-процессов в UMI.CMS, неоднократно формировал успешные команды веб-разработчиков, но никогда в жизни официально не работал программистом, – по меньшей мере странно.
С одной стороны, это лестно. Это означает, что в индустрии действительно становится всё меньше толковых людей, и любой адекватный технически компетентный чувак представляет живой интерес. А вот то самое маленькое “но” на практике означает, что заказчик озвучивает свои глубинные хотелки не совсем правильными словами.
Предположим, что мы не рассматриваем недобросовестных работодателей, которые под соусом “руководителя отдела” хотят нанять человека, который руками напишет им больше половины всего кода. Обсудим добросовестных и честных.
Безусловно, я умею программировать. Я считаю, что технических менеджеров, не умеющих это делать, стоило бы вешать на заборе у входа в ваш офис. Равно как я умею и проектировать структуры баз данных, администрировать линукс, настраивать кластеры, ковырять код дебаггерами, подвергать фронтенд и бэкэнд нагрузочному тестированию (и применять результаты), верстать html/css, управляться с яваскриптом (хоть в браузере, хоть в nodejs), писать рецепты деплойки и миграций БД, настраивать триггеры в заббиксе и делать ещё миллион других штук, о которых некоторые программисты даже не задумываются.
Но я никогда не стремился делать это основной компетенцией своей профессиональной жизни.
Я способен поддерживать часовую беседу о тонкостях разработки веб-сайтов и сервисов, начиная от словоблудия вокруг абстрактных классов и интерфейсов, и заканчивая побуквенным разбором аббревиатуры SOLID и недостатками практической реализации EAV-модели. Я могу вымотать на собеседовании любого разработчика, претендующего на позицию senior, так что он на выходе будет трясти мне руку и благодарить за множество новых знаний, которые он от меня получил в ходе собеседования. Я регулярно тыкаю носом (вежливо, разумеется) своих сотрудников в их код, на конкретных примерах указывая, что их решение – неоптимально, хавает слишком много вычислительных ресурсов, ляжет под нагрузкой, сожрёт память, будет легко доступно “на пробитие” по безопасности, создаст трудности при масштабировании, или просто будет чересчур дорого в дальнейшей поддержке.
Я участвую в каждом мало-мальски серьёзном куске проекта – как идеолог, проектировщик, строгий цензор, одновременно критик, тестировщик и первый же благодарный пользователь. Буквально, садясь за один стол с ведущим разработчиком, изрисовывая десятки листов A4 схемами и алгоритмами – до тех пор, пока решение не покажется мне стабильным, красивым, надёжным, и выгодным в долгосрочной перспективе. Как правило, я и документирую сложные места проекта, потому что зачастую только я в команде имею реальное представление “как оно всё вместе работает”.
Нередко бывает и так, что я могу проснуться в три часа ночи, чтобы быстро закодить решение какой-либо сложной проблемы из проекта – быстрый рабочий прототип. С которым утром приходишь в команду, чтобы они смогли погонять его на стендах и внедрить решение в проект правильным и надёжным программным кодом.
Я проектирую и поддерживаю всю инфраструктуру и технологические процессы в проекте. Каждый шаг, начиная от регулярной сборки, прогона тестов и анализаторов, включая процессы деплоя и миграции, управление конфигурацией серверов, настройки мониторинга и внутренних показателей стабильности – определяется мной. Я слежу изнутри за всем тем, чтобы вся эта система работала безотказно, а заказчик снаружи видел только регулярные выпуски новых версий.
Но мне никогда не придёт в голову меряться пиписьками с тем, кто профессионально работает веб-программистом уже много-много лет. Я и он – профессионалы в разных, хоть и очень близких и пересекающихся областях. И у профессионального программиста есть одно отличие и особенность: он профессионально знает свои инструменты.
Сегодня профессиональный программист должен виртуозно владеть своими инструментами, знать их особенности и достоинства, следить за изменениями профессиональной среды. Как парикмахер, разбирающийся в двух десятках видов ножниц, – программист досконально знает свой любимый Bitrix, или свою любимую Symfony, или свой драгоценный Ruby on Rails. Также, как профессиональный сисадмин может администрировать свои серваки хоть левой пяткой через мобильный телефон, а профессиональный дизайнер будет порхать пальцами над макетом в сто пятьдесят слоёв в фотошопе.
Сегодня вы уже практически не встретите абстрактного “программиста на PHP” среди senior-ов. Это будет либо “программист Bitrix”, либо “программист UMI”, либо разработчик на Symfony, либо специалист по Ruby on Rails или Django. Именно это разделение труда, когда существуют руководители (инженеры-конструкторы, если хотите), разработчики на конкретных платформах, тестировщики, администраторы – и возвело программирование из статуса деревенского ремесла – в современный индустриально-промышленный труд.
Мне возражают, что технический руководитель, “не участвующий” в реальной работе с кодом, со временем теряет понимание и отрывается как от используемого инструментария, так и от реального внутреннего состояния подотчётной системы. Техдиректор должен быть авторитетом своей команды, и быть в курсе всего.
Но дьявол, как всегда, кроется в деталях. Авторитет в среде разработчиков можно заработать не только ручным написанием кода. Его можно приобрести лёгким наброском изящного алгоритма на маркерной доске. Можно – здоровой критикой чьего-то решения, и предложением альтернативы. Можно – ежедневными рассказами из жизненного опыта о решении таких проблем, которые другим сотрудникам даже не снились. Можно – просто будучи адекватным человеком, не мудаком, всегда делясь опытом и знаниями с людьми, с которыми работаешь.
И не получается отрыва от системы, когда ежедневно пялишься в код. Когда на пару с разработчиком до десяти часов вечера сидишь в консоли продакшен сервера, потому что только там проявляется бл**ская ошибка, и выхватываешь друг у друга клавиатуру, чтобы под внимательным наблюдением коллеги попробовать 100500-ое по счёту решение. Когда ежедневно делаешь хотя бы выборочное код-ревью. Когда исправляешь аварийные косяки какого-нибудь питонячьего скрипта, автор которого уже едет домой на метро или откупоривает третью бутылку в баре, и заведомо недоступен по мобильнику. Не получается оторваться от системы, даже если бы ты и хотел.
Я не ставлю себе главной целью совершенствоваться в знании инструментов. Я совершенствуюсь в успешном решении технологических задач, которое достигается командой. Потому что именно это, в конечном итоге, является целью, которую передо мной ставят заказчики.
Существует небольшая, но значительная разница в терминологии: техлид и техдиректор (технический лидер и технический директор). Почему вы ошибаетесь, если хотите нанять техлида вместо техдиректора? Потому что первый – разработчик, а второй – менеджер. Техлид может (и должен) быть высококлассным специалистом, тянуть вперёд большую часть проекта, но вы столкнётесь с равнодушием и отсутствием взаимопонимания, когда захотите донести до него бизнес-ценности. Например, то что сделать релиз в срок – иногда бывает важнее, чем “запилить крутую фичу”. Продать немного сырой продукт важному клиенту – иногда бывает важнее, чем довести его до совершенства. Наладить продуктивное взаимодействие между всеми отделами компании – всегда важнее, чем внедрить QA и автоматизированное тестирование.
Восприятие программного продукта как бизнеса – это то, что отличает руководителя разработки от ведущего разработчика. Теперь вы знаете всё, и сможете сделать правильный выбор.
Возвращаясь к тому, что заказчик озвучивает свои внутренние желания не совсем правильными словами, поясню: заказчику просто нужно, чтобы программисты не сделали какую-нибудь *уйню. Сделали бы качественный, хороший продукт – в разумные сроки. А руководитель не хлопал бы ушами, а реально прикладывал бы свой мозг и весь свой опыт – к каждому значимому месту в продукте. Надо просто называть вещи своими именами.
Как я насчёт немного покодить?
Думаю, вы сами сможете ответить на этот вопрос.