Когда кто-то будет считаться плохим программистом? [закрыто]

57

Как вы считаете, что программист плох в том, что он или она делает?

Если возможно ... Как он / она должен улучшиться?

Tom Wijsman
источник
3
Потому что указанный человек не принимает ответы на веб-странице, связанной с программированием. Шучу :-)
Даниил
1
@EvanKroske: Нет, это не правильно .... Сообщество Wiki существует, чтобы разрешить совместное редактирование сообщений. Смотрите также: Наша мета-метка: сообщество-вики
Тамара Вийсман
На многие вопросы невозможно принять ни одного ответа. Смотрите также: Наша мета - Поиск: принять
Тамара Вийсман
Не каждый вопрос получает ответ, который действительно решает проблему.
Лорен Печтел

Ответы:

134

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

Мы все зеленые в какой-то момент; однако, если вы не поправляетесь или пытаетесь поправиться, значит, вы плохой программист.

PSU_Kardi
источник
4
Согласитесь - вы должны иметь обратную связь, всегда учиться на своих ошибках.
Марсель Ламот
1
@ PSU хорошо сказано. Как и любое ремесло, программисты - торговцы и не совершенны, всегда учатся, но если вы не учитесь на ошибках, вы не улучшаете свое мастерство.
Крис
2
Это очень широкое определение; это не ограничивается программистами. Это касается ученых, поваров, спортсменов, переводчиков, уборщиков, фотографов и действительно любой профессии.
RegDwight
13
Каждый придурок хотя бы раз в неделю.
МВД
@RegDwight: а ваша точка зрения была ...?
SamB
125

Программист, который не знает того, чего не знает, и вообще не заинтересован в этом.

Гравитон
источник
16
Если бы я мог повысить это 100 раз, я бы. Немного смирения и голода учиться компенсирует многое в долгосрочной перспективе.
Уильям Пьетри
1
+1 для Нгу и Уильяма тоже. Это самый типичный критерий плохого «программиста».
Фабрика
Что происходит, когда вы знаете, что не знаете много, и как бы сильно вы ни старались, вы никогда не узнаете большую часть этого?
Стивен Эверс
@snOrfus, ты найдешь наставника, который научит тебя ...
75

Большой предупреждающий знак - если они программисты "культа груза" - это значит, что они делают вещи, но не знают, зачем они это делают (это просто "магия"). Отличный пост Эрика Липперта здесь .

Из статьи:

программисты, которые понимают, что делает код, но не понимают, как он это делает.
Марсель Ламот
источник
3
* и некоторое время программировал в этой технологии
Джо Филлипс
5
Это применимо практически ко всем программистам, которые когда-либо занимались веб-разработкой с такими фреймворками, как Java / Spring или Ruby on Rails. Эти фреймворки полны чёрной магии, которую обычные программисты обычно не понимают.
фактор
3
@ Missing Faktor - и, следовательно, было бы не слишком неточно сказать, что большинство программистов, которые делают это, не являются
хорошими
14
С другой стороны, нереалистично предполагать, что программисты должны полностью понимать внутреннюю работу фреймворка, виртуальной машины или того, на чем они строят код. (Или, действительно, детали всех уровней абстракции ниже, пока не будет достигнут голый металл.) Вы можете быть очень хорошим, продуктивным программистом, даже если вы знаете только самые важные части.
Джоник
4
@ Missing Faktor: они могут не понимать внутреннюю часть библиотек и фреймворков, которые они точно используют, но они должны, по крайней мере, знать, для чего каждая вещь в их коде: «поймать обморок», потому что в документации сказано, что это необходимо сохранить целостность пространственно-временного континуума »и т. д.
SamB
45

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

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

JohnFx
источник
Ах да, я работал с ним. К счастью, в прошедшем времени.
Майк Вудхаус
1
Некоторые даже не могут сформировать достойные вопросы, просящие вас «просто исправить это»
deltreme
21

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

