Отказ от проекта не делает разработчика «хорошим».

Я изо всех сил пытался найти способ объяснить это, которое не выглядело бы как семантическая щепетильность, снисходительность или потенциально догматизм. Это было на удивление сложно. Казалось бы, очевидно, что профессионалы должны иметь профессиональные стандарты, что разработка программного обеспечения и веб-приложений — это нечто большее, чем просто «выполнение» или «завершение работы».

Я считаю, что у меня наконец есть хорошая аналогия.

Три повара

Представьте, что вы состоявшийся ресторатор, который собирается нанять нового шеф-повара. Вы сужаете большой круг кандидатов до трех поваров. Вам нравятся все трое по разным причинам, и поэтому вы решаете позволить каждому из них временно попробовать свою работу.

Первый — отличный повар. Он может быстро и эффективно следовать вашим существующим рецептам, а также изобрел некоторые из своих собственных, которые действительно вас впечатлили, однако есть одна маленькая проблема. У него есть некоторые вредные привычки на кухне, и он, как правило, не так тщательно следит за чистотой своего помещения и следит за тем, чтобы он не использовал посуду повторно таким образом, чтобы это могло вызвать перекрестное загрязнение. Но вы уверены, что если бы вы наняли его, вы могли бы легко научить его улучшать свои привычки, чтобы они соответствовали стандартам вашего существующего кухонного персонала.

Второй повар отлично умеет быстро и качественно выполнять ваши существующие рецепты, но его собственные рецепты вас особо не впечатлили. Однако он быстр, очень опытен и отлично поддерживает чистоту на своей территории и тщательно избегает перекрестного загрязнения. Вам нужен шеф-повар, который в конечном итоге сможет расширить ваше меню, и вы еще не уверены, сможет ли этот шеф-повар это сделать, но вы знаете, что он станет отличным дополнением к вашему существующему кухонному персоналу.

Шеф-повар номер три неплохо готовит, но не любит следовать вашим рецептам. Ему не нравится, когда другие люди в вашей команде говорят, как что-то делать, и поэтому он часто пренебрегает важными шагами в некоторых ваших существующих процессах. Кроме того, основные практики, которым следуют остальные сотрудники, он в основном игнорирует. Он действительно готовит достаточно хорошую еду, однако свои средние кулинарные навыки он компенсирует украшениями, которых не требовали рецепты и которые не просили клиенты.

Например, он добавляет лишний соус к блюду, которое в нем не нуждалось. Он может добавить три вида гарнира к рецепту, который требовал одного, и он постоянно заново изобретает существующие рецепты, если не игнорирует их полностью. Он тебе нравился, потому что он очень много работал. Он приходил рано и уходил поздно, а также казался очень изобретательным и стремился угодить клиентам.

Однако, в дополнение к его неспособности хорошо работать с другими и его плохим навыкам следования рецептам, он просто не понимает основ поддержания чистоты и порядка на вашей кухне. Правилами безопасности при приготовлении пищи также часто пренебрегают, а остальные сотрудники постоянно наблюдают за ним, чтобы попытаться выявить потенциальные проблемы с безопасностью, такие как недоваренная еда, прежде чем она попадет на тарелку клиента.

Все трое из этих поваров могут «справиться с работой». Если вы попросите их приготовить стейк, все они приготовят приличный стейк. Все они умеют неплохо готовить и усердно работают, чтобы угодить клиентам.

Я уверен, что если бы настоящий повар прочитал это, он бы рвал на себе волосы, пытаясь сказать мне, что повара с плохим обращением с едой и гигиеной на кухне на самом деле не «справляются со своей работой». Но так оно и есть в разработке. У нас нет очень реального и непосредственного риска заболеть клиента, поэтому плохая гигиена кода и плохие практики кода могут иногда оставаться незамеченными и непроверенными способами, которые просто не сработали бы на профессиональной кухне.

Итак, если вы ресторатор, кого вы нанимаете? Я бы избавился от шеф-повара три сразу. Нанять его было бы огромным риском с очень небольшим потенциальным вознаграждением.

Два других могут быть немного сложнее. Первый представляет большой риск, если вы не можете заставить его быстро отказаться от своих вредных привычек, но его мастерство и креативность делают его отличным выбором для расширения вашего меню.

Шеф-повар номер два, с другой стороны, обладает именно теми профессиональными навыками, которые вы ищете, но в настоящий момент, кажется, не так хорош в создании своих собственных рецептов. Тем не менее, ему может быть всего несколько лет и немного тренировок, чтобы стать великим в этом, и он не представляет масштаб риска первого шеф-повара.

