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

Джон Парселл, создатель CaveOfProgramming.com

1. Использовать «Пробел» вместо «Tab». Всегда, всегда используйте «Tab», а не «Пробел».
2. Использовать «Tab» вместо «Пробела». Всегда, всегда используйте «Пробел», а не «Tab».
3. Не использовать автоформатирование. Забудьте про весь мусор вроде табов и пробелов, используйте автоформатирование в своем коде и людям не придется видеть ваши странные скобки и отступы.
4. Использовать интегрированную среду разработки (IDE) с ее автоформатированием и цветными клавишами. Все коды должны быть написаны в vi или Emacs, что подтверждает безупречность ваших навыков программирования.
5. Не использовать IDE. Никто не хочет платить за время, которое вы тратите на набор текста, если это можно сделать в один клик, или за прокручивание вверх-вниз с помощью заумной комбинации клавиш из LISP.
6. Не учить С и С++. Два этих языка жизненно необходимы любому программисту. Думаете, Java так же хорош? Отлично, создайте мне систему управления гоночными автомобилями в режиме реального времени на Java, и я вам поверю.
7. Учить С и С++ в то время, которое вы могли бы использовать на что-то более современное, например, на Java. Признайте – все таблицы, написанные на С или С++, изживают себя в течение 5 лет. И в таком случае в программном обеспечении есть серьезные ошибки, которые Java просто не позволил бы вам совершить.

Рой Леман, разработчик ПО

1. Сначала написать, потом подумать. Вы получили требования к товару, пробежались по ним, запустили свою любимую IDE и принялись за работу. Легко, не правда ли?
   Стоп! Вы уверены, что поняли требования до конца? Я не сомневаюсь в вашем умении читать. Но учли ли вы все пограничные случаи? Продумали, как будете тестировать систему? Набросали алгоритм, который собираетесь использовать? Завтра вы этого и не вспомните!
2. Изобретать колесо. Итак, вам нужно создать шаблон проектирования Producer-Consumer. Вы знаете, как это сделать, еще с университетской скамьи… Легко, не правда ли?
   Стоп! Не важно, с каким языком вы работаете, уже существуют готовые шаблоны, или модули, или открытые исходники. Используйте их. Или по крайней мере изучите их перед тем, как создавать свои.
3. Бояться прикасаться к коду. Итак, у вас есть задание добавить несколько функций к 20 000-линейному файлу (О, нет! За что?) Вы радостно беретесь за работу и вдруг замечаете огрехи в исходных функциях – нет пограничного случая или проверки на нулевой показатель. Это находится за пределами сферы вашей ответственности. Так? Стоп! Если вы видите небезопасный код – исправьте его. Вы еще хлебнете на этих ошибках, даже если код написан не вами!
4. Быть безразличным к тому, чем занимается ваша компания. Вы программист, верно? Написание кодов – это здорово, вы не изучали маркетинг или продажи, с чего вам интересоваться тем, что не имеет к вам отношения?
   А следовало бы! Как можно создать продукт, не понимая, чем занимается компания? Как сделать так, чтобы продукт удовлетворял потребности клиента?
   Никак! Изучите дело, будьте в курсе всех вопросов компании, а не только тех, которые касаются непосредственно вас. Это важно! В какой-то момент это даже может повлиять на ваше повышение.

5. Не следить за новыми трендами. Вы занимаетесь программированием уже 10 лет и подыскиваете работенку.
   Перед этим вы работали старшим разработчиком С++ в крупной корпорации – за многое отвечали и имеете отличные рекомендации. Вы вроде знаете, что такое DevOps, но на практике никогда не сталкивались с этими практиками и с С++14? На вашем предыдущем месте работы в ходу был С++98… Не так уж важно, не так ли?
   Нет, не так!
   Никто не похвалит вас за владение технологиями 15-летней давности!
   Если вы не учитесь в свободное время, чтобы соответствовать запросам работодателя, ваша кандидатура будет отвергнута!
6. Не обладать коммуникативными навыками. Вы разработчик, к чему вам уметь общаться с людьми! Вам платят за умение общаться с компьютером, а не коллегами. Сиди себе, пиши качественные коды и добьешься успеха, верно?
   Не верно!
   Ваше неумение кратко и четко изложить суть дела вышестоящим – самая большая головная боль для менеджера.
   Очевидно, что это не единственный параметр, по которому вас оценивают, но все же – грамотное предоставление информации в дружественной манере повысит доверие со стороны коллег и вот тогда вы добьетесь успеха.
7. Не иметь целей. Вам нравится ваша работа, вы прекрасно владеете технологиями Deep Learning. Передовые технологии, прекрасные коллеги… Вы могли бы работать так вечно.
   Но – вы не будете. Все когда-нибудь заканчивается, иногда резко и неожиданно. Если у вас не будет карьерных целей, вы можете оказаться на задворках, выполняя работу и получая зарплату, которые вас не достойны.
   Так что думайте наперед – где бы вы хотели оказаться через 10 лет? В какой роли вы себя видите?
   Научным работником? Разработчиком? Менеджером по продукции? Вице-президентом? Техническим директором? Исполнительным директором?
   Вам решать!

Нико Салминен, старший консультант

1. Лень: Ну, кажется, код работает нормально. Нет необходимости писать комментарии или проводить автоматизированное тестирование.
2. Похоть: Эй, а ведь этот новый срочный проект – отличная возможность опробовать новый крутой фреймворк, о котором все говорят!
3. Зависть: Другая команда продвигается быстрее, чем мы. Лучше не помогать, если у них возникнут проблемы при интеграции с нашим кодом.
4. Чревоугодие: Мне нужно выполнить итерацию ключей объекта. Мне совершенно необходимо импортировать 1,5-Мбайтную библиотеку для проведения этой операции.
5. Гордыня: Прочтение этой книги по шаблонам проектирования сделало меня лучшим разработчиком, нежели коллеги! Я собираюсь использовать каждый шаблон, упомянутый в книге при работе над следующим проектом.
6. Гнев: К черту все! Пускаю этот патч hotfix прямиком в производство!
7. Алчность: Они что предлагают изменить код в моем репозитории? Отклонить! Это мой проект!

Усман Шаукат, более 8 лет опыта в сфере веб-разработки, PHP, Javascript, Node.Js

Вопрос касается программирования не как процесса разработки ПО в целом, так что мой ответ касается непосредственно фазы программирования:

1. Программировать, не планируя. Самый страшный из всех грехов.
2. Пытаться изобрести колесо. Если есть возможность, всегда используйте алгоритмы, предложенные в книгах и научных статьях (например, алгоритмы сортировки, поиска и т.д.), а не пишите собственные.
3. Писать несистематизированные/некачественные коды и не придерживаться стандартов программирования.
4. Считать, что тестирование – это не ваша забота. Я вас очень прошу, пожалуйста, тестируйте свои коды.
5. Писать сложный код, когда с тем же успехом можно обойтись простым. Простые коды – это элегантно.
6. Слепое копирование-вставка с сайтов вроде stackoverflow.com без ознакомления с пояснениями и комментариями.
7. Последнее, и самое важное – совершенствуйтесь сами и осваивайте новый инструментарий. Никогда не бойтесь новшеств. Знакомьтесь с ними раньше всех. Это поможет вам оставаться востребованным.