EpsilonVector
источник
1
Я думаю, что могли бы быть некоторые новички с потенциалом быть хорошими программистами - у кого есть проблемы с этим.
Джей Ди Айзекс
2
Новичкам хорошо, если вы ищете младшего программиста, которого вы намереваетесь сформировать и превратить в хорошего. Но эта проблема настолько тривиальна, что не нужно ни у кого с опытом писать время.
Мэтт ДиТролио
8
Я бы сказал, что никому, кто успешно прошел курс программирования начального уровня, не нужно много времени, чтобы решить эту проблему.
EpsilonVector
4
Если новичок не может решить FizzBuzz, он не должен подавать заявку на программирование. Если вы утверждаете, что умеете программировать (например, подаете заявку на работу по программированию), вы должны быть в состоянии решить FizzBuzz.
Чинмай Канчи
1
Stackoverflow вопрос на FizzBuzz стоит посмотреть. Посмотрите на решение Python, которое не использует деление или модуль. stackoverflow.com/questions/437/…
Гордон
21

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


Приложение: (добавив то, что тире сказал ниже в комментариях)

Расширением этого являются люди, которые знают подмножество функциональных возможностей какой-либо технологии, но не хотят больше узнать о ней. Язык программирования, редактор, другие инструменты ...

оборота отсутствует фактор
источник
6
... и без веских причин, я должен добавить.
фактор
18

Когда член команды является разработчиком негативных программ .

|# Lines Written| - |# Lines of bugs introduced| - |# Lines of rework required| < 0

Это означает, что остальная часть вашей команды должна делать больше из-за плохого разработчика. NNPP

danivovich
источник
1
Я согласен - эти люди могут быть чрезвычайно вредными для их команды.
Марсель Ламот
44
Ха ... Я вчера удалил 500 строк избыточного кода и не внес ошибок. Метрики LOC считаются вредными?
Писквор
5
Большинство показателей ужасны, а показатели LOC обычно более бесполезны. Дело в том, что плохой программист - это тот, кто создает больше работы для команды, чем он / она выполняет.
Данивович
5
Метрики LOC не бесполезны. Они ВРЕДНЫ. Кроме того, подсчет LOC очень сложен в большинстве современных языков. Но метрика не в этом. Это просто говорит | Работа для создания | - Работа, которая была неправильной | - | работать над исправлением | ... то есть, если вам потребовалось 10 часов, из которых вы потратили 6 часов, работая над чем-то, что в конечном итоге пришлось исправить, и потребовалось еще 6 часов, чтобы сделать это, тогда у вас -2 часа. Время действительно то, что вы пытаетесь получить в любом случае.
МВД
1
Метрики LOC - отличный способ измерить, сколько мест должны скрывать ошибки.
SamB
18

Когда они производят вещи, которые регулярно появляются на The Daily WTF .

Билли ОНил
источник
15

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

JeffO
источник
Но могут быть экспертные разногласия по поводу того, что «лучше».
ДаренВ
@DarenW - Я бы не сказал , что кто - то плохой программист , потому что они приняли сторону по спорной теме, но когда у них есть окончательный выбор в их собственном сознании.
JeffO
15

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

Daenyth
источник
5
Что делать, если они не могут найти ничего плохого, и это их беспокоит?
SamB
1
Или, что еще хуже, они не могут найти что-то не так и пытаются это исправить.
Toon Krijthe
15

Те, кто игнорирует предупреждения о своих кодах и заботится только об ошибках.

Reigel
источник
14

