Спойлер: разозлить разработчика очень просто. Точнее, разработчика может взбесить буквально все. И чем более “религиозны” взгляды разработчика в отношении определенных сущностей и событий, тем проще это сделать. Я считаю, что нет более токсичного сообщества, чем сообщество разработчиков, программистов и инженеров.

Даже если мы заведем разговор хотя бы о том, как правильно назвать профессию, споров и агрессии не избежать. Кем является каждый из нас? Жалким разработчиком, пишущей обезьяной, уважаемым программистом или высокомерным инженером - сколько людей, столько и мнений. Но, например, некоторые инженеры приходят в неистовое бешенство, когда кто-то то ли по незнанию, то ли специально называет их “разработчиками”.

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

if-else vs. полиморфизм

Дорогие мои, разве я подозревал, каких размеров осиное гнездо я разворошу, когда писал статью “Прекратите использовать if-else” (“Stop using if-else”). Опубликованный материал получил более 100 000 просмотров всего за несколько дней (а это по стандартам Medium, на минуточку, уже признак вирусного контента). Статья породила даже целую ветку хейтеров на Reddit. Я полагаю, что существует тайная секта поклонников плохих практик, приветствующих традиционное ветвление, в том числе с использованием инструкций if-else. Наиболее ортодоксальных представителей этой секты раздражает существование объектно-ориентированного программирования, как наиболее сложного и непонятного процесса, особенно для начинающих программистов.

Оценка задач непрофессионалами

Оценку одного из моих первых проектов проводил коллега, имеющий степень магистра, но… в сфере политических наук. Нам нужно было создать “с нуля” проект, который включал: установку окружения на трех облачных структурах, создание модели базы данных, написание бизнес-логики и саму реализацию проекта: в том числе front-end и back-end.

Так вот, подсчеты коллеги установили следующие затраты времени и ресурсов:

1. 34-36 часов,
2. 1 разработчик.

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

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

Статьи о программировании

Публичные материалы часто обращают внимание на ставшие уже традиционными моменты или делают им вызов, в том числе и в области программирования. Я часто получаю комментарии следующего типа: “Я работаю в данной области более 20 лет, всегда делаю X, и это работает”.

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

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

Чужой код

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

/* Same line */
if (something) {
}
else {
}

/* Seprate line */
if (something)
{
}
else
{
}

/* K&R 1TBS (the One True Braces Style) */
if (something) {
} else {
}

А еще мы, конечно, обратим внимание на отступы: табы или пробелы? А если пробелы: 2 или 4?

Code review и pull request

Возвращаясь к разговору о токсичной культуре, можно сказать, что такие события как CR/PR всегда направлены на выявление Ваших слабых сторон и худших качеств на поприще разработчика.

Многие из нас относятся к обзору кода, как к публичной порке.

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

Комментарии

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

let number = 0;
number++ // increment 'number' by one

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

Не забывайте, что в данной статье изложено только личное мнение автора. Спасибо за внимание.

Перевод статьи Nicklas Millard “How to Piss Off a Developer”.