Предположим, например, что через две недели после того, как вы наняли первого повара, вы обнаружили, что он все еще использует плохие методы на кухне, уволите ли вы его? Как долго вы будете терпеть потенциальный риск для вашей пищевой безопасности?

Второй повар, вероятно, является вашим лучшим бизнес-решением.

Три разработчика

Так как же эта аналогия применима к программному обеспечению и веб-разработке?

Первый повар представляет суперзвездных разработчиков с отвратительной гигиеной кода. Разработчики, которые всегда совершают удивительные подвиги, но с кодом, который невозможно понять или использовать повторно. Они могут быстро делать отличные вещи, они могут предлагать новые изобретательные функции, но вам нужен кто-то, кто будет тщательно и регулярно проверять их код, или вы спрашиваете о серьезных проблемах в будущем.

Шеф-повар два представляет тех разработчиков, которые заботятся о качестве и профессионализме, которые пишут только хороший код, но могут быть слишком заняты, чтобы изобретать или предлагать следующую большую удивительную функцию. Они не только реализуют свои проекты, но и пишут код, пригодный для повторного использования, тестируемый и понятный.

Шеф-повар 3 — это ваши супер-специальные разработчики, которые думают, что их способ разработки так же хорош или лучше, чем у кого-либо еще. Они также считают, что добавление дополнительных функций всегда является хорошей идеей и всегда делает продукт лучше. Они верят, что они особенные в мире разработки, и что все, что они делают, должно быть сделано в индивидуальном порядке, потому что только они достаточно особенные, чтобы понять, как делать что-то по-своему.

Они компенсируют свое постоянное отступление от лучших практик и ваш зарекомендовавший себя продукт, добавляя всевозможные дополнительные маленькие функции и настройки, о необходимости которых вы даже не подозревали. Но эти разработчики - вечная проблема. Их проекты всегда выходят за рамки бюджета, перепроектированы, ими трудно управлять, и они постоянно изобретают велосипед.

Кроме того, их импульсивные изменения продукта часто приводят к дополнительным ошибкам, дополнительным конфигурациям и требуют дополнительной документации. В некоторых случаях изменения продукта фактически снижают удобство использования или функциональность по сравнению с предыдущей итерацией и заставляют других разработчиков выполнять дополнительную работу по устранению неполадок в новых интерфейсах и поиску неизвестных ошибок. Гигиена кода — это не то, о чем знают или хотят знать суперспециализированные разработчики.

Каждый из этих разработчиков «осуществляет» свои проекты, но каждый представляет свой собственный вид риска. Еще раз, третья разновидность разработчиков — разработчиков суперспециального стиля — это те, кого вам следует избегать. Они создадут больше проблем, чем решат, и представляют чрезвычайный риск для стоимости вашего программного обеспечения.

Для сравнения, если вы можете заставить своих «суперзвезд»-разработчиков доводить свой код до уровня качества ваших «двойок» разработчиков «чистого кодирования», и вы можете сделать так, чтобы разработчики-двойки были такими же изобретательными, как и ваши разработчики-разработчики, тогда вы были бы на вашем пути. путь в отличную профессиональную команду. Вам нужен креатив и изобретательность, но это должно быть сбалансировано с солидным профессионализмом, потому что, в конце концов, вам все равно нужно вовремя сдать этот программный проект с повторно используемым кодом, который легко понять, протестировать и отладить.

Я был в нескольких командах, где разработчики сильно различались по своему профессионализму и навыкам, и все же часто все разработчики считались одинаковыми.

Новые и менее опытные разработчики часто так легко впечатляются тем, что «делают» другие разработчики, что фактически не могут отличить отличных разработчиков от низкопробных.

«Посмотрите на функцию, которую реализовал супер-специальный разработчик… Это здорово. Ну и что, что клиент не просил об этом и не будет его использовать? Я тоже хочу построить что-нибудь красивое…»

Та же проблема существует с менеджерами и нетехническими коллегами, которые часто не знают, как правильно оценить техническую работу.

Мы должны уметь различать опытных разработчиков, которые работают профессионально и в результате создают огромную ценность для своего бизнеса, и тех разработчиков, которые создают постоянные проблемы и относятся к своим программным проектам как к хобби на выходных.

Это настолько элементарно в других отраслях, что странно, что у нас нет четкого понимания и обсуждения стандартов в мире профессиональных программистов и разработчиков.

Я знаю, какую еду от шеф-повара я бы хотел съесть, и, честно говоря, для меня не имеет значения, насколько хорошо ты умеешь готовить. Если у вас нет чистой кухни и хороших профессиональных стандартов обращения с посудой и едой, я бы вообще не хотел есть в вашем ресторане.

Программное обеспечение затрагивает все, и мы должны быть не менее обеспокоены тем, кто пишет наш код и насколько хорошо он его пишет.