Когда я был руководителем группы в небольшом магазине, было несколько человек, которых мне пришлось переназначить (ни у меня, ни у моего непосредственного руководителя не было возможности расторжения без тонны красной ленты и кучи документации.) Или без продления контракта. в конце текущего сражения. Некоторые из перечисленных типов также работали для других руководителей команд, и они в значительной степени придерживались той же точки зрения. Вещи, которые привели людей в категорию «Плохой программист» в моей книге:

  1. Необратимый или окостеневший в прошлом
    Когда «программист», кажется, не в состоянии освоить новую систему, новый инструмент или что-либо еще, что бы ни применялось, независимо от того, как проходит обучение / обучение. Должен повторять эти тренировки на регулярной основе.
    Когда «программист» знает только те технологии или парадигму кодирования, которые они использовали 10 или 15 лет назад. Тогда это было достаточно хорошо, так почему они должны меняться?
  2. Ковбой кодер
    Человек, который кодирует первым, без плана. «Программист», который делает непроверенные изменения в производственном коде и / или данных «потому что мы должны исправить это сейчас», а затем удивляется, когда «исправить» не удается.
    Ковбой также определенно не командный игрок. Не нуждается в вонючей команде.
  3. Флюгер погоды
    Этот «программист» очарован «технологией путешествия » и видит каждую новую структуру, язык, методологию или что-то новое и горячее, как
  4. «Большой мозг»
    Этот «программист» настолько уверен в своем таланте и способностях, что все сделано, что не имеет большого смысла в проекте. например, переписать стандартную библиотеку «потому что она неэффективна для нашей системы» или представить инструменты и методы, не подходящие для рассматриваемой проблемы. например, введение Lisp или Forth в среду мэйнфреймов.
  5. LOC a. Sandbagger
    Этот «программист» использует обфускацию и неправильное направление, чтобы увеличить a. LOC: строки кода, за которые платят. В этой ситуации я видел код, который представлял собой страницу за страницей, экран за экраном с дублирующейся структурой и логикой, в которых менялись только имена абзацев или управляющих переменных, чтобы увеличить количество строк.
  6. Незаменимый эксперт
    «Программист», обладающий знанием предметной области для решения стоящих перед ним задач, но поскольку он «знает» обо всем этом. На самом деле, если бы их сбил автобус, вся организация рухнула бы. { Наблюдение: те, кто считают себя незаменимыми, обычно являются. (Кто-нибудь получил источник этого афоризма?)}
  7. The Pasta Chef
    Этот «программист» специализируется на спагетти-коде, приправленном идентификаторами, которые слишком сложны для понимания без синтаксически реализованной IDE. например, IndexI1O0, Index1I0O и т. д.
  8. Летний стажер - конкретно подтип «Бродячая катастрофа» В
    моем старом магазине нанимали нескольких молодых специалистов позднего школьного или колледжа. Когда-то департаменту требовалась небольшая база данных для отслеживания использования некоторого оборудования (теперь это было недопустимо, и он использовал dBase III). Парень кодировал все лето, но это не было сделано, когда колледж начался осенью. Он получил продление на одну неделю, а затем на вторую неделю. В конце второй недели меня отправили принять его проект и вернуть его к разработке систем для завершения. Он показал мне то, что он сделал, а затем незаконченную часть. То , что сработало у хорошего глаз конфеты, но приложение былонеполный. Когда я открыл новую коробку с отформатированными дискетами, чтобы получить копии, он сказал: «Секундочку, позвольте мне удалить мои тестовые файлы ...», и прежде чем я успел что-либо сказать, он удалил кучу файлов.
    Будучи подозрительным, и обнаружив, что его приложение было почти ничем иным, как приятным глазом, когда я вернулся в свой магазин, я вернулся в отдел и вытащил Нортона и восстановил удаленные файлы, пытаясь найти дополнительную логику, даже если неполный.
    Я нашел не плохую логику, а плохое поведение. Принтер, подключенный к ПК, который он использовал, был принтером с гирляндой. Набор символов, обычно установленный, был швейцарским вариантом. На выходе удаленных программ выводятся имя, адрес, DOB, некоторые буквенные коды и некоторый тип идентификационного номера. Формат и верстка надоели мне. Все даты рождения для нескольких людей были едва ли законным пьющим возрастом. Большинство адресов не было, когда я посмотрел их в нашем каталоге. Когда я показал распечатки его руководителю, он посмотрел на меня и сказал: «Водительские права, не правда ли?» Я сказал, что сделал так. Он сказал, что именно по этой причине он обнаружил, что запасы прозрачности полностью уничтожены в мусорном баке рядом с ксероксом. Наш плохой мальчик сделал пометки, чтобы скорректировать возраст своих и его друзей по их водительским удостоверениям. Мы сообщили об этом властям.не заплатил за его последние две недели.

Это лишь некоторые из плохих персонажей, с которыми мне приходилось работать ....

/ s / BezantSoft

оборота БезантСофт
источник
RE «Те, кто считают себя незаменимыми, обычно» напоминают мне en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
DaveDev
10

