вещества?

too long to read

много букв, ниасилил

tl;dr

КГ/АМ

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

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

принято. а ЯП важен?

Если программы пишутся и в большинстве случаев работают правильно, то это нормальный программист.

А если программа работает, но в ней каждом шагу используется GOTO, невнятные названия переменных типа «jdfix», полностью отсутствует комментарии и форматирование текста, методы цепляют данные изо всей программы и программа выдаёт ужасные ошибки и крашится при попытке сделать что-то не так - то можно ли сказать, что её написал хороший программист?

А статью писал вовсе не программист а графоман.
не программист

А откуда не-программист всё это знает?

+= 1

Сий текст явно писал не программист.

то можно ли сказать, что её написал хороший программист?

Я ничего не говорил про хорошего программиста. Я говорил про нормального.

А откуда не-программист всё это знает?

Слушай, ясли я сейчас начну говорить об энергии электронной эмиссии, то это не сделает меня физиком.

ЯП важен?

Нет конечно. Я же говорю — программы работают? Значит всё хорошо.

Так и есть. Особая благодарность автору за указание альтернативных профессий.

Хронических неосиляторов нужно гнать сцаными тряпками из ITшки. Развелось куча кодеров-быдлянчиков с ЧСВ овер 9k.

А если программа работает, но в ней каждом шагу используется GOTO, невнятные названия переменных типа «jdfix», полностью отсутствует комментарии и форматирование текста, методы цепляют данные изо всей программы и программа выдаёт ужасные ошибки и крашится при попытке сделать что-то не так - то можно ли сказать, что её написал хороший программист?

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

Ты какую выбрал?

Очень плохой программист

Каждый, для которого программирование — основная специальность.

По работе императивчик, но всё больше и больше начинаю упарываться хацкелем в свободное время. Не осилю хацкель - самозабанюсь и пойду на площадь ботинки чистить.

Не осилю хацкель - самозабанюсь и пойду на площадь ботинки чистить.

Вот, а многие спрашивают — зачем нужен Хаскель? Большую пользу он приносит современному обществу.

если она работает и дает предсказуемый результат

Дает предсказуемый результат на некотором временном отрезке наблюдений. Если наблюдать чуть дольше - возможно заказчик будет доволен только первую неделю после внедрения.

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

написано в сроки которые поставлены «с верху» - можно ли его назвать плохим программистом? и кто его назовет так?

начальство довольно

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

Важный вопрос - как долго оно будет довольно.

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

оно ведь ничего не понимает,

Это плохое начальство. Так что приходим к выводу что плохие программисты устраивают только плохое начальство. Гармония.

Хотя статья по содержанию так себе

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

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

оно ведь ничего не понимает

Смотря какое начальство. Есть такое, не знающее что такое программа и кто такие программисты.

«плохой» программист скажет

Да, возможный вариант. Когда программист в одном экземпляре.

Теперь ряд предположений. Если программистов много, они объединены в отдел, у отдела есть глава, этот глава подчиняется техдиру... В этом случае намного труднее быть «плохим». Работник (он же специалист по предметной области) жалуется менеджеру (тот тоже в теме), менеджер жалуется техдиру, глава отдела программирования разбирается с конкретным программистом. В таких условиях трудно быть плохим.

этот глава подчиняется техдиру

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

техдир подчиняется начальству которое «не понимает»

Да, такое часто встречается.

техдир может быть плохим и прикрывать плохих программистов

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

в глазах «начальства» опять же все отлично

Свидетельство того, что бизнес плохо построен. Если начнутся разборки среди отделов, как следствие постоянных факапов программистов, виновных найдут и сделают выводы. Если не начнутся, если не найдут, то и незачем обсуждать failed state.

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

как найдут? кто судьи?

Таких увольняют экстренно или на собраниях правления компании.

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

Да, такое часто встречается.

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

Если программы пишутся и в большинстве случаев работают правильно, то это нормальный программист.

Есть ещё такая штука, как поддержка. Если програма пишется и работает правильно, на добавление новой фичи занимает времени в 2 раза больше чем переписывание всего проекта с нуля, то его писал плохой программист.

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

учитывая что переписывать никто не будет с нуля в 99.9% случаев (редко такое встретишь), то и время изготовления замерить будет сложно и цифра «в 2 раза быстрее» не появится, ну а если еще взять понимание того, что написание второго раза с нуля при большем понимании области дает более быстрый результат то и вообще не понятно как это измерить.

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

как найдут? кто судьи?

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

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

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

а платят всегда дяди кто не шарит

Есть дяди, которые им рекомендуют платить/не платить. Они за это несут ответственность. Тут очень многое зависит от доверия.

