Коли когось вважали б поганим програмістом? [зачинено]

Як ви вважаєте, що програміст погано ставиться до того, що він чи вона робить?

Якщо можливо ... Як йому / їй вдосконалитись?

Коли вони не вчаться на своїх помилках та в рецензії.

Ми всі в якийсь момент зелені; однак, якщо ви не покращуєтесь або намагаєтесь покращитись, то ви поганий програміст.

Програміст, який не знає, чого не знає, і зовсім не зацікавлений, щоб це дізнатися.

Великий попереджувальний знак - якщо вони програміст "культового культу" - це означає, що вони роблять речі, але не знають, чому вони роблять це (це просто "магія"). Чудовий пост Еріка Ліпперта тут .

Зі статті:

програмісти, які розуміють, що робить код, але не те, як він це робить.

Для мене велика порада, коли вони задають вам або іншим питанням розробників програмістів, які чітко показують, що вони доклали абсолютно нульових зусиль, щоб зрозуміти це самостійно.

Наслідком є ​​те, коли вони задають одне і те ж запитання програмування кілька разів, вказуючи, що вони не інтерналізують інформацію.

Коли їм потрібно багато часу, щоб вирішити проблему FizzBuzz.

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

Додаток: (додаючи те, що тире сказано нижче у коментарях)

Розширенням цього є люди, які знають підмножину функціональності деяких технологій, але не виявляють бажання дізнаватися про неї більше. Мова програмування, редактор, інші інструменти ...

Коли учасник команди є негативно розвиваючим розробником .

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

Це означає, що решта вашої команди повинна більше працювати через поганого розробника. NNPP

Коли вони виробляють речі, які регулярно з'являються на The Daily WTF .

Коли вони знають, що є кращі способи робити речі, але все ж відмовляються їх робити навіть тоді, коли дозволяє час.

Особисто я вважаю, що будь-який програміст, який може подивитися на власний код, який вони написали деякий час тому, і не знайти в ньому щось не так, не є хорошим. "Час" може бути масштабним із досвідом ... Я б сказав, що від кількох тижнів до року або близько того.

Ті, хто ігнорує попередження щодо своїх кодів і піклується лише про помилки.

Коли я був керівником команди в невеликій крамниці, було декілька людей, яких мені довелося перепризначити (ні я, ні мій безпосередній керівник не мали можливості розірвати без тонни Червоної стрічки і купу документації.) Або не поновити контракт наприкінці поточного залучення. Деякі з перерахованих типів також працювали для інших лідерів команд, і вони, в основному, займали той же погляд. Речі, які перевели людей у ​​категорію "Поганий програміст" у моїй книзі:

1. Недосвідчений або костенізований у минулому
   Коли, здається, "програміст" не може засвоїти нову систему, новий інструмент чи інше, що використовується, незалежно від того, як проводиться навчання / освіта. Доводиться часто повторювати зазначені тренування.
   Коли "програміст" знає лише технологію чи парадигму кодування, яку вони використовували 10 чи 15 років тому. Це було досить добре тоді, то чому вони повинні мінятися?
2. Ковбойський кодер
   Людина, яка кодує перше, без плану. "Програміст", який вносить неперевірені зміни у виробничий код та / або дані ", тому що ми повинні це виправити зараз", а потім дивується, коли помилка "виправлення" не вдається.
   Ковбой також, безумовно, не гравець команди. Не потрібна смердюча команда.
3. Флюгер
   Цей «програміст» закоханий з «технологією чергові » і бачить кожен новий рамковий, мова, методологію або будь-які нові та гарячі , як
4. "Великий мозок"
   Цей "програміст" настільки впевнений у своєму таланті та можливостях, що робиться все, що не має великого сенсу проекту. наприклад, переписування стандартної бібліотеки "тому, що вона неефективна для нашої системи" або введення інструментів та методів, не підходящих для проблеми. наприклад, представлення Lisp або Forth в середовищі мейнфреймів.
5. LOC ^a. Пісочниця
   Цей "програміст" використовує затуманення і неправильне напрямок для збільшення ^а. LOC: Рядки коду, за які платять. Я бачив код у цій ситуації, який був сторінка за сторінкою, екран за екраном дублюючої структури та логіки, із зміною лише назви змінних абзацу та елементів керування, щоб накачати кількість рядків.
6. Незамінний експерт
   "програміст", який має доменні знання для вирішення проблем, але вони знають "все". Власне кажучи, якби їх вдарив автобус, тоді вся організація зіткнулася б. { Спостереження: Зазвичай такі, хто вважає, що вони незамінні. (Хтось отримав джерело про цей афоризм?)}
