Pull to refresh

Comments 27

В разработке их нет
Лишать премии.
премию еще заработать нужно
а если забирать часть з/п, то так команда быстро разбежится, еще и ужасы про компанию рассказывать будут
Да это я просто как пример. Методов воздействия то не мало, даже не обязательно по карману бить.
По факту же — надо было думать до приёма подобного разработчика.
Не нанимать таких говнюков. Попросить примеры кода или написать небольшое тестовое задание на час-два. И можно будет понять, что за человек. Если еще не ясно — есть испытательный срок. В это время можно вдоволь насмотреться на то, какой код пишет человек. Но лучше всего смотреть личные проекты. Если таковых нет, то я даже не приглашал бы на интервью.
У некоторых премии просто нет.

Если ты плохой разработчик, то и получать ты должен соответственно меньше других, вот и вся арифметика.
Если бы только в разработчике было дело.
Бывает и такое, что вся цепочка дефектная: плохой разработчик -> плохой проектировщик -> плохой менеджер -> плохой директор.
UFO just landed and posted this here
Плохой проект с точки зрения архитектуры/реализации может быть вполне прибыльным, к сожалению.
значит и компания будет убыточна. Если же деньги приходят и не малые — значит время пересмотреть свою оценку.
Да никто никогда не будет писать афигенски читаемый переносимый суперкод! Весь вонючий output программиста необходимо контроллировать, контроллировать и еще раз контроллировать, а еще пинать за говнокод и т.п.

Поставьте себя на место среднего прогера. Быстрее намалевать решение и освободиться — лучшее решение в текущий момент для программиста. Никто все-равно не проверяет что за лапшу там накодил этот прогер, не пинает, коллеги скромно молчат, ведь они такие же… АААА потооом такой программист становится незаменимым т.к. со временем он становится повелителем лапши, единственным человеком разбирающимся в этом говне. Начинает просить большую з.п. Смеется над новичками, которые «такие тупые», что просто поменять текст лабела в формочке не могут и т.п… Хотя тут новичок может и намного опытнее и лучше, но что поделаешь — факты говорят об обратном. Тут у программиста начинает подниматься эго, его наконец «ценят», к нему постоянно обращаются за консультациями, повышают з.п. по первому требованию. А если уже совсем запахло жаренным можно сказать, что ты «перерос» и уволится.

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

Еще раз повторюсь: Контроль, контроль и контроль! Говнокод не должен попасть в главную ветку репы.
Неправда ваша. Многие программисты еще и эстеты в отношении кода. Часто можно слышать, что код «красивый» или «изящный», или бывает «корявый». Писать и одновременно наслаждаться написанным — в этом ловят свой кайф множество программистов. Я лично знаю примеры, когда программисты уходили из компании, где их так или иначе вынуждали писать код, не удовлетворяющий их эстетическим чувствам. Получение удовольствия от процесса работы — мотиватор едва ли менее значительный, чем деньги.
Я не говорил, что эстетов не бывает, но вы же не наберете в команду исключительно их? Обычно 50% кода (если не больше) пишутся низкоквалифицированными кадрами, они лишь кодируют что им говорят. Изначально тепличные условия очень редки. Если вы подскажете такую контору, то с удовольствием конечно попытаю счастье там. Но поймите, чтобы создать такие условия нужен жесткий КОНТРОЛЬ кода и вообще архитектуры! Ревью всегда должно быть.

