Переводим на 50+ языков, делаем видео IT-компаниям
62,66
рейтинг
2 июня 2015 в 08:16

Разработка → Восемь различных типов программистов перевод


Кадр из фильма Kingsman
Уверены, в этой статье вы точно узнаете своих сотрудников, а возможно, и себя. Шведский предприниматель и разработчик Дэвид Эльбе описал восемь типов программистов, с которыми ему приходилось иметь дело за последние 10 лет работы в проектах по веб-разработке. Какие типы лучше всего объединить в команду и какой код от них ждать — читайте в переводе от Alconost Translations.

1. Агент 007



Кадр из мультфильма “Пингвины Мадагаскара”
Быстро вникает в ваши проблемы и решает их. Не очень заботится о качестве кода. Ему не придет в голову исправлять отступы в чужом коде. Если необходимо, «воспользуется скотчем».

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

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

Плохо срабатывается с Перфекционистом.

2. Господин 90 %




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

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

Не уживается с тестерами, но отлично соблюдает дедлайны. Объедините такого программиста в одну команду с Агентом 007. Это будет хорошая команда.

3. Любитель переписывать код




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

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

Если дать такому программисту существующий проект на PHP и MySQL, он начнет переписывать его на Go и базе данных, не поддерживающей SQL. И только потом он спросит, какую проблему необходимо было решить.

4. Перфекционист




Похож на Любителя переписывать код, но в отличие от него стремится сделать идеальным свой собственный код. Может тратить целые дни на задачи, которые Агент 007 решает за пару минут, но при этом готовый код будет безупречен.

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

Перфекционист никогда не может правильно оценивать время, необходимое на проект, так как совершенство не имеет временных рамок.

5. Кодер-копипастер




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

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

6. Экспериментатор




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

Никто ничего не знает о качестве его кода, поскольку он ничего не создает, но при этом постоянно экспериментирует с новинками.

Хорошо срабатывается с Любителем переписывать код.

7. Спагетти-кодер




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

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

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

8. Псевдокодер


Менеджер, который считает, что сможет лучше объяснить что-то сотрудникам, написав псевдокод.
if
  price of beer is less than 10
then
  do order drink
else
  exit foobar

В действительности это выглядит так, как будто он разговаривает с ребенком: «Ой, какой милашка! Принеси мамочке вон тот красный мячик! Умница, хороший программист!»

Ну как, узнали себя в каком-то из типов?
Автор: @alconost David Elbe
Переводим на 50+ языков, делаем видео IT-компаниям