Невозможно приспособиться к будущим технологиям

Гопи
источник
10

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

оборота Чинмай Канчи
источник
1
И программист действительно плох, когда он не может прочитать хорошо написанный код :-)
Maniero
4
Разве это не будет почти у всех? Я имею в виду, разве код не всегда труднее читать и / или поддерживать, чем должен быть?
SamB
Нет. Код всегда легче написать, чем прочитать. Но мне пришлось поддерживать очень хорошо написанный код, который максимально уменьшил эту боль.
Чинмай Канчи
10

Когда никто другой не может прочитать его код. Неважно, насколько вы ярки; ни один программист не является островом.

stevenvh
источник
Ну, если он пишет в Унламбде, никто не сможет его прочитать.
SamB
Кроме того, когда программисту требуется очень мало времени, чтобы сделать что-то вначале, а затем много времени, чтобы сделать некоторые настройки для этого. Я часто видел, как это происходит, потому что программист в основном копирует вставляет код (поэтому сначала быстро), но потом отнимает много времени, потому что трудно (даже для хороших программистов) изменить его оттуда из-за отсутствия намерения написать настраиваемый код в начале.
Сандипан Нат
7

Кто-то, кто не обращает внимания на детали и всегда находится в режиме «это работает, поэтому я оставляю это в покое. Все эти исключения в журналах не имеют значения».

talonx
источник
7

Для меня есть две категории для программистов - соло и команда.

Плохие сольные программисты

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

Плохие программисты команды - это те, кто попадает в категорию плохих индивидуальных программистов, включая

  • Те, кто не может координировать свои действия с другими членами команды.
  • Те, кто не приветствует критику.
  • Те, кто не знает, как быть полезным для других и как извлечь выгоду из других членов команды.
  • Те, кто не может написать читаемый код.
  • Те, кто не комментирует ради читабельности для других.
тиа
источник
8
Я не помню точно, как я реализовал вещи, которые я запрограммировал на прошлой неделе. Это необычно? У меня сложилось впечатление, что работа с конечной человеческой памятью была лишь одной из задач программирования. Отсюда важность структурирования и документирования кода, так что мне не нужно запоминать детали.
Джеймс
@James Прошу прощения за мой английский;). Я имею в виду, что если программист вернется, чтобы посмотреть свой код несколько дней спустя, и у него не будет никаких подсказок, это плохой знак. Я также не помню, как и что именно я сделал несколько дней назад, но я уверен, что мне не нужно чесать голову, когда я смотрю на собственный код и говорю: «о чем я думал?»
ТИА
@James: Точно, он должен задокументировать свой код, чтобы не имело значения, что он забыл, как работает половина
кода
4

Не желая признать, что они не знают ответа и / или не хотят искать вещи.

Если вы этого не знаете, не сдавайтесь - разберитесь и сделайте это.

Дин Хиггинботам
источник
4

Большим предупреждением в моем опыте является то, что они не комментируют свои хаки ....

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

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

Бобби Столы
источник
3

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

user2528
источник
3

Будучи repreategly показан правильный способ сделать это, и не раз просто делать это легкий путь.

DaveDev
источник
3

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

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

Двоичный код отлично работает на компьютерах: он равен 1 или 0, включен или выключен. Мы можем абстрагировать и кодировать много информации, используя эти два знаменитых состояния. Но это не имеет ничего общего с человеческими делами: «хорошо» или «плохо», «вменяемый» или «безумный», «добро» или «зло», «умный» или «глупый», «толстый» или "худой", "живой" или "мертвый?" Подобные поляризованные оценки всегда оставляли заботливого человека частью меня ужасно неудовлетворенным. Какими бы схемами измерения я ни пользовался, я обычно нахожу, что ответы на такие резкие контрасты на самом деле лежат где-то вдоль континуума между одним таким полюсом и другим, а не на обоих концах.

Я уже давно борюсь с этой тенденцией к поляризации, и мое личное решение состоит в том, что я считаю гораздо более полезным применять три слова для любой такой оценки: « до какой степени!»

