Программистов очень легко вывести из себя. В сообществе разработчиков, где каждый имеет свои «религиозные» взгляды на код и технологии, споры вспыхивают мгновенно. Не существует, пожалуй, более токсичной среды, чем сообщество программистов и инженеров. Даже обсуждение того, как правильно назвать нашу профессию, может вызвать бурю негодования.
Кто мы: разработчики, программисты или инженеры?
Самый простой вопрос — кем считать себя: разработчиком, программистом или инженером — может вызвать жаркие дебаты. У одних поднимается давление, если их называют «разработчиками», в то время как другие могут обидеться на то, что их не считают «инженерами». В этой статье мы рассмотрим темы, которые действительно раздражают программистов, в зависимости от их опыта и убеждений.
If-Else против полиморфизма: вечный спор
Однажды я написал статью под названием «Прекратите использовать if-else» («Stop using if-else»), которая вызвала огромный резонанс. Она собрала более 100,000 просмотров всего за несколько дней и стала причиной создания целой ветки хейтеров на Reddit. Оказалось, что существует настоящая секта сторонников традиционного ветвления, которые приветствуют использование if-else и раздражаются от самого существования объектно-ориентированного программирования. Для них любые упоминания о полиморфизме — это как красная тряпка для быка.
Непрофессиональная оценка задач
Одна из самых раздражающих ситуаций для разработчика — когда оценку его работы проводит человек, не имеющий технического образования. Вспоминается случай, когда мой проект оценивал коллега с дипломом по политическим наукам. Он предположил, что весь проект можно выполнить за 34-36 часов одним разработчиком, и представил это клиенту без консультации со мной. Подобные решения, принятые без участия специалистов, могут выводить из себя даже самых спокойных программистов.
Статьи о программировании: источник споров
Статьи, посвященные программированию, часто становятся полем битвы для разработчиков. Особенно когда в них даются советы, которые идут вразрез с традиционными подходами. Комментарии вроде «Я работаю в этой сфере уже 20 лет и всегда делаю X, и это работает» подчеркивают, насколько болезненно программисты воспринимают изменения и новые идеи. Проблема в том, что в мире программирования все быстро меняется, и старые методы часто становятся неактуальными. Тем не менее, публикация подобных материалов вызывает волну споров и даже ненависти.
Чужой код: ненависть с первого взгляда
Мы часто ненавидим чужой код, особенно когда уверены, что можем сделать лучше. В таких случаях нас раздражает всё: от реализации задачи до использования синтаксических деталей, таких как расположение фигурных скобок:
/* Same line */
if (something) {
}
else {
}
/* Separate line */
if (something)
{
}
else
{
}
/* K&R 1TBS (the One True Braces Style) */
if (something) {
} else {
}
И, конечно, вечный спор: табы или пробелы? А если пробелы, то сколько — два или четыре?
Code Review и Pull Request: публичная порка
Для многих разработчиков процессы Code Review и Pull Request — это не просто проверка кода, а настоящее испытание на прочность. Обзор кода может ощущаться как публичная порка, особенно когда вы тратите часы на создание функционала, который потом критикуют и разрушают за считанные минуты.
Комментарии в коде: необходимость или зло?
Комментарии в коде — ещё одна бесконечная тема для обсуждений. Существует мнение, что если ваш код требует комментариев, значит, он недостаточно ясен:
let number = 0;
number++; // увеличиваем 'number' на один
Очевидно, что хорошо продуманные комментарии могут быть полезными для других разработчиков, а также для вас самих, когда вы вернетесь к этому коду спустя время. Однако, комментарии часто становятся предметом споров, особенно когда их использование кажется излишним.
Заключение
Программирование — это не только технический процесс, но и эмоциональное испытание. Токсичные споры и раздражение — неотъемлемая часть этой среды. Каждый из нас имеет свои убеждения и принципы, которые могут вступать в конфликт с чужими. Важно помнить, что в конечном итоге все эти дебаты помогают нам расти как профессионалам, развивая нашу гибкость и способность адаптироваться к изменениям.