Комментарии (87)

  • +33
    Может проверить весь ваш секретный API-ключ в вашем опенсорсном проекте на Github, потому что это самое быстрое и простое решение.

    Оригинал:
    Checks in all your secret API-key in your open source project on Github, because that was the quickest and simplest solution.

    Это переводится как «Может закоммитить все ваши секретные API-ключи на Github».
    • 0
      Спасибо! Поправили, сейчас все ок?
      • +1
        На гитхаб никто ничего не загружает. Закоммитить это именно закоммитить. Если не хотите использовать жаргонизм, напишите «сделать коммит».
        • +11
          <зануда>Ну если уж быть совсем дотошным, то запушить. Коммитят обычно все-таки в свою локальную репу, а потом уже пушат на какой-нибудь ремот</зануда> Хотя
          • +1
            Я согласен, это так. Но в оригинале — check in, что синоним коммита, а не пуша.
            • +14
              Есть красивый и элегантный жаргонизм «залить», не являющийся калькой с английского.
              • –1
                «закоммитить» — это не калька, калька была бы что-нить вроде «засовершить»:) Но «залить» — отличное слово, в самый раз!
                • +5
                  Вы, случайно, не четвёртый тип? ;)
                  • –1
                    2, 3, 4, 6:)
            • –1
              `check in` — синоним именно пуша, а не коммита, потому что в распределенных репозиториях такого действия нет, оно родом из времен, когда svn было самым прогрессивным хранилищем. В svn — `check in` это push@github, commit@github это add@svn.
              • –4
                check-in == ci === commit
                По смыслу, как уже указывали, больше подходит пуш, да.
              • 0
                Повторюсь, что в оригинале все-таки check-in, а не push, и по поводу этого термина все претензии к автору, а не к переводчику и тем более не ко мне.
                • 0
                  Давайте я еще раз попробую. В распределенных системах check-in отсутствует. Но термин жив. Ибо еще живы люди, которые помнят svn. Там существовал check-in (и там от был алиасом commit’а, это правда).

                  Применительно к github — check-in это push. Period. “Make check-in into remote git repository” переводится c английского на консольный язык как “git push”. Period.

                  Претензий я никаких не высказывал, не минусовал я никогда из принципиальных соображений, я лишь ответил на ваш неверный комментарий.
          • +1
            Если уже быть совсем дотошным, то «закоммитить» родилось в среде пользователей cvs и svn. Там commit означает немедленную отправку изменений на сервер. Отсюда и путаница.
  • +2
    Прошел следующие этапы: псевдокодер, спагетти-кодер, сейчас боюсь дойти до «перфекциониста» с элементами «экспериментатора»
  • +14
    Я думаю, все программисты в разные моменты времени и требований — это сочетания перечисленных в статье за исключением 5 и 8. Последние — не программисты.
    • +4
      все программисты в разные моменты времени и требований

      В точку, когда читал, нашел себя в разных типах, в разные временные отрезки и на разных проектах.
    • 0
      Тут все так же, как с темпераментами, но в случае с кодом имеет хаотическое влияние техзадание)
  • +4
    1, 3, 4 >< Ибо очень быстро пишу базовый код, который потом несколько раз переписываю, доводя до идеала
    • 0
      На мой взгляд это очень правильный подход, сам так делаю. Сначала прототип для демонстрации и прощупывания, а потом — доводка и расширение.
  • +7
    Действительно, не кажется ли автору статьи, что категории в общем-то не взаимоисключающие? Например, 6 и 4 вполне могут сочетаться. Но в целом, многие категории как-то наталкивают на представления о начинающем программисте.
    • 0
      Соглашусь. Это не сколько категории, а набор личных качеств. Некоторые категории получаются противоположными экстремумами одной шкалы измерения меры. В списке явно каких-то измерений ещё не хватает.

      В идеале у разработчика должен быть баланс при начале работы с поставленной задачей, а уже исходя из ситуации динамически смещаться в ту или иную сторону по мере необходимости. Беда когда программист изначально смещён в своём подходе к решению задач, требуя пристального контроля для соблюдения сроков и качества. Это свойственно молодым и неопытным… Ну, или старым и упёртым.
      • 0
        Я бы сказал, что авторы нащупали некоторые базисные вектора подпространства «программисты». Не все, и вероятно линейно зависимые, но попытка зачётная.
  • +1
    Полноценный агент 007, за что много раз получал по мозгам от Перфекциониста. Но сработались нормально. В начале задачи пытались работать по его правилам, под дедлайн возжи отдавались мне, и почти всегда успевали. Но в начале следующей задачи он матерясь в душе приводил в порядок мой код решения предыдущей задачи.
    • 0
      Это здорово, когда 007 осознает, что он им является! Бывает что человек явно из этой категории, но признать этого не хочет, поэтому к попыткам править свой код относится очень болезненно
  • +3
    Псевдокод слишком негативно освещён. Очень часто перелопачивая несколько страниц технических требований по разрабатываемым продуктам (или уже каких-то инженерных документов) требуется сжато и понятно изложить постановку задаче в issue tracker'а. Простая отсылка к документу и даже его обсуждение не всегда даёт желаемый результат и даже негативно сказывается на производительности команды, т.к. все разработчики вынуждены перечитывать весь документ (100-1000+ стр.), обновляющийся по ходу разработки, чтобы полностью понять одно конкретное требование из него.

    Псевдокод позволяет более осведомлённому архитектору и менеджеру, видящих проект целиком, описать требуемую логику, которую впоследствии смогут быстро понять другие участники команды, когда будут разбираться в коде двухлетней давности.
  • +1
    Любит решать проблемы в рабочих средах, так как его локальная копия для разработки никогда не работает.


    Не сразу понятно что за рабочие среды такие. А вот в оригинале все понятно:
    Likes to fix things in production environments, because her local development copy never works.


    Человек любит сразу на продакшн-серваке разработку вести (в частности)!
    • +5
      Предложу осмысленный, хоть и вольный перевод: «Предпочитает вести разработку на сервере заказчика, потому что не в состоянии настроить рабочую среду у себя на машине»
  • +2
    > Если дать такому программисту существующий проект на PHP и MySQL, он начнет переписывать его на Go и базе данных, не поддерживающей SQL.

    Мы знакомы???
    • +8
      Кстати, не понятно почему и зачем перевели NoSQL (в виде «не поддерживающей SQL»), но почему тогда и SQL не перевели? ;-)
      • +8
        Может быть, автор просто (еще) не знаком с данным термином
      • +10
        image
  • –1
    Перфекционист какой-то слабый — на картинке нужно больше симметрии.
    • 0
      Как вы алфавитный суп уложите в квадратную сетку по алфавиту «более симметрично»?..
      • –1
        Не заметил, что он алфавитный. :)
        А так красненькие надо было по углам разложить. Или вообще по кругу.
    • 0
      В аду для перфекциониста
      ни серы нету, ни огня,
      и лишь слегка несимметрично
      стоят щербатые котлы © anoubis
  • +3
    Перфекционист-экспериментатор. Такое возможно? :)
    У меня в проекте есть копипейстер. Фраза «понятия не имеет, что он делает» просто в яблочко! К сожалению, он не проводит дни на StackOverflow. Для любой даже самой простой задачи он задаст пятьдесят вопросов, до тех пор, когда ему не объяснишь даже не как делать, а как это написать. А после этого добьет еще пятьюдесятью вопросами типа «я написал как ты сказал, а у меня вылез этот эксепшн», и копипейст стектрейса…
    • +7
      Зачем вы его держите? По-моему, такому человеку надо объяснить, что либо он начинает делать всё сам (с разумным привлечением помощи в оговоренных моментах), либо вы с ним прощаетесь.

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

      Кстати, запрещать ему дёргать именно вас по пустякам бесполезно, он будет дёргать кого-то ещё, причём постарается, чтобы вы этого не видели. Посадите его поближе к себе и смотрите, как он работает.
    • +2
      Попробуйте найти для него работу, в которой не может возникнуть много вопросов. Часто бывают унылые куски, качество которых особо не важно, важна именно копипаста. Грамотный специалист при виде этих задач впадает в уныние (ну или начинает радостно разрабатывать Большой Фреймворк на ближайшие пару лет). А копипастеру самое то. Все вопросы решаются подсматриванием в аналогичные готовые куски.
      • 0
        Собственно я его и посадил писать интеграционные тесты, где надо придумать большое количество данных, заполнять формы и сообщения. При всем при том, что вся инфраструктура тестинга разработана, чел не понимает даже какие случаи надо оттестировать. Весь отчет: «я попробовал запустить тест, высылаю тебе лог системы». К сожалению, решение о его присутствии в команде зависит не от меня. Он был приведен, чтобы «набираться опыта», но челу это как бы не нужно.
        • 0
          К счастью, в моих командах таких случаев не было, но со стороны я это наблюдал. Лучшее, что можно сделать — отстранить его от работы вообще, чтобы не мешался под ногами и не отвлекал других. Пусть сидит тихонько в углу, в игрушки играет. Если ему это не понравится (в чём я сомневаюсь) и он побежит жаловаться своему покровителю — объясните ему, что вы можете либо заниматься обучением дундука, не желающего учиться, либо делать свою основную работу.
          • 0
            это звучит сильно жестоко
            • +1
              Зато результативно.
  • 0
    Слишком много пунктов, достаточно всего трёх:
    1. Куятор — выдаёт быстрый результат всегда ужасного качества, тем кто не знает изнанки нравится, тем кто знает изнанку — нет
    2. Потерянный хакер — знает технологии, но результат выдаёт исключительно медленно и обычно не очень хорошего качества т.к. не всегда технологии к месту и не всегда понята задача, никому не нравится.
    3. Нормальный программист — пишет нормального качества код, тестирует его. Работает не быстро, но хорошо. Разработчикам нравится, желающим результата кажется что он работает медленно, особенно на фоне куятора.

    остальное это уже незначительные модификации этих трёх вариантов
    • +4
      Куятор куятору рознь. Одно дело выдать результат ужасного качества, который ещё и не решает проблему как надо, и который выгоднее было написать сразу хорошо. А другое — в кратчайшие сроки подпереть падающую стену костылём, или слепить новую функцию из говна и говна (даже не используя палки), чтобы как можно быстрее всё заработало так, как надо.

      Грамотный куятор востребован и любим в двух случаях: либо когда всё уже горит, либо когда неясно, надо ли оно вообще, или этот кусок проекта покроется пылью через два дня после релиза. Это и есть «агент 007» по классификации поста.
      • 0
        нене, любовь к куятору означает что всё плохо, ничем хорошим его не оправдать, разве что сферический в вакууме случай когда куятор делает прототип, но сразу после того как становится ясно что он нужен его переписывают нормальные программисты
        • +7
          Вы живёте в идеальном мире, где ничего не падает по вине третьих сторон, о DDoS-атаках ваша компания знает из газет, сервера не умирают посреди ночи, а интернет-каналы всегда стабильны? Что ж, могу за вас порадоваться, потому что где-то в вашей компании сидит куятор, который любезно огораживает вас от всего этого, чтобы вы могли спать по ночам и работать по техзаданию.

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

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

          Хреновый код при равной стабильности и скорости работы отличается от хорошего кода только маленькой стоимостью написания и сравнительно большой стоимостью изменения. Никаких других отличий между ними нет, как бы ни было приятно многим воображать обратное.
          • –4
            Нене, то что произошло по вине третьих сторон легко исправляется хорошими админами и программистами (мало того, они пишут так что внешний мир редко что-то ломает), куятор для этого не нужен.
            Зато куятор порождает код изменять который может практически только он, а без него стоимость будет очень высока.
  • 0
    пятый пункт, судя по отпечаткам, даже копипастит двумя руками. Не преставляю, как можно так нажать одной рукой, чтобы остались такие отпечатки, обычно cmd нажимается боком или даже чуть-чуть ногтевой стороной большого пальца. За исключением копипастера у нас есть все типы
    • 0
      А я нажимаю мизинцем. Как-то так и должен остаться отпечаток.
      • 0
        именно cmd? в случае с ctrl и виндовой клавой, да, мизинец удобнее всего. Но на маковой клаве мне даже приходится прикладывать некоторое усилие, чтобы попасть мизинцем в cmd, а указательным в c/v
        • 0
          ctrl, ага.
          cmd на маковой, судя по картинке, расположен как alt на виндовой… Можно средним нажимать, а указательным — с и v, тогда получатся такие отпечатки. Но я бы тоже большим нажимал.
          • 0
            все равно, отпечатки, вроде бы, от нажатий плашмя. Я как ни пробовал, у меня так не получилось. Видимо, для таких нажатий нужны руки более высокого разрешения )
            • 0
              А вы правой рукой попробуйте.
        • 0
          Я alt на обычной клавиатуре в комбинации Alt+V нажимаю безымянным пальцем. Отпечаток будет полный и нажимать удобно. Так что вполне правдоподобно.
        • 0
          При слепом десятипальцевом вводе разумнее нажимать Cmd/Alt большим пальцем. Остальные модификаторы — уже от клавиатуры зависит, слишком большой разброс. Про функциональные клавиши и говорить нечего, там ад и содомия, особенно на ноутбуках.
  • +1
    Полноценный «4. Перфекционист». Обожаю работать с «2. Господином 90%».
    К сожалению, часто приходится делать «7. Спагетти-кодер», ненавижу «6. Экспериментатор», но перфекционирую и его при необходимости :)
    • 0
      Во, у меня почти то же самое. Правда с некоторыми отличиями: «6. Экспериментатор» никогда не делаю и с представителями такого стараюсь не связываться, но раньше довольно часто обожал (как правильно перевёл valexey тут) «Человек любит сразу на продакшн-серваке разработку вести». Ныне же при работе на заказчика я «4. Перфекционист» на все 100%. Пока не вылижу код так, чтобы «скрипел когда по нему пальцем проведёшь» считаю что работа не сделана. А когда пишу для себя, то или «1. Агент 007», или «7. Спагетти-кодер», всё равно кроме меня этот быдло-китайско-индусский код никогда никто не увидит.

      Когда-то потерял собственные исходники, напрочь и без возможности восстановления. Это было давно, я был ещё молод и глуп несравненно, никаких систем контроля версий у нас в организации не использовалось, да я про такие и не знал. Бекапы тоже никто никогда не делал, было полное раздолбайство, а программу надо было поддерживать. Восстанавливать исходники времени не было и я где-то месяца полтора исправлял, добавлял или убирал функциональность в программе методом бинарного патчинга запускаемого файла в hiew. И ничего, работало. Хорошо что эту программу перестали использовать ещё до того, как я уволился, перешли на другое железо и программа стала не нужна. А то бы ух как пришлось бы попотеть тому, кто пришёл после меня. Сейчас я конечно так никогда не поступаю, бекапы и VCS наше всё! Но каким я тогда был программистом согласно приведённому списку? Такого пункта, который бы подходил, я не нашёл.
      • 0
        Вы подпадали под первый пункт. Его критерий — не плохой код сам по себе, а нацеленность на решение проблем бизнеса ценой абстрагирования от процесса написания кода. Код же при этом может быть плохим (чаще всего), может быть хорошим, или же его может вообще не быть.
  • +4
    Пока читал, создалось впечатление, что нормальных программистов, как типа, нет :)
    • +1
      Нормальные программисты вне этой классификации. Как сферические кони в вакууме.
      • +1
        Нормальные программисты, как уже было сказано, находятся посередине между озвученными крайностями.
        • 0
          в разный момент в разной роли
  • 0
    Блин, я мутант, в разные периоды моей жизни на разных проектах во мне были качества практически от каждого типа, разве что кроме псевдокодера)) Как с этим теперь жить?
    • 0
      Радоваться. Вы — сбалансированный профессионал. Если, конечно, разные стороны в вас проявлялись в подходящие моменты.
  • 0
    «Всякая классификация хромает» ©

    Вообще, не очень удачно разделены группы. Поведение 2, 3, 4, 6, как правило, вызваны одной и той же чертой характера, поэтому почти всегда проявляются одновременно. То же самое можно сказать про пару 5, 7. Только первый и последний пункты стоят особняком.

    Увы, скорее вынужден отнести себя к первой группе.
    • 0
      Не согласен. Про себя могу сказать, что во мне больше всего 2 (увы, борюсь с этим всю жизнь), 6 нет вообще, так как люблю изучитьтехнологию до тонкости прежде, чем применять и не люблю новые, незнакомые подходы — всегда воспринимаю их с недоверием. Перфекционизм во мне развит довольно слабо, код переписываю только когда (если) перестаю в нем ориентироваться из-за запутанности.
  • 0
    В начале проекта — 1, если остается время — 3
    До некоторых проектов пункт №3 не добрался
  • +1
    Знаю еще три типа:

    9. Мастер-ломастер (в некотором смысле, крайний вариант агента 007). Абсолютно, всегда и безоговорочно считает, что он знает все, является истиной в последней инстанции и что его решение не просто самое, но единственно верное. При этом почти всегда применяет теоретические знания совершенно не к месту, «поперёк», в результате чего его решения обычно ломают систему, например по-памяти или по-времени работы. Никогда не делает выводов из своих ошибок, говоря «это не я неправильно сыграл, это все вы неправильно спели!» Умудряется за короткое время настроить против себя всех адекватных программистов, потому что постоянно открыто и резко говорит, что те делают «всё неправильно!». Обычно недолго остается в компании, но новую находит довольно легко, так как на собеседовании может свободно говорить на абстрактно-программисткие темы, не привязаные к реальным задачам.

    10. Недоразумение (крайний вариант копи-пастера). Чел, попавший в программисты по недоразумению. Недоразумением остается и причина, по которой его приняли на фирму (родственник начальника?). Не знает базовых вещей и врядли узнает, потому что его мозги вообще не приспособлены для программирования. На работе искренне мучается каждый день и каждый час. Очень стыдится и боится того, что другие могут понять, что он вообще ничего не знает, но ему невдомек, что все другие давно уже это поняли. Но не уходит, предпочитая стоять «на краю пропасти», потому что хуже увольнения ничего не будет.

    11. Страшила мудрый. Это больше к архитекторам или тем, кто делает дизайн системы/модуля. Был лучшим в универе, может бесконечно рассуждать про классовые диаграммы, паттерны, алгоритмы, теоремы и прочее, но слабовато знает, как это все работает на практике. Делает любой дизайн с расчетом на сто лет вперед, с максимальной гибкостью и возможностью адаптировать буквально ко всему. В результате дизайн становится просто неподъемным и рушится под своим собственным весом. Хорошо, если продукт рушится сразу. Плохо, если работает, покряхтывая от напряжения, потому что тогда он успевает наворотить столько, что приходится потом годами вычищать системы от его «гибкостей» и «степеней свободы»,
    • 0
      Знаю 11, но только «Был лучшим в универе» не про него.
      12. Динозавр — думает что знает всё про продукты версии на рубеже века и упорно применяет эти знания на актуальной версии.
  • 0
    Я господин перфекционист-эксперементатор 90%. Как лечить?
    • 0
      Как понимаю — гильотина это вариант неприемлемый…
    • 0
      Обычно хорошо лечится бабками. Точнее, их недаванием, если сорваны сроки. :)
      • 0
        Тогда сроки могут стать дооооолгими. Да и 90% — это почти рабочее, отсутствие 10% не сразу и заметно.
  • 0
    Еще есть «перфекцехуист» — это когда изначально хочешь сделать идеально… но и так сойдет.
  • 0
    Может загрузить все ваши секретные API-ключи в ваш опенсорсный проект на Github, потому что это самое быстрое и простое решение.

    Кроме шуток, один мой знакомый однажды так и сделал.
    Обернулось взломом проекта :)
    Правда, ничего особо серьёзного не было, но этот случай ему припоминается до сих пор.
  • 0
    Я — Мистер 90 процентов в напряженных ситуациях, но внутренний перфекционист никогда не оставляет в покое.
  • 0
    Настоящий мистер 90%. Теперь буду знать с кем мне работать надо :)
  • 0
    Странно. Ни в одну категорию не попал. Видимо, я уже не программист. :-D
  • 0
    аффтар! все отлично! Погляди как все вокруг начали оправдываться -)
  • 0
    Может быть я один такой странный, но первые 7 пунктов про меня.
    В разных ситуациях и проектах подходят различные пункты.
  • 0
    Агент 007, только постоянно форматирую отступы. И очень часто многовато думаю о том, вынести этот кусок кода в лямбду или функцию или оставить, потому что вроде только один раз копипастить придется. Но последнее время вроде всегда выношу.

    А вообще список кажется довольно странным. Если последних 6 много, то индустрии наверное должно быть плохо.
    • 0
      Тоже практикую вынос кусков кода в лямбду или функцию
      почему в лямбду в ряде случаев (а не в просто приватную функцию) — когда что этот кусок кода актуален только в контексте данного метода, и отдельная функция только нагружала бы класс объемом кода.

      Выносить в любом случае нужно:
      1. Вы можете сразу не знать, будет вызываться код в одном месте или нескольких.
      2. Удобно и наглядно, когда вызывается некий кусок кода по «имени» — т.е., видно, что мы делаем, а как — см. детали реализации в функции/лямбде.
  • 0
    Тип 9 (или подтип): Переписать все с «нуля». )
  • 0
    По моим наблюдениям, самые популярные подходы в индустрии — 5 и 7, что считаю крайне печальным.
  • 0
    Я бы еще добавила такой тип программиста — как «учитель» или что-то типа того. Такой тип начинает учить других и этому уделяет больше времени, чем программированию :))
    • 0
      Это просто тим-лид или преподаватель в каком-нибудь учебном заведении. Программист, который тратит больше времени на поучения, чем программирование, вряд ли существует по-определению.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разработка