Итак, мой ответ на ваш вопрос состоит в том, чтобы предложить вам перефразировать его и задать себе вопрос: «В какой степени я плохой программист?» Или, что еще лучше, задать вопрос в другом направлении: «Насколько я хороший программист?» Если вы преследуете истину, вы, вероятно, найдете себя где-то на континууме между «плохим» программистом и «хорошим». Затем, когда вам удастся найти приблизительно то место, где вы находитесь на этом пути, вы, вероятно, сможете определить точку, несколько ближе к «хорошему» концу - точку, в которой вы хотели бы оказаться в ближайшем будущем.

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

Поэтому я настоятельно рекомендую вам попробовать мои три маленьких слова «до какой степени» и посмотреть, как далеко в правильном направлении они могут вас занять!

Джон Тоблер
источник
2

Кто-то, кто говорит "Это не может быть сделано".

На мой взгляд, все дело в решении проблем, инструмент должен быть гораздо менее актуальным, чем фактически выполненная работа. Если я должен решить эту проблему с помощью MS-Access или ассемблера, это вопрос времени и денег, а не вопроса "Это невозможно сделать"

Предупреждающий знак - это слишком большой акцент на академическом и «правильном» способе ведения дел и недостаточное внимание к выполнению работы.

Дэн Уильямс
источник
2
И когда он говорит, почему это можно сделать?
Маньеро
1
Итак, как насчет решения проблемы остановки? Это можно сделать?
П Швед
2
Плохо отклонить что-то как невозможное, если это не так и наоборот.
Рэндалл Шульц
2
@Randall Schulz: Насколько я могу судить по craigslist, программист рок-звезды - это тот, кто занимается всеми уровнями разработки (база данных, пользовательский опыт, развертывание, sysadmin и поддержка пользователей) в рекламном агентстве за значительно меньшую зарплату, чем обычно. одна из тех вещей. Они называют их рок-звездами, потому что после 60 часов в неделю их диета похожа на тех, кто ездит в фургоне с эконолином и должен закладывать свои гитары в пищу.
Дэн Монего
1
Да, я сделал широкое обобщение :), но ... это было важно. «Мое профессиональное мнение, что это не должно быть сделано», лучше. Еще лучше "Как насчет решения той же проблемы другим способом". Моя точка зрения - хороший программист должен быть ориентирован на решение. «Это невозможно сделать», без предложения вариантов очень расстраивает клиента.
Дэн Уильямс
2

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

Чанки патхак
источник
2

Когда они делают много понтификата, но производят очень мало.

Gratzy
источник
2

! (умный и добивается цели)

Ник Пирпойнт
источник
== глуп или не способен что-либо сделать ;-).
Toon Krijthe
2

Те, кто не знает таких принципов, как SOLID, DRY, OOP и так далее. Важно хорошо понимать принципы и основы программирования, а не знать конкретные технологии. Те, у кого есть прочная основа, смогут легко изучать новые темы и создавать лучший код.

Гиорги
источник
2

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

tcrosley
источник
2

Непосредственный сигнал распознавания - это когда кто-то говорит: «Я не понимаю, почему это не работает. Я все сделал правильно».

Роберт Россни
источник
За ним внимательно следит: «Я не понимаю, почему это работает, это неправильно».
Рэндалл Шульц
Да, это глупый компьютер :)
Дэн Уильямс
2

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

Однажды я унаследовал систему, в которой предыдущий разработчик повторно реализовал (на Java) большой набор API-интерфейса Ashton Tate DBase III +, размещенного поверх пользовательской библиотеки доступа dbf. Ни одна из рамок коллекций Java не использовалась.

Это было для того, чтобы он мог написать приложение на Java / swing, которое выглядело бы и действовало как приложение DBase III + (или, возможно, Clipper).

Приложения, которые он написал в этой системе, имели меню lite-bar и открывали полноэкранную форму с рядом кнопок внизу, когда вы переходили в lite-bar к этой опции. Это было похоже на маленькую машину времени в 1980-х.

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

Но он был ужасным программистом в том смысле, что его код неправильно использовал возможности систем, над которыми он работал. Он был более готов потратить 3 месяца на нестандартную библиотеку сомнительного преимущества, чем изучать Java / Swing / SQL.

сал
источник