Разработка
Инженеры-программисты не являются (и не должны являться) техниками
Я считаю тревожным сигналом, если инженер или команда попадают в предсказуемый «поток», потому что это означает, что существует перспективная возможность для автоматизации, которую они игнорируют.
На самом деле я не считаю, что предсказуемость — это хорошая вещь в программной инженерии. Возможно, для некоторых людей (особенно для менеджеров) это станет сюрпризом, но я объясню, что я имею в виду.
На мой взгляд, великий инженер-программист — это тот, кто автоматизирует повторяющийся/ручной труд. Вы думаете, что это довольно низкая планка, которую нужно преодолеть, верно? Разве автоматизация повторяющихся задач не является… как бы… основой программирования? Разве большинство инженеров-программистов не были бы великими инженерами в соответствии с моим критерием?
Нет.
Я бы сказал, что большинство крупных организаций, занимающихся разработкой программного обеспечения, поощряют антиавтоматизацию, и это в первую очередь из-за их склонности к предсказуемости, особенно к предсказуемым оценкам и предсказуемой работе. Причина этого в том, что предсказуемая работа — это работа, которую можно было бы автоматизировать, но не автоматизировали.
Пример
Я приведу конкретный пример предсказуемой работы с моей последней работы. На ранних этапах у нас был отдельный разработчик для поддержки нашего веб-интерфейса. Каждый раз, когда другая команда добавляла новую конечную точку gRPC API к внутреннему сервису, этот разработчик получал задание предоставить ту же информацию через HTTP API. Это была довольно рутинная работа, но она все равно требовала времени и размышлений с его стороны.
Изначально менеджерам нравилось, что разработчик мог оценивать надежно (потому что работа была хорошо понятна), а разработчику нравилось, что ему не нужно было выходить из своей зоны комфорта. Но для бизнеса это было не очень хорошо! Этот человек часто становился узким местом при выпуске новых функций, потому что он вводил свой собственный ручной труд как необходимый этап в конвейер разработки. Они доказывали, что руководству следует нанять больше таких разработчиков, как они, чтобы справиться с растущим спросом на их работу.
Наша команда не согласилась с этим, поскольку мы признали, что работа этих разработчиков настолько предсказуема, что ее можно полностью автоматизировать. Мы довели до руководства, что вместо того, чтобы нанимать другого человека для выполнения той же работы, нам следует автоматизировать больше, и хорошо, что мы это сделали. Тот разработчик вскоре ушел из компании, и вместо того, чтобы нанимать его на замену, мы автоматизировали его работу. Мы написали код для автоматической генерации HTTP API из соответствующего gRPC API , и это принесло бизнесу гораздо больше пользы, чем наем нового разработчика.
Техники против инженеров
Мне нравится использовать термин «технарь» для описания разработчика, который (А) выполняет работу, которая хорошо понятна, и (Б) которому не нужно часто выходить из своей зоны комфорта. Очевидно, что нет четкой границы, разделяющей инженеров и техников, но в целом, чем более предсказуема и рутинна работа разработчика, тем больше он склоняется к тому, чтобы стать техником. В приведенном выше примере я рассматривал разработчика, поддерживающего веб-интерфейс API, скорее как техника, чем как инженера.
И наоборот, чем больше кто-то склоняется к роли инженера, тем более непредсказуемой становится его работа (как и оценки). Если вы постоянно автоматизируете работу, то вся предсказуемая работа постепенно иссякает, и остается только непредсказуемая. Суть работы инженера-программиста заключается в том, что он решает все более сложные и амбициозные задачи по мере того, как он все больше автоматизирует.
Я считаю, что большинство технологических компаний не должны склоняться к предсказуемости и избегать найма/выращивания технических специалистов. Причина, по которой технологические компании получают завышенные оценки в стоимости, кроется в автоматизации. Стремление к предсказуемости и четкому пониманию работы непреднамеренно стимулирует ручной труд, а не автоматизацию. Для многих технологических компаний это не очевидно, потому что они предполагают, что любая работа, связанная с программированием, обязательно автоматизирована, но это не всегда так (…и обычно так и бывает, лично я очень цинично отношусь к инженерной эффективности большинства технологических компаний). Технологические компании, которые не осознают этого, в конечном итоге набирают слишком много сотрудников и удивляются, почему большее количество людей выполняет меньше работы.
Или, говоря иначе. Я считаю тревожным сигналом, если инженер или команда попадают в предсказуемый «поток», потому что это означает, что существует перспективная возможность для автоматизации, которую они игнорируют.