7. Шеф-кухар макаронних виробів
   Цей програміст спеціалізується на коді спагетті, приправленому ідентифікаторами, які занадто важко слідувати без синтаксично реалізованої IDE. наприклад, IndexI1O0, Index1I0O і т.д.
8. Літній стажер - конкретно підтип Ходяча катастрофа У
   моєму старому магазині колись наймали стажувальників пізньої середньої школи чи коледжу. Одного разу департаменту була потрібна невелика база даних для відстеження використання обладнання (зараз це було відмовою назад, і воно використовувало dBase III). Хлопець кодував усе літо, але цього не робив, коли коледж розпочався восени. Він отримав продовження на тиждень, а потім на другий тиждень. Наприкінці другого тижня мене відправили взяти його проект і повернути його до системи розробки систем. Він показав мені зроблене, а потім незакінчену частину. Те, що працювало, мало приємні очні цукерки, але додаток булонеповний. Коли я відкрив нову скриньку відформатованих дискетів, щоб отримати копії, він сказав: "Лише на секунду, дозвольте мені видалити свої тестові файли ...", і перш ніж я можу щось сказати, він видалив купу файлів.
   Будучи підозрілим і виявивши, що його заява майже не є окрім цукерки, коли я повернувся до свого магазину, я повернувся до відділу і витягнув Нортона та видалив файли, які він видалив, намагаючись знайти додаткову логіку, навіть якщо неповна.
   Я виявив, не погана логіка, але погана поведінка. Принтер, прикріплений до ПК, яким він користувався, був принтом колеса Дейзі. Нормально встановлений набір символів був швейцарським варіантом. У висновку видалених програм виводяться ім’я, адреса, DOB, деякі літерні коди та певний тип ідентифікаційного номера. Формат і макет мене турбували. Усі дати народження для кількох людей були ледь законним віком. Більшість адрес там не було, коли я переглянув їх у нашому перехресному довіднику. Коли я показав роздруківки його керівнику, він подивився на мене і сказав: "Водійські посвідчення, ви не думаєте?" Я сказав, що так і зробив. Він сказав, що саме тому він знайшов запас прозорості весь розрізаний у смітнику поруч із Xerox. Наш поганий хлопчик зробив накладки, щоб підкоригувати його та його друзів віком на посвідчення водіїв. Ми повідомили про це владі.не заплатив за останні два тижні.

Це лише деякі з поганих персонажів, з якими мені довелося працювати ...

/ s / BezantSoft

Неможливо адаптуватися до майбутніх технологій

Крім очевидного браку знань / здібностей, програміст є поганим, якщо їх код важче читати та / або підтримувати, ніж повинен бути.

Коли ніхто більше не може прочитати його код. Не має значення, наскільки ви яскраві; жоден програміст не острів.

Хтось, хто не звертає уваги на деталі і завжди знаходиться в "це працює, тому я залишаю його в спокої. Усі ці винятки в журналах не мають значення".

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

Погані сольні програмісти

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

Погані програмісти - це ті, хто потрапляє в категорію поганих сольних програмістів, в тому числі

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

Не бажаючи визнавати, вони не знають відповіді та / або не бажають шукати речі.

Якщо ти цього не знаєш, не здавайся - з’ясуй це і зроби це.

Великий попереджувальний знак у моєму досвіді - це коли вони не коментують свої хаки ....

Ви знаєте, що я маю на увазі: коли тебе змушують робити щось дуже хакітне, тому що просто немає кращого способу зробити це.

Хороші програмісти будуть ненавидіти, що потрібно це робити, і вкладати вбудовані коментарі, кажучи, наскільки вони ненавидять вводити такий хак, але вибору немає. Погані програмісти просто помістять хак і не коментуватимуть це.

Тихо, очевидно, коли програміст пише багато коду. Дуже великі функції, можливо, скопіюйте / вставте рядки або блоки коду, використовуючи набагато більше ifs, ніж це необхідно, і т. Д. Це може бути тому, що програміст не знає стандартної функції робити те, що він хоче, але більшу частину часу це не так.

Будучи репрезентативно показано правильний спосіб зробити це, і неодноразово просто робити це легким способом.

Я перекладаю свою відповідь сюди із закритої дубліката теми, яка запитала Чи можете ви визнати, чи поганий ви програміст? Інша тема була закритою, коли я писав свою відповідь. Моя відповідь прямо стосується питання, як це було сформульовано іншим запитувачем, і він буде читати краще, якщо ви це розумієте.

Зітхніть! Частина мене не хотіла додавати до цієї вже зайнятої теми, але інша частина мене перемогла! Чому вона перемогла; чому я намагаюся додати ще багато слів до цього конкретного мультилогу? Ну тому, що я певною мірою можу трохи по-іншому сприймати це, ніж багато попередніх коментаторів.

