Pull to refresh

Comments 41

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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


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


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

Sign up to leave a comment.