И вообще 90% эстеты только на словах, им лишь бы поболтать и покритиковать. А уходящие по этим «эстетическим» принципам программисты часто напоминают боящихся испортить педикюр девочек, болтающих беспрерывно за чашечкой чая своим язычком о новых веяниях моды, но только в сфере IT, в то время как настоящие мужики сидят в наушниках и не подавая ни звука кодят. Если все начнем уходить из-за того, что нам не нравится лапша доставшегося в наследие проекта, то что тогда будет? Часто нужно закатывать рукова и сувать свои мужские руки по локоть в это дерьмо! Прочищать эти вонючие трубы, а потом ставить надежные фильтры! Нужно давать по щам желторотым, ато потом весь проект будет обкомичен с ног до головы всяким говном.
Правда бывает, что начальство так или иначе не понимает всей плачевности ситуации, а вы не в состоянии донести до них этого всилу независящих от вас обстоятельств… А еще бывает, что ты становишься уже слишком «немолод чтоли», устаешь от этого всего по горло. Тогда да, лучше искать гнездышко поспокойнее.
По моему опыту достаточно одного эстета, который общается с другими программистами.
Сначала составили неправильную формулу классного водителя, затем сами её разрушили.
Ну и ударю по стереотипам, сказав непопулярное мнение, — не всегда нужно писать хорошо поддерживаемый код в ущерб времени. Лично встречался со случаями, когда я знал что этот код не будет использоваться больше одной недели — прибегает заказчик с ошалевшими глазами, поназаказывает всего «с рюшечками» и чтобы «омлет готовило». Отговаривать это всё равно что ребенку по рукам бить когда он пытается шнурки завязать, поэтому пишу код со скоростью «давай быстрее, не могу терпеть», не в ущерб функционалу, но в ущерб поддержки.
Он смотрит, радуется, а потом понимает что идея была не очень-то и классная.
А еще очень часто нужен просто прототип. И здесь во главу угла ставиться скорость написания, и не правильная проработка архитектуры, тестирование всего и вся. Ведь такой прототип должен быть максимально дешевым и максимально быстро написан для первоначального исследования рынка, и потом должен быть переписан. Обратная сторона: потом его «забывают» переписать, наращивают функционал на платформе, которая изначально не была для этого готова, и в итоге имеем то, что имеем.
С прототипами полностью согласен — вот тут обсуждали.
Ну это вы просто риски на себя перекладываете вместо того, чтобы сделать их публичными и прозрачными для заказчика. Он то потом будет думать, что всегда можно с такой скоростью двигаться. Идеи то далеко не все не нравятся в итоге…
Для этого у меня и есть опыт и интуиция, чтобы почувствовать и понять когда можно писать нормально, а когда быстро. К тому же, мои риски это мои риски и я не нагружаю ими заказчика.
Ну это если вы пишете в гордом одиночестве. В команде такие вещи не сильно приветствуются.
Точно так же у водителей могут быть: плохая логистика, плохой автопарк, необходимость разгружать то, что навозил, постоянно горящие сроки и бесконечный план работ, низкая зп и тд. От всего этого даже лучшие начинают водить абы как.
Полностью согласен. Такие негативные проявления я называю низкой моралью. Откуда ноги растут более-менее понятно: из отсутствия или недостаточного управления процессом. В случае наличия высококультурных разработчиков возможна самоорганизация, только тут как курица и яйцо.
«Any fool can write code that a computer can understand. Good programmers write code that humans can understand.» — Martin Fowler.
А очень хорошие программисты понимают, как тот код будет развиваться, и оставляют самоочевидные места расширения. Высший пилотаж, который средним программистам обычно на первый взгляд незаметен, и только потом когда понадобится что-то дописать, скажешь: «Круто! Предусмотрел ведь!»
Последнее время всё больше убеждаюсь, что умение писать код вторично. С повальным переходам в аджайлу куча времени тратися на то, чтобы узнать какую кнопку где расположить и какое действие должно происходить по клику, затем пишешь тесты и вот звёздный час — пишешь две грёбаные строчки кода самой кнопки и обработчика, затем демонстрируешь заказчику и пару раз переносишь и меняешь цвет кнопки.

В итоге твои изначально идеальные две строчки кода обрастают десятком ифов и становятся далеко не идеальными, НО… Заказчик доволен, он получил то, что хотел, ты классный программист.

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

А у разработчиков с дипломатией и политикой очень плохо. Вот и приходится, либо писать дерьмовый код, либо увольняться (и тогда недописаный код — становится унаследованным дерьмовым кодом).
Sign up to leave a comment.

Articles