Да ерунда это всё.
Фичи, время, плохой, хороший.
Это всё (в первую очередь это относится к автору статьи из начального сообщения) от ЧСВ.
Такой образ мыслей не приводит ни к чему конструктивному:
О-о-о-о! Я знаю 36,5 паттернов! А ты, гнида волосатая, не знаешь даже что такое «капсулирующий дельта-класс». Лошара!

Это уныло. Это мерзко. Это как строитель, хвалящийся знанием вязкости металла, из которого сделаны во-о-он те гвозди. Само знание похвально, но похвальба такими знаниями раздражает. А похвальба без сообщения сути знания — заслуживает множественных ударов по морде.

Вот и ты туда же лезешь. Почему в 2 раза? Может в пи раз? Или в е раз? Видишь, взял от фонаря цифру и тащишься какой ты молодец. Ребячество.

Да ерунда это всё.

Сами слова может и ерунда. А вот затраты времени на разработку — не ерунда. Как ты будешь руководству объяснять, что добавление элементарной фичи заняло 2 недели, потому что изначальный код писал индус и оно валится от малейших изменений?

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

смотри, вот тебе дали какой то проект X, ты смотришь на него и говоришь «жесть, говно, писали плохие люди», начальство тебя спрашивает, «что делать?» - ты отвечаешь «переписывать с нуля», они спрашивают «сколько времени это займет?», ты говоришь «около полугода», они «и нахрена?», ты «внесение новых изменений функциональности будет занимать в 5 раз меньше времени», они «ты сможешь это гарантировать? как будем измерять? ведь каждое изменение по своей сути уникально?»

Можно. Если увольняют (а это именно так), значит можно.

Уволить можно, только тот кто увольняет до конца не знает, правильно ли он делает, может оказаться так, что тот кто придет на его место еще хуже.

Не-не-не, я про «переписать с нуля» в шутку сказал. Такое работает только с маленькими проектами. Обычно достаточно объяснить начальству, почему нужно потратить много времени на прибивание скотчем нового функционала, и почему надо ещё потратить время на рефакторинг.

Да так и скажу: писалось индусами. Что тут выдумывать-то?
Да и как вся это всевдоЫлитарная пузомерялка поможет?
О чём вообще разговор?
О том какие мы тут все молодцы и какие вон те люди дураки?
Где цель, мораль, смысл наконец?

Да ну вас. Пойду код писать.

О чём вообще разговор?

Понятия не имею. Я говорил про качество код, а ты прицепился к цифре «2». Наверное, похожая на эту цифру собака в детстве покусала :)

Обычно достаточно объяснить начальству, почему нужно потратить много времени на прибивание скотчем нового функционала, и почему надо ещё потратить время на рефакторинг.

в реальности обосновать это практически невозможно, ибо конца и края рефакторинга обычно нет, можно бесконечно играть в code golf, многие этим даже пользуются во зло, перекатывая код туда сюда, функционал же не меняется, поэтому критерии расплывчаты КПД такого разработчика

У теяб припекло от goto?

конца и края рефакторинга обычно нет

Есть «отрефакторить всё» и «отрефакторить настолько, чтобы конкретная фича влезла без проблем». А вообще зависит от длительности проекта. Если он дан на один раз, то нет смысла много переписывать и рефакторить — ты не оценишь профита. А если он на годы вперёд, то рано или поздно рефакторить придётся, и чем раньше тем проще будет.

тот кто увольняет до конца не знает, правильно ли он делает,

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

Я смотрю в треде много «правильных». Итак, по правилам, программист не архитектор. Вопрос, какого хера тут все так просто, ведь через месяц у нас будет масштабирование, а программа так проста, что не масштабируется, относится к архитектору. Программист здесь причем? Если архитектор любит нихера не делать и дал комманду программисту «решай сам» без указания планов на будушее. Кто берет роль архитектора, тех дир или его помощник или «у нас все архитекторы» признак стократного ССЗБ. Плох тот программист, который решил поиграть в архитектора без предъявления претензий по ЗП и взятию ответственности за принятие решений. Если молча принял, сделал и готов все исправить в случае ошибки — хороший программист. Отсутствие входных данных о планах на будущее делает любого эксперта идиотом и плохим програмистом.

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

Нет совести, кругом ложь (заказчику: наша всеми уважаемая компания решает за день любые задачи, ЛЮБЫЕ) и кругом только виноватые.

goto ненужен.

можно ли его назвать плохим программистом?

По крайней мере нельзя назвать хорошим.

Слушай, ясли я сейчас начну говорить об энергии электронной эмиссии, то это не сделает меня физиком.

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

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

Мне нравится эта методика!

Посмотри хотя бы сюда, дурачок

https://github.com/torvalds/linux/blob/master/drivers/ata/ahci.c