Кент Бек (Kent Beck), легендарный разработчик ПО, создатель методологий экстремального программирования и test-driven development и автор многих книг по программированию, однажды сказал: «Я не великий программист, я просто хороший программист с замечательными привычками». Какими привычками и способностями обладают «рок-звезды» программирования?
Попробуем разобрать три популярные утверждения о «суперпрограммистах», чтобы понять, что из них — правда, а что — скорее преувеличение.
/ фото Connie CC
Одно из наиболее популярных мнений о супер-разработчиках — они умеют в нужный момент дать нестандартное решение проблемы. Такие решения обычно лежат в основе многих историй успеха, связанных с разработкой.
Одной из них делится резидент 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-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:
Попробуем разобрать три популярные утверждения о «суперпрограммистах», чтобы понять, что из них — правда, а что — скорее преувеличение.
/ фото 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:
AlexZaharow
Я размышлял на эту тему достаточно долго и пришёл к странному выводу. Сам по себе поиск этой способности ошибочен. Её не надо искать. Она в вас была изначально, когда вы входили в профессию, но теперь она утрачена.
Поясню. Изначально вы ничего не знали об информатике/электронике/программировании/другое и с удовольствием глотали волшебные заклинания, чтобы разобраться в работе, постепенно утрачивая способность видеть задачу целиком, а не в виде декомпозиции на отдельные части с принципами работы. Погружение в профессию оказывает вам медвежью услугу.
Поэтому я бы посоветовал просто почаще вспоминать ощущения, когда вы ещё были очень слабы в предмете и на всё глядели свежим взглядом.
Neikist
Не соглашусь, по крайней мере по моим наблюдениям раньше как раз видел только детали и «магию», а сейчас более широко могу видеть, поднимаясь на более высокие уровни абстракции.
AlexZaharow
Ну так в статье речь не про то, что c увеличением опыта можно подняться на другие уровни абстракции (это вроде как очевидно), а когда вы выбрали досуха весь «стек» ваших абстракций, но это не помогает решить задачу и нужно выйти за свои «какие-то пределы».
P.S.
Не каждая задача требует выхода за пределы своих возможностей. Для «обычных» задач опыт, естественно, очень сильно помогает.
sshmakov
Теперь, когда я овладел языком воды и до мельчайшей черточки, как азбуку, усвоил каждую мелочь на берегах великой реки, я приобрел очень много ценного. Но в то же время я утратил что-то. То, чего уже никогда в жизни не вернешь. Вся прелесть, вся красота и поэзия величавой реки исчезли! Мне до сих пор вспоминается изумительный закат, который я наблюдал, когда плавание на пароходе было для меня внове. Огромная пелена реки превратилась в кровь; в середине багрянец переходил в золото, и в этом золоте медленно плыло одинокое бревно, черное и отчетливо видное. В одном месте длинная сверкающая полоса перерезывала реку; в другом — изломами дрожала и трепетала на поверхности рябь, переливаясь, как опалы; там, где ослабевал багрянец, — возникала зеркальная водная гладь, сплошь испещренная тончайшими спиралями и искусно наведенной штриховкой; густой лес темнел на левом берегу, и его черную тень прорезала серебряной лентой длинная волнистая черта, а высоко над лесной стеною сухой ствол дерева вздымал единственную зеленую ветвь, пламеневшую в неудержимых лучах заходящего солнца. Мимо меня скользили живописнейшие повороты, отражения, лесистые холмы, заманчивые дали, — и все это залито было угасающим огнем заката, ежеминутно являвшего новые чудеса оттенков и красок.
Я стоял как заколдованный. Я созерцал эту картину в безмолвном восхищении. Мир был для меня нов, и ничего похожего я дома не видел. Но, как я уже сказал, наступил день, когда я стал меньше замечать красоту и очарование, которые луна, солнце и сумерки придавали реке. Наконец и тот день пришел, когда я уже совершенно перестал замечать все это. Повторись тот закат — я смотрел бы на него без всякого восхищения и, вероятно, комментировал бы его про себя следующим образом: «По солнцу видно, что завтра будет ветер; плывущее бревно означает, что река поднимается, и это не очень приятно; та блестящая полоса указывает на скрытый под водой каменистый порог, о который чье-нибудь судно разобьется ночью, если он будет так сильно выступать; эти трепещущие „зайчики“ показывают, что мель размыло и меняется фарватер, а черточки и круги там, на гладкой поверхности, — что этот неприятный участок реки опасно мелеет. Серебряная лента, перерезающая тень от прибрежного леса, — просто след от новой подводной коряги, которая нашла себе самое подходящее место, чтобы подлавливать пароходы; сухое дерево с единственной живой веткой простоит недолго, а как тогда человеку провести здесь судно без этой старой знакомой вехи?»
AlexZaharow
jorgen
Мне кажется, «выйти из коробки» — легко. Надо просто смотреть на проблему под разными углами. С точки зрения заказчика, вселенной, процессора, провода… Утрирую, конечно, но примерно так.
Про 10х. Тут скорее по другому. «Звёзды» не пишут код в 10 раз больше или безбажнее. Просто их (наши :) ) решения иногда (!) дают выхлоп для бизнеса х10. А иногда х100.
Idot
Согласен!
Количество кода 10x — симптом write-only говнокодера.
vyatsek
Согласен с автором поста, выше .
«Супер разработчик» решает проблему простым способом и не придумывает тонны костылей.Именно в это и сокрыта это преимущество. Простой код требует меньше времени на саппорт, поиск дефектов и понимание.
Druu
> «Супер разработчик» решает проблему простым способом и не придумывает тонны костылей.
Именно в это и сокрыта это преимущество.
Чтобы рассуждать, в чем сокрыто преимущество, надо сначала доказать, что преимущество есть. Иначе это классический поиск черной кошки в черной комнате.
NikRag
Факт существования программистов разного уровня доказывает наличие преимущества некоторых из них. Атропный принцип.
Druu
> Факт существования программистов разного уровня доказывает наличие преимущества некоторых из них.
Факт наличия кошек разного цвета доказывает наличие преимущества некоторых из них?
Очевидно, что это чушь.
Ну и речь скорее не о самом факте наличия преимущества, а о величине — мы обсуждаем «в разы», напоминаю.
suppa-duppa
— В чем секрет успеха?
— Я прочитал Джавакор до конца.
— Все прочитали.
— А, я еще с начальников бухал.
Jon7
"выйти из коробки" это тренируемый навык. Я участвовал в подобных тренингах.
Ничего там особенного нет, психолог даёт разнообразные задачи, решить которые можно только пересекая границы. Некоторые задачи совсем простые, некоторые можно сделать только в группе.
Там важно расслабиться, не концентрироваться на поиске решений привычным образом, освободить место для творческого подхода, как бы отстраниться, не грузить мозг, держать его лёгким. И так несколько раз подряд.
lxsmkv
а есть разница, когда ты на тренировке знаешь, что нужно искать альтернативный подход, и в жизни когда ты можешь и не подозревать что его нужно искать в этом месте, потому что якобы «ну это всегда и везде так делается»?
Jon7
Разница несомненно есть, только тебе об этом не говорят и психолог кандидат наук, своё дело знает. Там разнообразные вещи были, смесь задач, например тебя связывают веревкой и ты должен найти способ выпутаться, оказывают давление сокращая время до минимума, ставят 3 задачи одновременно, ставят в неравные условия и т.д. и т.п. в течение 6-7 часов.
Это потом, на разборе ошибок, тебе показывают что это было и над чем, над каким именно навыком в каком случае была работа. Все это включено в серии деловых игр, нужно набрать определённое количество баллов, конкурентная среда ошибок не прощает.
380365
HSerg
По моим наблюдениям (последние 15+ лет) — 10x более чем реальны. Но не на типовых задачках, т.к. для них важна только скорость набора текста.
P.S. Был опыт работы с интересным backend-разработчиком — он заранее продумывал алгоритмы, а потом генерил тысячи строк со скоростью хорошей машинистки (почти не глядя в экран). Обратная сторона — debug-ом почти не пользовался, а удалял и писал заново. Код получался далёким от лаконичности, но дефекты встречались очень редко.
algotrader2013
на типовых те же 10х вполне возможны. Выбрав правильный инструмент, обобщив нужные сущности, и, если надо, написав кодогенератор, можно и большего прироста достичь. Конечно, если есть определенная свобода.
HSerg
Если возникла впервые, то она ещё не типовая. А после разбора — уже вся команда решает её с одинаково максимальной эффективностью (с поправкой на скорость набора и мышеклики).
380365
Разглядывание пазов (в смысле «дыр») ещё могу себе представить… Что имелось в виду-то?
third112
М.б. здесь опечатка: разгадывание пазЛов?
cuwHuk
Именно эту задачу и должен решить код. Если реализуется сразу то, что надо, то 1) клиент доволен 2) не тратятся время и деньги на переделывание работы.
BUY33
пазлов)
dom3d
Очень хорошие программисты с удовольствием помогают коллегам.
А засранцы помогают коллегам только при условии что об этом попросит начальник.
samodum
Что такое «очень хорошие программисты»?
dom3d
Хороший вопрос. Нужно подумать.
Но навскидку.
Хороший программист может дать эстимейт и не ошибиться при этом в 10 раз.
А Очень Хороший Программист может так спроектировать систему (фреймворк), что ее не нужно будет переделывать после реализации. Такие люди — на вес золота. Это бриллианты среди программистов.
Кстати Хакер — это программист, который может сделать игру за один день.
algotrader2013
а своровать исходники игры с закрытым кодом тоже в зачет?)
dom3d
А воровать и врать не хорошо.
Не зачет.
vladob
Есть генетика, которая определяет способности «от природы», есть «история жизни», определяющая опыт конкретного индивида, есть «окружающая среда» (environment, кстати, со своей историей). Прикинем функции для каждой из групп переменных, поинтегрируем по времени, поинтегрируем по ансамблю…
Ну и что, то не все они гладкие, или случайные, многомерные, с разрывами и неопределенностью если вообще известно о них хоть что-нить…
В общем, чо на чо влияет, тренируемо ли (если потенциал не исчерпан), или индивид уже давно работает выше своего потолка… Вопросы, вопросы…
Сплошная стохастика, по-моему.
40 лет назад на термехе (который по Л. и Л.) услышал, что задача двух тел решена давно в общем виде. А вот задача трех и более тел не решена (была) и то ли доказано, то ли просто есть сомнения, что она решаема в принципе.
dipsy
Ptolemy_master
Вставлю свои пять копеек. Думаю, что «умение выйти из коробки» — вполне тренируемый навык, так же, как, например, навык решать олимпиадные задачи. Сначала вы скованы своими представлениями о том, как надо их решать, но постепенно, знакомясь с большыми количеством разных подходов, вы начинаете искать свои, и таким образом, способны рассматривать задачи под совершенно разными углами.
Но есть одно «но». Вот честно, положа руку на сердце, часто ли нам, программистам, приходится решать задачи, которые требуют выглянуть из коробки? К сожалению, очень редко. Вот поэтому этот навык также постепенно утрачивается (у тех, у кого он был как-то развит), либо не развивается (у большинства). Чтобы его поддерживать, надо решать много разных, нестандартных задач. У большей части программистов таких задач просто нет.
FyvaOldj
В десять не в десять.
Но раз пять — бывает и не редкость.
А учитывая что зарплата при этом различается раза в три то более эффективные программисты все равно раз в восемь более выгодны.
FyvaOldj
Сие достигается не просто более быстрой кодогенирацией а и правильно заложенными сразу абстракциями которые экономить время вскоре начинают.
HSerg
Пока ещё нигде не встречал, чтобы даже в два раза отличалась (если речь про зарплаты senior). Обычно 20-50%.