Две правды, одна ложь: популярные концепции о «выдающихся программистах»

    Кент Бек (Kent Beck), легендарный разработчик ПО, создатель методологий экстремального программирования и test-driven development и автор многих книг по программированию, однажды сказал: «Я не великий программист, я просто хороший программист с замечательными привычками». Какими привычками и способностями обладают «рок-звезды» программирования?

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


    / фото Connie CC

    Thinking outside of the box


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

    Одной из них делится резидент Quora и программист Питер Блэйн (Peter Blain). Он рассказывает, что в одной из сложных ситуаций работающее решение для «вставшего в тупик» проекта внезапно предложил новый разработчик, у которого был минимум времени на то, чтобы ознакомиться с задачей.

    Его подход касался не столько реализации, сколько архитектуры: он позволил локализовать проблему и для ее решения объединить сразу несколько open-source продуктов. Разумеется, это предложение не было спонтанным — тем не менее, свою роль в решении проблемы сыграл не только опыт и исключительные способности, но и свежий взгляд нового в проекте человека. По словам Питера, умение выйти за рамки традиционных подходов позволяет разработчику выйти на новый уровень — и буквально превратиться из «просто хорошего программиста» в «гроссмейстера».

    Кстати, теме Thinking outside of the box на Quora посвящено более 700 вопросов — и большинство из топик-стартеров хотят понять, как развить в себе эту способность. Ответы оказываются самыми разными — от советов делать регулярные перерывы и физические упражнения до предложений решать головоломки и читать книги по направлениям, смежным (или вообще не связанным) с вашей текущей деятельностью. Более системный подход к изучению этого явления применительно к программистам применили ученые из Вашингтонского университета совместно с представителями компании Microsoft.

    Они провели исследование, пытаясь выяснить, что отличает выдающегося программиста от просто «хорошего». Оказалось, что опрошенные ими разработчики отметили характеристику, которая по описанию соответствует пресловутому «outside of the box». Они назвали ее умением «видеть и лес, и деревья» — то есть рассматривать ситуацию на четырех разных уровнях абстракции, включая технические нюансы, индустриальные тренды, видение компании и потребности клиента.

    Разумеется, такой подход не даст внезапных гениальных озарений, но здравая оценка ситуации и ответы на вопросы: «Что действительно хочет получить клиент?», «Есть ли у этой технологии будущее, или она скоро уйдет с рынка?», «Соответствует ли это решение ценностям нашей компании?» могут дать лучший результат, нежели ежедневное разгадывание паззлов.

    Этот подход, как минимум, позволяет утверждать, что способность «видеть и лес, и деревья», можно развить — 59 интервью с представителями 13 подразделений Microsoft служат тому доказательством.

    Коллективный разум


    Еще одна важная черта выдающегося программиста, которую отметили исследователи из Вашингтона, — умение попросить помощи в нужный момент и помочь другим. Боб Мартин (Robert C. Martin) в своей книге «Идеальный программист. Как стать профессионалом разработки ПО» делает в этом отношении еще более сильное заявление: он пишет, что программировать настолько сложно, что ни один человек не может сделать это хорошо в одиночку. Даже если вы очень опытный разработчик, мысли и идеи вашего коллеги наверняка принесут вам пользу.

    Возможно, это звучит банально, но этот пункт — еще одна важная составляющая успеха. В конце концов, существует огромное количество ресурсов (включая тот же Хабр), где разработчики всячески поощряют друг друга делиться опытом и с удовольствием придут на помощь не только коллеге по проекту.

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

    Некоторые программисты считают умение правильно задавать вопросы и давать грамотные ответы особым искусством. Еще один разработчик на Ruby Стивен Хирлстон (Steven Hirlston) отмечает, что одни из главных вещей, которые он вынес за время работы, заключаются в следующем: хороший программист знает как задавать вопросы, не раздражая окружающих, а выдающийся программист знает как отвечать на них без заносчивости.

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

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

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

    А впоследствии Джефф Этвуд, один из создателей StackOverflow, так выразил ее в своем блоге:
    «Не будьте «тем парнем». Не будьте парнем, который пишет код в темном офисе и появляется на людях только когда ему надо купить колы. «Того парня» никто ни знает, никто не видит, и ему нет места в коллективе, где все открыты и готовы друг другу помочь».

    10х programming


    Одна из наиболее старых (и живучих) концепций о «звездах» разработки ПО заключается в том, что супер-разработчики продуктивнее обычных не на какие-нибудь 10-15%, а в разы — точнее, в 10 раз. Попробуем разобраться, как появилась эта идея и что стоит и за этим утверждением.

    Стив Макконнелл (Steve McConnell), генеральный директор и ведущий разработчик компании Construx Software и автор многих известных книг, в своей статье об истоках 10x рассказывает о следующем. В конце шестидесятых исследователи Сэкмен, Эриксон и Грант (Sackman, Erikson, Grant) провели первую попытку анализа производительности профессиональных программистов (в исследовании приняли участие разработчики, средний стаж работы которых составлял порядка 7 лет).

    Результаты показали, что разница во времени написания кода между лучшими и худшими результатами составила 20 к 1, разница времени отладки — 25 к 1, разница в длине кода между «худшими» и «лучшими» составляла 5 к 1, а скорость выполнения программ — 10 к 1. При этом они не обнаружили связи между опытностью программиста и качеством его кода.

    Выглядит внушительно. С другой стороны, как справедливо отмечает разработчик из Autodesk Ашрафул Алам (Ashraful Alam), софт, создававшийся в те годы, был гораздо проще тех продуктов, которые создают сейчас.

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

    В октябре этого года компания Belitsoft PHP development опросила «рок-звезд» программирования (то есть, потенциальных 10х-программистов) — в компании хотели узнать, что позволяет им работать в 10 раз лучше остальных. Оказалось, что далеко не все из опрошенных суперразработчиков считают свои способности настолько выдающимися.

    Например, Виктор Фолькман (Victor Volkman), ведущий разработчик компании ProQuest, считает, что десятикратная разница между продуктивностью двух программистов — большое преувеличение: в конце концов, объем программы далеко не всегда коррелирует с ее качеством. Поэтому успех проекта гораздо чаще зависит не от скорости написания кода, а от умения находить простые и элегантные решения проблем — а это отследить и замерить гораздо сложнее.

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

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



    P.S. О чем еще мы пишем в Первом блоге о корпоративном IaaS:

    ИТ-ГРАД 203,74
    vmware iaas provider
    Поделиться публикацией
    Комментарии 41
    • +2
      умение выйти за рамки традиционных подходов позволяет разработчику выйти на новый уровень
      и большинство из топик-стартеров хотят понять, как развить в себе эту способность

      Я размышлял на эту тему достаточно долго и пришёл к странному выводу. Сам по себе поиск этой способности ошибочен. Её не надо искать. Она в вас была изначально, когда вы входили в профессию, но теперь она утрачена.
      Поясню. Изначально вы ничего не знали об информатике/электронике/программировании/другое и с удовольствием глотали волшебные заклинания, чтобы разобраться в работе, постепенно утрачивая способность видеть задачу целиком, а не в виде декомпозиции на отдельные части с принципами работы. Погружение в профессию оказывает вам медвежью услугу.
      Поэтому я бы посоветовал просто почаще вспоминать ощущения, когда вы ещё были очень слабы в предмете и на всё глядели свежим взглядом.
      • +7
        Не соглашусь, по крайней мере по моим наблюдениям раньше как раз видел только детали и «магию», а сейчас более широко могу видеть, поднимаясь на более высокие уровни абстракции.
        • +1
          Ну так в статье речь не про то, что c увеличением опыта можно подняться на другие уровни абстракции (это вроде как очевидно), а когда вы выбрали досуха весь «стек» ваших абстракций, но это не помогает решить задачу и нужно выйти за свои «какие-то пределы».
          P.S.
          Не каждая задача требует выхода за пределы своих возможностей. Для «обычных» задач опыт, естественно, очень сильно помогает.
          • 0
            Позвольте добавлю. Задача, которая предполагает выход за пределы своих возможностей, называется сверхзадачей. У сверхзадачи иная логика. Все задачи в ней служат только сверхзадаче. Сверхзадача не обслуживает технологии, заказчиков, людей с их бесконечно растущими проблемами и желаниями и т.п. Наоборот все технологии, стеки, люди и заказчики служат сверхзадаче. Если нет сверхзадаче, то никакие задачи не интересны на серьезную перспективу.
            • 0
              Если нет сверхзадаче, то никакие задачи не интересны на серьезную перспективу
              В основном нужны ведь не задачи, а решения ))) Накидать проблем можно на раз-два.
              • 0
                Накидать «проблем» вы не сможете, как говорите, на раз-два в условиях и состояниях своих задач, иначе будете как Марфа, печься о многом, сначала о задачах, потом о проблемах, которые накидаете. Было бы так, не стоял бы вопрос «выхода из коробки». В среде практикующих «выход за пределы» или «из коробки», есть такое решение: если задача не решается, усложни задачу. Как это работает никто не знает, но работает и мудрости сей простой уж не счесть веков.
                • 0
                  Поправил немного, тонкий вопрос. «Накидать проблем» вы не сможете, как говорите, на раз-два, так как вы уже в условиях и состояниях своих задач, а они не решаются, или решаются горизонтально. То есть вы как Марфа, печетесь о многом, сначала о задачах, потом о проблемах и так по кругу. Поэтому на вопрос «выхода из коробки» в среде практикующих есть такое решение: если задача не решается, необходимо усложнить задачу. Как это работает никто не знает, но работает и мудрости сей простой не счесть веков.
                  • 0
                    То есть вы как Марфа, печетесь о многом, сначала о задачах, потом о проблемах и так по кругу
                    Я не вижу в этом ничего плохого. У каждого человека должны быть внутренние стопоры как в отношении делания, так и в отношении неделания.
                    Накидать проблем...
                    Всё-таки программный продукт имеет много качеств, которым надо удовлетворять — цена своего качества, цена сложности поддержки в будущем и в итоге само кодирование занимает небольшое количество времени по отношению к общему решению. Многие проблемы существуют ещё до начала написания кода. Просто вначале профессии не задумываешься об этом. Отсюда и куча холиваров, когда дискуссия превращается… превращается дискуссия… Поэтому и решения надо разделять на программные и «кодированные». (Если решение работает, какие могут быть к нему претензии? «Ты плохо спрограммировал!» — да плевать, когда работает. Если закодировано «плохо», то вопрос к менеджеру, т.к. он не описал, что значит «хорошо», чтобы кодировщик мог сам себя контролировать)

                    Мне в последнее время кажется, что надо разделить «программистов» на две части — кодировщиков и собственно программистов. Всё-таки странно называть одинаковым названием людей, квалификация которых зависит от языка. Знаешь JavaScript — программист. А кто не знает — не программист? А если можешь решить задачу на C# и не можешь тоже самое сделать на Java? Поэтому написать «выдающийся» кодировщик будет уместнее, т.к. он знает хитрости реализации конкретного решения на соответствующем языке (а иногда и в соответствующей виртуальной машине языка). В то время как программист не зависит от языка программирования и он принципиально решает задачу и ему тонкости языка не важны. Поэтому среди программистов будут свои выдающиеся люди, но уже с другими способностями.

                    Отсюда вполне логично, что можно выходить из коробки в области кодирования, а можно выходить из коробки в области программирования. И поэтому в дискуссиях на тему «эффективности» нужно видеть грань между кодированием и программированием и не предъявлять каждой из этих областей требований из другой. Именно таким образом можно избежать «накидать проблем».
          • 0
            Погружение в профессию оказывает вам медвежью услугу.
            Аналогичный случай был на Миссисиппи и описан Марк Твеном.

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

            Теперь, когда я овладел языком воды и до мельчайшей черточки, как азбуку, усвоил каждую мелочь на берегах великой реки, я приобрел очень много ценного. Но в то же время я утратил что-то. То, чего уже никогда в жизни не вернешь. Вся прелесть, вся красота и поэзия величавой реки исчезли! Мне до сих пор вспоминается изумительный закат, который я наблюдал, когда плавание на пароходе было для меня внове. Огромная пелена реки превратилась в кровь; в середине багрянец переходил в золото, и в этом золоте медленно плыло одинокое бревно, черное и отчетливо видное. В одном месте длинная сверкающая полоса перерезывала реку; в другом — изломами дрожала и трепетала на поверхности рябь, переливаясь, как опалы; там, где ослабевал багрянец, — возникала зеркальная водная гладь, сплошь испещренная тончайшими спиралями и искусно наведенной штриховкой; густой лес темнел на левом берегу, и его черную тень прорезала серебряной лентой длинная волнистая черта, а высоко над лесной стеною сухой ствол дерева вздымал единственную зеленую ветвь, пламеневшую в неудержимых лучах заходящего солнца. Мимо меня скользили живописнейшие повороты, отражения, лесистые холмы, заманчивые дали, — и все это залито было угасающим огнем заката, ежеминутно являвшего новые чудеса оттенков и красок.

            Я стоял как заколдованный. Я созерцал эту картину в безмолвном восхищении. Мир был для меня нов, и ничего похожего я дома не видел. Но, как я уже сказал, наступил день, когда я стал меньше замечать красоту и очарование, которые луна, солнце и сумерки придавали реке. Наконец и тот день пришел, когда я уже совершенно перестал замечать все это. Повторись тот закат — я смотрел бы на него без всякого восхищения и, вероятно, комментировал бы его про себя следующим образом: «По солнцу видно, что завтра будет ветер; плывущее бревно означает, что река поднимается, и это не очень приятно; та блестящая полоса указывает на скрытый под водой каменистый порог, о который чье-нибудь судно разобьется ночью, если он будет так сильно выступать; эти трепещущие „зайчики“ показывают, что мель размыло и меняется фарватер, а черточки и круги там, на гладкой поверхности, — что этот неприятный участок реки опасно мелеет. Серебряная лента, перерезающая тень от прибрежного леса, — просто след от новой подводной коряги, которая нашла себе самое подходящее место, чтобы подлавливать пароходы; сухое дерево с единственной живой веткой простоит недолго, а как тогда человеку провести здесь судно без этой старой знакомой вехи?»


            Нет, романтика и красота реки положительно исчезли. Каждую примету я рассматривал только как средство благополучно провести судно. С тех пор я от всего сердца жалею докторов. Что для врача нежный румянец на щеках красавицы — как не «рябь», играющая над смертельным недугом? Разве он не видит за внешней прелестью признаков тайного разложения? Да и видит ли он вообще эту прелесть? Не разглядывает ли он красавицу с узко профессиональной точки зрения, мысленно комментируя болезненные симптомы?

            И не раздумывает ли он иногда о том, выиграл ли он, или проиграл, изучив свою профессию?
            • 0
              И не раздумывает ли он иногда о том, выиграл ли он, или проиграл, изучив свою профессию?
              Не читал Марка Твена, но одобряю, хотя мне кажется, что он не до конца раскрыл тему. Описание заканчивается на том, что вроде как профессия освоена и что же делать дальше? Лично я вижу два варианта — первый, можно просто и незатейливо передавать знания и второй — двигать профессию дальше. Но для этого надо выйти за привычные «рамки». Вопрос — а какие рамки? Вот тут как раз у него и нет ответа. А жаль. Могу пока только предположить, что каждый выходит за рамки по своему.
          • +3
            Мне кажется, «выйти из коробки» — легко. Надо просто смотреть на проблему под разными углами. С точки зрения заказчика, вселенной, процессора, провода… Утрирую, конечно, но примерно так.

            Про 10х. Тут скорее по другому. «Звёзды» не пишут код в 10 раз больше или безбажнее. Просто их (наши :) ) решения иногда (!) дают выхлоп для бизнеса х10. А иногда х100.
            • 0

              Согласен!
              Количество кода 10x — симптом write-only говнокодера.

            • +8
              Согласен с автором поста, выше .
              Одна из наиболее старых (и живучих) концепций о «звездах» разработки ПО заключается в том, что супер-разработчики продуктивнее обычных не на какие-нибудь 10-15%, а в разы — точнее, в 10 раз. Попробуем разобраться, как появилась эта идея и что стоит и за этим утверждением.
              «Супер разработчик» решает проблему простым способом и не придумывает тонны костылей.
              Именно в это и сокрыта это преимущество. Простой код требует меньше времени на саппорт, поиск дефектов и понимание.
              • +1
                > «Супер разработчик» решает проблему простым способом и не придумывает тонны костылей.
                Именно в это и сокрыта это преимущество.

                Чтобы рассуждать, в чем сокрыто преимущество, надо сначала доказать, что преимущество есть. Иначе это классический поиск черной кошки в черной комнате.
                • 0
                  Факт существования программистов разного уровня доказывает наличие преимущества некоторых из них. Атропный принцип.
                  • –1
                    > Факт существования программистов разного уровня доказывает наличие преимущества некоторых из них.

                    Факт наличия кошек разного цвета доказывает наличие преимущества некоторых из них?
                    Очевидно, что это чушь.

                    Ну и речь скорее не о самом факте наличия преимущества, а о величине — мы обсуждаем «в разы», напоминаю.
              • 0
                — В чем секрет успеха?
                — Я прочитал Джавакор до конца.
                — Все прочитали.
                — А, я еще с начальников бухал.
                • 0

                  "выйти из коробки" это тренируемый навык. Я участвовал в подобных тренингах.
                  Ничего там особенного нет, психолог даёт разнообразные задачи, решить которые можно только пересекая границы. Некоторые задачи совсем простые, некоторые можно сделать только в группе.
                  Там важно расслабиться, не концентрироваться на поиске решений привычным образом, освободить место для творческого подхода, как бы отстраниться, не грузить мозг, держать его лёгким. И так несколько раз подряд.

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

                      Разница несомненно есть, только тебе об этом не говорят и психолог кандидат наук, своё дело знает. Там разнообразные вещи были, смесь задач, например тебя связывают веревкой и ты должен найти способ выпутаться, оказывают давление сокращая время до минимума, ставят 3 задачи одновременно, ставят в неравные условия и т.д. и т.п. в течение 6-7 часов.
                      Это потом, на разборе ошибок, тебе показывают что это было и над чем, над каким именно навыком в каком случае была работа. Все это включено в серии деловых игр, нужно набрать определённое количество баллов, конкурентная среда ошибок не прощает.

                    • 0
                      Там важно расслабиться, не концентрироваться на поиске решений привычным образом, освободить место для творческого подхода, как бы отстраниться…
                      То есть
                      просто почаще вспоминать ощущения, когда вы ещё были очень слабы в предмете и на всё глядели свежим взглядом
                      — (с) AlexZaharow
                    • +1

                      По моим наблюдениям (последние 15+ лет) — 10x более чем реальны. Но не на типовых задачках, т.к. для них важна только скорость набора текста.


                      P.S. Был опыт работы с интересным backend-разработчиком — он заранее продумывал алгоритмы, а потом генерил тысячи строк со скоростью хорошей машинистки (почти не глядя в экран). Обратная сторона — debug-ом почти не пользовался, а удалял и писал заново. Код получался далёким от лаконичности, но дефекты встречались очень редко.

                      • 0
                        Но не на типовых задачках, т.к. для них важна только скорость набора текста.

                        на типовых те же 10х вполне возможны. Выбрав правильный инструмент, обобщив нужные сущности, и, если надо, написав кодогенератор, можно и большего прироста достичь. Конечно, если есть определенная свобода.
                        • 0
                          Если возникла впервые, то она ещё не типовая. А после разбора — уже вся команда решает её с одинаково максимальной эффективностью (с поправкой на скорость набора и мышеклики).
                      • 0
                        ответы на вопросы: «Что действительно хочет получить клиент?», «Есть ли у этой технологии будущее, или она скоро уйдет с рынка?», «Соответствует ли это решение ценностям нашей компании?» могут дать лучший результат
                        «Рынок», «клиент», «ценности» — как всё это связано с кодом? По-моему, здесь идёт речь о хорошем маркетологе, а не хорошем разработчике.

                        нежели ежедневное разгадывание пазов
                        Разглядывание пазов (в смысле «дыр») ещё могу себе представить… Что имелось в виду-то?
                        • +1
                          М.б. здесь опечатка: разгадывание пазЛов?
                          • 0
                            Что действительно хочет получить клиент?

                            Именно эту задачу и должен решить код. Если реализуется сразу то, что надо, то 1) клиент доволен 2) не тратятся время и деньги на переделывание работы.
                            • 0
                              пазлов)
                            • –1
                              Очень хорошие программисты с удовольствием помогают коллегам.
                              А засранцы помогают коллегам только при условии что об этом попросит начальник.
                              • 0
                                Что такое «очень хорошие программисты»?
                                • –1
                                  Хороший вопрос. Нужно подумать.

                                  Но навскидку.
                                  Хороший программист может дать эстимейт и не ошибиться при этом в 10 раз.
                                  А Очень Хороший Программист может так спроектировать систему (фреймворк), что ее не нужно будет переделывать после реализации. Такие люди — на вес золота. Это бриллианты среди программистов.
                                  Кстати Хакер — это программист, который может сделать игру за один день.
                                  • 0
                                    Кстати Хакер — это программист, который может сделать игру за один день

                                    а своровать исходники игры с закрытым кодом тоже в зачет?)
                                    • 0
                                      А воровать и врать не хорошо.
                                      Не зачет.
                              • 0
                                Есть генетика, которая определяет способности «от природы», есть «история жизни», определяющая опыт конкретного индивида, есть «окружающая среда» (environment, кстати, со своей историей). Прикинем функции для каждой из групп переменных, поинтегрируем по времени, поинтегрируем по ансамблю…
                                Ну и что, то не все они гладкие, или случайные, многомерные, с разрывами и неопределенностью если вообще известно о них хоть что-нить…

                                В общем, чо на чо влияет, тренируемо ли (если потенциал не исчерпан), или индивид уже давно работает выше своего потолка… Вопросы, вопросы…
                                Сплошная стохастика, по-моему.

                                40 лет назад на термехе (который по Л. и Л.) услышал, что задача двух тел решена давно в общем виде. А вот задача трех и более тел не решена (была) и то ли доказано, то ли просто есть сомнения, что она решаема в принципе.
                                • +1
                                  Выходит, что среди характеристик «суперпрограммистов» эта — наименее правдоподобная. В конце концов, разработчики, с бешеной скоростью пишущие непонятный код, востребованы только в кино.
                                  Смешались в кучу кони, люди… А разработчики, пишущие в разумные сроки лаконичный, покрытый тестами код, DRY, SOLID, это тоже фантастика? По своему опыту могу сказать, что да, окружающие скорее будут лихо гавнокодить простыни маловразумительных заклинаний, активно применяя паттерн «copy-and-paste», а перед дедлайном выкатят свой «продукт» с гордым «я сделяль», и он даже будет работать, в 95% случаев и при достаточно удачном положении звёзд. Будет работать до того момента, когда понадобится внести изменения или исправить баг, тут-то оно всё и посыпется… Начальство считает продуктивными именно их. А вас уволят за то, что вы «ничего не делаете», не засиживаетесь на работе во время авралов в поисках неуловимых багов, да и про ваш софт никто особо не слышит, он просто работает и не отсвечивает, времени на поддержку почти не требует, и с повышением з/п вас туда же отправят. Добро пожаловать в реальный мир.
                                  • 0
                                    Вставлю свои пять копеек. Думаю, что «умение выйти из коробки» — вполне тренируемый навык, так же, как, например, навык решать олимпиадные задачи. Сначала вы скованы своими представлениями о том, как надо их решать, но постепенно, знакомясь с большыми количеством разных подходов, вы начинаете искать свои, и таким образом, способны рассматривать задачи под совершенно разными углами.

                                    Но есть одно «но». Вот честно, положа руку на сердце, часто ли нам, программистам, приходится решать задачи, которые требуют выглянуть из коробки? К сожалению, очень редко. Вот поэтому этот навык также постепенно утрачивается (у тех, у кого он был как-то развит), либо не развивается (у большинства). Чтобы его поддерживать, надо решать много разных, нестандартных задач. У большей части программистов таких задач просто нет.
                                    • 0

                                      В десять не в десять.
                                      Но раз пять — бывает и не редкость.
                                      А учитывая что зарплата при этом различается раза в три то более эффективные программисты все равно раз в восемь более выгодны.

                                      • 0

                                        Сие достигается не просто более быстрой кодогенирацией а и правильно заложенными сразу абстракциями которые экономить время вскоре начинают.

                                        • 0
                                          Пока ещё нигде не встречал, чтобы даже в два раза отличалась (если речь про зарплаты senior). Обычно 20-50%.
                                        • 0

                                          Я видел отличия и более чем в 5 раз. 25 наверное не было, но отличия раз в 10 вполне бывают.


                                          В основном за счёт более широкого «словаря». Одни программисты лучше владеют средствами языка, бибилиотеками, паттернами, алгоритмами, приемами композиции и декомпозиции кода.


                                          Также банальный фактор фокусировки на задаче. Один быстро напишет говнокод, который таки решает проблему. Второй будет долго вылизывать архитектуру и пидарасить такты. В долгосрочной перспективе обе крайности плохие, а в краткосрочной первый даст офигенную разницу в продуктивности.

                                          • 0

                                            Дубль

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

                                            Самое читаемое