Как вы считаете, что программист плох в том, что он или она делает?
Если возможно ... Как он / она должен улучшиться?
Как вы считаете, что программист плох в том, что он или она делает?
Если возможно ... Как он / она должен улучшиться?
Ответы:
Когда они не могут учиться на своих ошибках и на экспертных оценках.
Мы все зеленые в какой-то момент; однако, если вы не поправляетесь или пытаетесь поправиться, значит, вы плохой программист.
Программист, который не знает того, чего не знает, и вообще не заинтересован в этом.
Большой предупреждающий знак - если они программисты "культа груза" - это значит, что они делают вещи, но не знают, зачем они это делают (это просто "магия"). Отличный пост Эрика Липперта здесь .
Из статьи:
программисты, которые понимают, что делает код, но не понимают, как он это делает.
Большая подсказка для меня, когда они задают вам или другим разработчикам вопросы о программировании, которые ясно показывают, что они приложили абсолютно нулевые усилия, чтобы понять это самостоятельно.
Следствием является то, что они задают один и тот же вопрос программирования несколько раз, указывая на то, что они не усваивают информацию.
Когда им требуется много времени, чтобы решить проблему FizzBuzz.
Программисты, которые отказываются изучать новые технологии / языки и настаивают на том, чтобы придерживаться того, что они уже знают.
Приложение: (добавив то, что тире сказал ниже в комментариях)
Расширением этого являются люди, которые знают подмножество функциональных возможностей какой-либо технологии, но не хотят больше узнать о ней. Язык программирования, редактор, другие инструменты ...
Когда член команды является разработчиком негативных программ .
|# Lines Written| - |# Lines of bugs introduced| - |# Lines of rework required| < 0
Это означает, что остальная часть вашей команды должна делать больше из-за плохого разработчика. NNPP
Когда они производят вещи, которые регулярно появляются на The Daily WTF .
Когда они знают, что есть лучшие способы сделать что-то, но все равно отказываются делать это, даже если позволяет время.
Лично я думаю, что любой программист, который может взглянуть на свой собственный код, который они написали некоторое время назад, и не найти в нем что-то не так, не очень хороший. «Время» может меняться с опытом ... Я бы сказал, от нескольких недель до года или около того.
Когда я был руководителем группы в небольшом магазине, было несколько человек, которых мне пришлось переназначить (ни у меня, ни у моего непосредственного руководителя не было возможности расторжения без тонны красной ленты и кучи документации.) Или без продления контракта. в конце текущего сражения. Некоторые из перечисленных типов также работали для других руководителей команд, и они в значительной степени придерживались той же точки зрения. Вещи, которые привели людей в категорию «Плохой программист» в моей книге:
Это лишь некоторые из плохих персонажей, с которыми мне приходилось работать ....
/ s / BezantSoft
Помимо очевидного недостатка знаний / способностей, программист является плохим, если его код труднее читать и / или поддерживать, чем должен быть.
Когда никто другой не может прочитать его код. Неважно, насколько вы ярки; ни один программист не является островом.
Для меня есть две категории для программистов - соло и команда.
Плохие сольные программисты
Плохие программисты команды - это те, кто попадает в категорию плохих индивидуальных программистов, включая
Не желая признать, что они не знают ответа и / или не хотят искать вещи.
Если вы этого не знаете, не сдавайтесь - разберитесь и сделайте это.
Большим предупреждением в моем опыте является то, что они не комментируют свои хаки ....
Вы знаете, что я имею в виду: когда вы вынуждены делать что-то очень хакерское, потому что просто нет лучшего способа сделать это.
Хорошие программисты будут ненавидеть делать это и вставлять встроенные комментарии, говорящие о том, как сильно они ненавидят вводить подобные взломы, но выбора нет. Плохие программисты просто вставят взломать и не комментируют его.
Тихо, очевидно, когда программист пишет много кода. Очень большие функции, может быть, копировать / вставлять строки или блоки кода, используя больше ifs, чем необходимо, и т. Д. Это может быть потому, что программист не знает стандартной функции, чтобы делать то, что он хочет, но большую часть времени это не делает.
Я перенесу свой ответ сюда из закрытой повторяющейся темы, в которой спрашивается. Можете ли вы распознать, если вы плохой программист? Другая тема закрывалась, когда я составлял свой ответ. Мой ответ более прямо касается вопроса, как он был сформулирован другим спрашивающим, и будет лучше читать, если вы это понимаете.
Вздох! Часть меня не хотела добавлять к этой уже занятой теме, но другая часть меня победила! Почему это победило; почему я пытаюсь добавить еще слова в эту конкретную мультилог? Ну, потому что, в некоторой степени, у меня может быть немного другое мнение об этом, чем у многих предыдущих комментаторов.
Двоичный код отлично работает на компьютерах: он равен 1 или 0, включен или выключен. Мы можем абстрагировать и кодировать много информации, используя эти два знаменитых состояния. Но это не имеет ничего общего с человеческими делами: «хорошо» или «плохо», «вменяемый» или «безумный», «добро» или «зло», «умный» или «глупый», «толстый» или "худой", "живой" или "мертвый?" Подобные поляризованные оценки всегда оставляли заботливого человека частью меня ужасно неудовлетворенным. Какими бы схемами измерения я ни пользовался, я обычно нахожу, что ответы на такие резкие контрасты на самом деле лежат где-то вдоль континуума между одним таким полюсом и другим, а не на обоих концах.
Я уже давно борюсь с этой тенденцией к поляризации, и мое личное решение состоит в том, что я считаю гораздо более полезным применять три слова для любой такой оценки: « до какой степени!»
Итак, мой ответ на ваш вопрос состоит в том, чтобы предложить вам перефразировать его и задать себе вопрос: «В какой степени я плохой программист?» Или, что еще лучше, задать вопрос в другом направлении: «Насколько я хороший программист?» Если вы преследуете истину, вы, вероятно, найдете себя где-то на континууме между «плохим» программистом и «хорошим». Затем, когда вам удастся найти приблизительно то место, где вы находитесь на этом пути, вы, вероятно, сможете определить точку, несколько ближе к «хорошему» концу - точку, в которой вы хотели бы оказаться в ближайшем будущем.
Если вы не установите эту точку слишком далеко, вы, вероятно, сможете включить задний конец в передачу и начать движение в этом направлении. Если вам удастся повторить этот довольно простой эвристический алгоритм несколько раз, вы можете вскоре оказаться слишком занятым программированием, чтобы снова задать этот вопрос! О, и вы, вероятно, добьетесь большего успеха, если начнете набирать код на клавиатуре так быстро и часто, как сможете; и, если вы сделаете небольшой перерыв время от времени, прочитайте качественный код, написанный вашими коллегами! В наши дни динамичной разработки с открытым исходным кодом у вас нет недостатка в бесплатном и изысканном коде для изучения!
Поэтому я настоятельно рекомендую вам попробовать мои три маленьких слова «до какой степени» и посмотреть, как далеко в правильном направлении они могут вас занять!
Кто-то, кто говорит "Это не может быть сделано".
На мой взгляд, все дело в решении проблем, инструмент должен быть гораздо менее актуальным, чем фактически выполненная работа. Если я должен решить эту проблему с помощью MS-Access или ассемблера, это вопрос времени и денег, а не вопроса "Это невозможно сделать"
Предупреждающий знак - это слишком большой акцент на академическом и «правильном» способе ведения дел и недостаточное внимание к выполнению работы.
Если он знает только синтаксис языка, но не знает основных понятий алгоритмов.
Непосредственный сигнал распознавания - это когда кто-то говорит: «Я не понимаю, почему это не работает. Я все сделал правильно».
Одна вещь, которая отличает плохой программист от новичка программистов упрям настойчивое внедрение их любимой системы на любом языке и API они работают в.
Однажды я унаследовал систему, в которой предыдущий разработчик повторно реализовал (на Java) большой набор API-интерфейса Ashton Tate DBase III +, размещенного поверх пользовательской библиотеки доступа dbf. Ни одна из рамок коллекций Java не использовалась.
Это было для того, чтобы он мог написать приложение на Java / swing, которое выглядело бы и действовало как приложение DBase III + (или, возможно, Clipper).
Приложения, которые он написал в этой системе, имели меню lite-bar и открывали полноэкранную форму с рядом кнопок внизу, когда вы переходили в lite-bar к этой опции. Это было похоже на маленькую машину времени в 1980-х.
Человек был явно опытным разработчиком. Он достаточно знал, что он мог написать всю эту систему сам во время этого проекта. Он также смог повторно использовать его в нескольких других внутренних системах.
Но он был ужасным программистом в том смысле, что его код неправильно использовал возможности систем, над которыми он работал. Он был более готов потратить 3 месяца на нестандартную библиотеку сомнительного преимущества, чем изучать Java / Swing / SQL.