6 грехов, которые совершают программисты

[suffix_ixbt]

ИМХО — самый распространённый грех программистов (из которого и следуют упомянтые в статье мелкие грешки) — ГОРДЫНЯ !

[DrPass]

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

[aasten]

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

[EvilGenius18]

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

[Blindovich]

Мне показалось речь шла о прокрастинации вызванной страхом перетрудиться)

[QuantumBoy]

Лень считать?)))

[lovermann]

Я думаю, что проблема оверинжениринга — это не всегда искусственное создание сложности кода из-за скуки, а часто — просто чужой код с SOF. Какое решение было опубликовано в первом комменте, такое и вставляют в код, не разбираясь, сложно это или не сложно, работает — и хорошо!

[Tangeman]

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

Ну конечно… Нужно взять алгоритм топологической сортировки из зависимости размером в мегатонну (из которой больше ничего не используется), вместо того чтобы реализовать это самостоятельно, причём даже без изобретения этого самого алгоритма.

А если вспомнить историю однострочного isPromise и её последствия (и это всего лишь один пример), то смотреть на велосипеды нужно не в общем, а всегда в частности, и в зависимости от этого взгляда либо изобретать, либо нет, а не отказываться от них "потому что это плохо по определению".

[marenkov]

Прокрастинация

Вместо того, чтобы решать проблемы, программисты часто читают статьи наподобие этой.

[eximus]

Вместо того, чтобы решать проблемы, программисты часто читают статьи наподобие этой.

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

[marsdenden]

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

[DrPass]

Это было бы справедливо, не будь в реальности массы кейсов, когда подобная «фигня» фигнёй и остается, ничего впоследствии не экономя и не сокращая. А зачастую ещё и усложняя разработку, заставляя потом вместо простого решения «в лоб» реализовывать какой-то гибкий мощный API, который нафиг не сдался для данной задачи, ни сейчас, ни в будущем.

[marsdenden]

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

[amazed]

Из субъективного:
1. Использовать хаотичные не информативные названия классов и методов на ломанном английском и высокомерно не сопровождать код комментариями, потому что хорошо написанный, код как известно, в комментариях не нуждается.
2. Вместо того чтобы написать 2 или 3 отдельные функции, написать одну универсальную с кучей параметров и множеством условий внутри, делающих ее работу совершенно непостижимой.
3. Написать функцию, которая содержит проверки некоторых входных параметров на null (когда по смыслу его там вообще быть не должно), после чего вызывает функцию, которая делает запись в лог и проверяет на null что-то еще, затем вызывает функцию, которая всего лишь извлекает значение из массива. Обернуть код каждой внутри try catch с описанием исключения.
4. Изобрести архитектуру классов и абстракции до чтения ТЗ и понимания что нужно делать. Далее строго ее придерживаться.
5. Любые непонятные из ТЗ нюансы реализовать как бог положит. Тестировщики потом разберутся и скажут как правильно. Исправить код так, чтобы он делал в точности то что написали тестировщики, опять не вникать в ТЗ.

[thomasR]

5. Любые непонятные из ТЗ нюансы реализовать как бог положит.

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

[amazed]

Я имел ввиду ТЗ от тимлида. Если у программиста есть проблемы с требованиями заказчика, значит о по совместительству сам себе тимлид, а это уже другая история.

[pproger]

поделюсь своим опытом прокрастинации. не могу сказать, что я очень хороший специалист, но увлеченный, это 100%. и если меня чтот цепляет, то может очень долго не отпускать. так случилось и на работе. прилетела задача, настолько тупая и неинтересная, что делать ее ну никак не хотелось. вместо нее занимался какой-то интересной для себя херью, уже и не вспомню. 2 недели на дейли митингах я оттачивал актерское мастерство, описывая, как продвигаются дела по таске. в начале третьей недели понял, что оттягивать уже некуда закрыл таску, как решенную (код ревью тогда не было). и со спокойной душой взялся уже за следующую. через пару дней прилетает баг от тестеров, не работает якобы закрытая таска. не вопрос говорю, посмотрю. и за пару часов ее резолвлю. через неделю я свалил из конторы (отработал в итоге почти 5 лет) туда, где мне было бы интереснее работать, дабы таких ситуаций не повторялось. конец.

[HellWalk]

7. Соглашаться на неадекватные требования руководства/заказчика.

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

[DrPass]

будьте уверенны, потом никогда не наступит, а за плохой код вас обязательно спросят

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

[usovdm]

Понятно, что перевод, но статья не отличается должным уровнем рефлексии. Можно было и побольше покопаться в себе, а то все «грехи» от высоких идей исходят. А мне кажется все достаточно банальнее и примитивнее.

1. Вроде не такой плохой пункт. И Agile не против, если все зафиксировано. Выполняя первым попавшимся способом, лишаешь себя удовольствия сделать более качественную вторую идею. Но это явно лучше, чем 3. Оверинжиниринг.
2 и 5. Чистая лень и недисциплинированность, на самом базовом уровне. Решается элементарно, донесением ценности и культивации самодисциплины или автодисциплины (линтер).
3. «не хватает мотивирующих задач»? «кусочек кода пригодится в будущем»? Я вас умоляю… А как же страх? Боязнь не предусмотреть все, не сделать идеально? Перфекционизм, синдром отличника, как угодно. Или у западных коллег такого нет? Решение: признать ценность ошибок, каждая из которых ценнее, чем успех с 1ой попытки, и почитать про XP практики (я сам только погружаюсь, и по этой проблеме отличное решение для меня TDD и pair programming).
Выше еще про гордыню писали. Сам не понимаю этих эмоций, т.к. я ближе к вышеописанному, но со стороны кажется, что таких тоже много.
4. Тут не так очевидно, но тут ведь та же самая лень. Не хочется разбираться с библиотекой, не хочется подстраиваться и быть гибким. А тут опять о высоком «отличный способ понять». Прям спекуляция какая-то, что все люди 80% времени обезьянки, а программисты, внезапно, — нет.
6. И опять о высоком… «в тупике или проект «не заходит»». Какое там. Каждый раз, когда «надо» работать, вылазит и прокрастинация. Если задачи приходят сверху, то «стоять» на проект будет достаточно редко. Мотивация — ресурс очень ограниченный. И тут и проявляется профессионализм и дисциплина. Самое важное, не бороться с прокрастинацией силой воли. Силы воли всегда будет меньше, чем случаев прокрастинации. Надо научиться готовить прокрастинацию. Декомпозировать на мелкие и, главное, понятные куски. Ставить перед собой микро цели и фокусироваться на них. Попробуйте TDD, для меня прям средство №1 от прокрастинации.

P.S. Хочу выращить огромную благодарность М. Дорофееву и его «Джедайским техникам пустого инбокса». Прям супер средство от прокрастинации и необоснованной гордыни.

[Miiko]

Кто-нибудь может объяснить простыми словами (а лучше — на примере), что означает «проглотить» ошибку? а то может я это делаю и не знаю?

[DrPass]

try
{
    DoSomethingThatThrowsError();
}
catch()
{
//todo: not forget to handle this exception later when I will have much time for this
}

[Miiko]

Этот пример больше похож на недописанную программу, но идею я понял, спасибо.

[DrPass]

В том-то и проблема, сколько такого недописанного обычно летит в продакшен…

[Moolfred]

Согласен только с последним "прокрастинация и перфекционизм", как результат откладывание фичей на потом, велосипеды, тестирование тестов и т.д.)))