Бінарне працює чудово на комп’ютерах: "1" або "0", "увімкнено" або "вимкнено". Ми можемо абстрагувати та кодувати багато інформації за допомогою цих відомих двох держав. Але це, як правило, не працює так добре в людських справах: "хороший" чи "поганий", "здоровий" чи "божевільний", "добрий" чи "злий", "розумний" чи "дурний", "жирний" чи "худий", "живий" чи "мертвий?" Такі види поляризованих оцінок завжди залишали турботливу людину частиною мене жахливо незадоволеною. За будь-якими схемами вимірювань, які я вирішив застосувати, я зазвичай вважаю, що відповіді на такі різкі контрасти насправді лежать десь уздовж континууму між одним таким полюсом та іншим, а не в обох кінцях.

Я боровся з цією тенденцією до поляризації вже досить давно, і моє особисте рішення полягає в тому, що я вважаю набагато кориснішим застосувати три слова до будь-якої такої оцінки: " в якій мірі!"

Отже, моя відповідь на ваше запитання полягає в тому, щоб запропонувати вам перефразувати це питання і запитати себе так: "Наскільки я поганий програміст?" Або, ще краще, запитати це в інший бік: "Наскільки я хороший програміст?" Якщо ви переслідуєте правду, ви, ймовірно, знайдете себе десь уздовж континууму між "поганим" програмістом і "хорошим". Потім, як тільки вам вдасться приблизно знайти місце, де ви знаходитесь на цьому шляху, ви, ймовірно, зможете визначити точку, дещо ближчу до "доброго" кінця - точку, де ви хочете опинитися найближчим часом.

Якщо ви не встановите цю точку занадто далеко, ви, ймовірно, можете отримати задній кінець передач і почати рухати його в тому напрямку. Якщо вам вдасться кілька разів повторити цей досить простий евристичний алгоритм, ви, можливо, незабаром опинитеся надто зайнятим програмуванням, щоб вам потрібно було знову задати це питання! О, і, ймовірно, ви будете швидше прогресувати, якщо почнете стукати код по клавіатурі так швидко і часто, як тільки зможете; і, якщо ви зробите невелику перерву час від часу, прочитайте якісний високоякісний код, написаний вашими колегами! У наші дні динамічного розвитку з відкритим кодом у вас не вистачає безкоштовного та вишуканого коду, з якого можна навчитися!

Отже, я настійно рекомендую вам спробувати три мої маленькі слова "в якій мірі" і подивитися, наскільки далеко в хорошому напрямку вони можуть вас відвести!

Хтось каже: "Це неможливо зробити".

На мою думку, це все у вирішенні проблем, інструмент повинен бути набагато менш релевантним, ніж власне робота. Якщо мені доведеться вирішити це за допомогою MS-Access або мови монтажу, це питання часу і грошей, а не питання "Це неможливо зробити"

Попереджувальний знак - це занадто велика концентрація уваги на академічному та "правильному" способі виконання дій, а також недостатня концентрація на роботі.

Якщо він знає лише синтаксис мови, але не знає основних понять алгоритмів.

Коли вони багато понтифікують, але виробляють дуже мало.

(розумний і все робить)

Ті, хто не знає таких принципів, як SOLID, DRY, OOP тощо. Важливо добре розуміти принципи та основи програмування, а не знати конкретні технології. Ті, хто має міцну основу, зможуть легко вивчати нові теми та створювати кращий код.

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

Сигналом негайного розпізнавання є хтось, хто говорить: "Я не розумію, чому це не працює. Я все зробив правильно".

Одне, що відрізняє поганого програміста від початківців програмістів, - це вперте наполягання на впровадженні своєї улюбленої системи будь-якою мовою та API, на якому вони працюють.

Я колись успадкував систему, де попередній розробник повторно реалізував (на Java) великий набір Ештан-Тейт DBase III + api, накладений поверх спеціальної бібліотеки доступу dbf. Жодна рамка колекцій Java не використовувалася.

Це було так, що він міг написати програму Java / swing, яка виглядала і діяла як додаток DBase III + (або, можливо, кліпер).

Програми, які він написав у цій системі, мали меню "смужка-панель", і вони відкривали б повну форму вікна з рядком кнопок внизу, коли ви переходили на панель Lite до параметра. Це було як невелика машина часу назад до 1980-х.

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

Але він був жахливим програмістом в тому, що його код неправильно використовував функції систем, над якими він працював. Він охочіше витратити 3 місяці на користувальницьку програму сумнівної користі, ніж вивчати Java / Swing / SQL.