Правило программиста #1: оставьте эмоции дома!

Как программисты, мы гордимся нашей работой. Мы показываем эту гордость, выполняя наши задачи лучшим образом. Мы относимся к ним со всей дотошностью, вплоть да названий переменных и методов. Мы всегда выбираем нужные классы для конкретной задачи, не смотря на то, что пользователю все равно, использовали ли мы List<KeyValuePair<Guid, string>> или Dictionary<Guid, string>. Мы нервно стараемся довести все до идеального состояния. Многие даже могут подумать, что у нас ОКР.

Но что происходит, когда разработчик слишком гордится тем, что он или она написали?

Что, если из-за этого эмоции проникают в код? Что может случиться, если программист не может расстаться не только с его или ее кодом, но и с методами ведения работы, принятия решений и своим поведением, как разработчика?

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

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

Но, когда мы набирались опыта, когда в нас появилась жажда узнать больше о тех технологиях, которые мы использовали, мы начинали отделять себя от своей работы. Многие учились находить лучший способ решения задачи, чем тот, который они реализовали. Многие из нас даже увлеклись этим. Чем больше мы узнавали о конкретной технологии, тем больше мы узнавали вещей, действительно упростивших нашу жизнь, и нам это нравилось. К сожалению, не все программисты встали на этот путь. Некоторые разработчики остались на шаге “неприятия критики”.

Что вызывает это поведение? Я считаю, что это не озлобленность, не инфантильность, не возвышение себя над другими. Мое мнение – это происходит из-за неуверенности в себе. Когда я был еще зеленым, я всегда считал, что любое изменение моего кода или выбор другого пути решения проблемы означает, что я – дурак. Я думаю, разработчики, которые защищают свой код до последнего, в тайне боятся, что их значимость в глазах других понизится, когда код, написанный ими, обвинят в неоптимальности. Независимо от причины.

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

А что, если это не сработало? Ну, у вас не такие приятные способы решения. Если тот программист не сдастся, то лучший способ – заручиться поддержкой остальной команды. Если он не тим-лид и не менеджер, то его плохой код (и отношение к работе) не устоят перед всей остальной командой.

Следующий шаг – предлагать улучшения напрямую менеджеру или тим-лиду. К сожалению, к вам может прийти чувство того, что вы ”нанесли удар в спину” остальной команде, поэтому вам стоит прихватить с собой другого компетентного разработчика, который мог бы подтвердить, что ваш способ действительно лучше, либо скорректировать его вместе с вами. Предложите ваше решение менеджеру, позвольте другим разработчикам отстоять свои позиции и пусть менеджер вынесет решение. Теперь все в его руках и вы не можете повлиять на его решение. Если он выберет другой путь, то вы, по крайней мере, попытались.

Как разработчикам, нам стоит быть менее эмоционально-привязанными к нашему коду. Вспомните это, когда снова задумаете спор против этого определенно лучшего решения, чем ваше.