Comments 41
умение выйти за рамки традиционных подходов позволяет разработчику выйти на новый уровень
и большинство из топик-стартеров хотят понять, как развить в себе эту способность
Я размышлял на эту тему достаточно долго и пришёл к странному выводу. Сам по себе поиск этой способности ошибочен. Её не надо искать. Она в вас была изначально, когда вы входили в профессию, но теперь она утрачена.
Поясню. Изначально вы ничего не знали об информатике/электронике/программировании/другое и с удовольствием глотали волшебные заклинания, чтобы разобраться в работе, постепенно утрачивая способность видеть задачу целиком, а не в виде декомпозиции на отдельные части с принципами работы. Погружение в профессию оказывает вам медвежью услугу.
Поэтому я бы посоветовал просто почаще вспоминать ощущения, когда вы ещё были очень слабы в предмете и на всё глядели свежим взглядом.
P.S.
Не каждая задача требует выхода за пределы своих возможностей. Для «обычных» задач опыт, естественно, очень сильно помогает.
Если нет сверхзадаче, то никакие задачи не интересны на серьезную перспективуВ основном нужны ведь не задачи, а решения ))) Накидать проблем можно на раз-два.
То есть вы как Марфа, печетесь о многом, сначала о задачах, потом о проблемах и так по кругуЯ не вижу в этом ничего плохого. У каждого человека должны быть внутренние стопоры как в отношении делания, так и в отношении неделания.
Накидать проблем...Всё-таки программный продукт имеет много качеств, которым надо удовлетворять — цена своего качества, цена сложности поддержки в будущем и в итоге само кодирование занимает небольшое количество времени по отношению к общему решению. Многие проблемы существуют ещё до начала написания кода. Просто вначале профессии не задумываешься об этом. Отсюда и куча холиваров, когда дискуссия превращается… превращается дискуссия… Поэтому и решения надо разделять на программные и «кодированные». (Если решение работает, какие могут быть к нему претензии? «Ты плохо спрограммировал!» — да плевать, когда работает. Если закодировано «плохо», то вопрос к менеджеру, т.к. он не описал, что значит «хорошо», чтобы кодировщик мог сам себя контролировать)
Мне в последнее время кажется, что надо разделить «программистов» на две части — кодировщиков и собственно программистов. Всё-таки странно называть одинаковым названием людей, квалификация которых зависит от языка. Знаешь JavaScript — программист. А кто не знает — не программист? А если можешь решить задачу на C# и не можешь тоже самое сделать на Java? Поэтому написать «выдающийся» кодировщик будет уместнее, т.к. он знает хитрости реализации конкретного решения на соответствующем языке (а иногда и в соответствующей виртуальной машине языка). В то время как программист не зависит от языка программирования и он принципиально решает задачу и ему тонкости языка не важны. Поэтому среди программистов будут свои выдающиеся люди, но уже с другими способностями.
Отсюда вполне логично, что можно выходить из коробки в области кодирования, а можно выходить из коробки в области программирования. И поэтому в дискуссиях на тему «эффективности» нужно видеть грань между кодированием и программированием и не предъявлять каждой из этих областей требований из другой. Именно таким образом можно избежать «накидать проблем».
Погружение в профессию оказывает вам медвежью услугу.Аналогичный случай был на Миссисиппи и описан Марк Твеном.
Теперь, когда я овладел языком воды и до мельчайшей черточки, как азбуку, усвоил каждую мелочь на берегах великой реки, я приобрел очень много ценного. Но в то же время я утратил что-то. То, чего уже никогда в жизни не вернешь. Вся прелесть, вся красота и поэзия величавой реки исчезли! Мне до сих пор вспоминается изумительный закат, который я наблюдал, когда плавание на пароходе было для меня внове. Огромная пелена реки превратилась в кровь; в середине багрянец переходил в золото, и в этом золоте медленно плыло одинокое бревно, черное и отчетливо видное. В одном месте длинная сверкающая полоса перерезывала реку; в другом — изломами дрожала и трепетала на поверхности рябь, переливаясь, как опалы; там, где ослабевал багрянец, — возникала зеркальная водная гладь, сплошь испещренная тончайшими спиралями и искусно наведенной штриховкой; густой лес темнел на левом берегу, и его черную тень прорезала серебряной лентой длинная волнистая черта, а высоко над лесной стеною сухой ствол дерева вздымал единственную зеленую ветвь, пламеневшую в неудержимых лучах заходящего солнца. Мимо меня скользили живописнейшие повороты, отражения, лесистые холмы, заманчивые дали, — и все это залито было угасающим огнем заката, ежеминутно являвшего новые чудеса оттенков и красок.
Я стоял как заколдованный. Я созерцал эту картину в безмолвном восхищении. Мир был для меня нов, и ничего похожего я дома не видел. Но, как я уже сказал, наступил день, когда я стал меньше замечать красоту и очарование, которые луна, солнце и сумерки придавали реке. Наконец и тот день пришел, когда я уже совершенно перестал замечать все это. Повторись тот закат — я смотрел бы на него без всякого восхищения и, вероятно, комментировал бы его про себя следующим образом: «По солнцу видно, что завтра будет ветер; плывущее бревно означает, что река поднимается, и это не очень приятно; та блестящая полоса указывает на скрытый под водой каменистый порог, о который чье-нибудь судно разобьется ночью, если он будет так сильно выступать; эти трепещущие „зайчики“ показывают, что мель размыло и меняется фарватер, а черточки и круги там, на гладкой поверхности, — что этот неприятный участок реки опасно мелеет. Серебряная лента, перерезающая тень от прибрежного леса, — просто след от новой подводной коряги, которая нашла себе самое подходящее место, чтобы подлавливать пароходы; сухое дерево с единственной живой веткой простоит недолго, а как тогда человеку провести здесь судно без этой старой знакомой вехи?»
Нет, романтика и красота реки положительно исчезли. Каждую примету я рассматривал только как средство благополучно провести судно. С тех пор я от всего сердца жалею докторов. Что для врача нежный румянец на щеках красавицы — как не «рябь», играющая над смертельным недугом? Разве он не видит за внешней прелестью признаков тайного разложения? Да и видит ли он вообще эту прелесть? Не разглядывает ли он красавицу с узко профессиональной точки зрения, мысленно комментируя болезненные симптомы?
И не раздумывает ли он иногда о том, выиграл ли он, или проиграл, изучив свою профессию?
И не раздумывает ли он иногда о том, выиграл ли он, или проиграл, изучив свою профессию?Не читал Марка Твена, но одобряю, хотя мне кажется, что он не до конца раскрыл тему. Описание заканчивается на том, что вроде как профессия освоена и что же делать дальше? Лично я вижу два варианта — первый, можно просто и незатейливо передавать знания и второй — двигать профессию дальше. Но для этого надо выйти за привычные «рамки». Вопрос — а какие рамки? Вот тут как раз у него и нет ответа. А жаль. Могу пока только предположить, что каждый выходит за рамки по своему.
Про 10х. Тут скорее по другому. «Звёзды» не пишут код в 10 раз больше или безбажнее. Просто их (наши :) ) решения иногда (!) дают выхлоп для бизнеса х10. А иногда х100.
Одна из наиболее старых (и живучих) концепций о «звездах» разработки ПО заключается в том, что супер-разработчики продуктивнее обычных не на какие-нибудь 10-15%, а в разы — точнее, в 10 раз. Попробуем разобраться, как появилась эта идея и что стоит и за этим утверждением.«Супер разработчик» решает проблему простым способом и не придумывает тонны костылей.
Именно в это и сокрыта это преимущество. Простой код требует меньше времени на саппорт, поиск дефектов и понимание.
Именно в это и сокрыта это преимущество.
Чтобы рассуждать, в чем сокрыто преимущество, надо сначала доказать, что преимущество есть. Иначе это классический поиск черной кошки в черной комнате.
Факт наличия кошек разного цвета доказывает наличие преимущества некоторых из них?
Очевидно, что это чушь.
Ну и речь скорее не о самом факте наличия преимущества, а о величине — мы обсуждаем «в разы», напоминаю.
— Я прочитал Джавакор до конца.
— Все прочитали.
— А, я еще с начальников бухал.
"выйти из коробки" это тренируемый навык. Я участвовал в подобных тренингах.
Ничего там особенного нет, психолог даёт разнообразные задачи, решить которые можно только пересекая границы. Некоторые задачи совсем простые, некоторые можно сделать только в группе.
Там важно расслабиться, не концентрироваться на поиске решений привычным образом, освободить место для творческого подхода, как бы отстраниться, не грузить мозг, держать его лёгким. И так несколько раз подряд.
Разница несомненно есть, только тебе об этом не говорят и психолог кандидат наук, своё дело знает. Там разнообразные вещи были, смесь задач, например тебя связывают веревкой и ты должен найти способ выпутаться, оказывают давление сокращая время до минимума, ставят 3 задачи одновременно, ставят в неравные условия и т.д. и т.п. в течение 6-7 часов.
Это потом, на разборе ошибок, тебе показывают что это было и над чем, над каким именно навыком в каком случае была работа. Все это включено в серии деловых игр, нужно набрать определённое количество баллов, конкурентная среда ошибок не прощает.
Там важно расслабиться, не концентрироваться на поиске решений привычным образом, освободить место для творческого подхода, как бы отстраниться…То есть
просто почаще вспоминать ощущения, когда вы ещё были очень слабы в предмете и на всё глядели свежим взглядом— (с) AlexZaharow
По моим наблюдениям (последние 15+ лет) — 10x более чем реальны. Но не на типовых задачках, т.к. для них важна только скорость набора текста.
P.S. Был опыт работы с интересным backend-разработчиком — он заранее продумывал алгоритмы, а потом генерил тысячи строк со скоростью хорошей машинистки (почти не глядя в экран). Обратная сторона — debug-ом почти не пользовался, а удалял и писал заново. Код получался далёким от лаконичности, но дефекты встречались очень редко.
Но не на типовых задачках, т.к. для них важна только скорость набора текста.
на типовых те же 10х вполне возможны. Выбрав правильный инструмент, обобщив нужные сущности, и, если надо, написав кодогенератор, можно и большего прироста достичь. Конечно, если есть определенная свобода.
ответы на вопросы: «Что действительно хочет получить клиент?», «Есть ли у этой технологии будущее, или она скоро уйдет с рынка?», «Соответствует ли это решение ценностям нашей компании?» могут дать лучший результат«Рынок», «клиент», «ценности» — как всё это связано с кодом? По-моему, здесь идёт речь о хорошем маркетологе, а не хорошем разработчике.
нежели ежедневное разгадывание пазовРазглядывание пазов (в смысле «дыр») ещё могу себе представить… Что имелось в виду-то?
А засранцы помогают коллегам только при условии что об этом попросит начальник.
Но навскидку.
Хороший программист может дать эстимейт и не ошибиться при этом в 10 раз.
А Очень Хороший Программист может так спроектировать систему (фреймворк), что ее не нужно будет переделывать после реализации. Такие люди — на вес золота. Это бриллианты среди программистов.
Кстати Хакер — это программист, который может сделать игру за один день.
Ну и что, то не все они гладкие, или случайные, многомерные, с разрывами и неопределенностью если вообще известно о них хоть что-нить…
В общем, чо на чо влияет, тренируемо ли (если потенциал не исчерпан), или индивид уже давно работает выше своего потолка… Вопросы, вопросы…
Сплошная стохастика, по-моему.
40 лет назад на термехе (который по Л. и Л.) услышал, что задача двух тел решена давно в общем виде. А вот задача трех и более тел не решена (была) и то ли доказано, то ли просто есть сомнения, что она решаема в принципе.
Выходит, что среди характеристик «суперпрограммистов» эта — наименее правдоподобная. В конце концов, разработчики, с бешеной скоростью пишущие непонятный код, востребованы только в кино.Смешались в кучу кони, люди… А разработчики, пишущие в разумные сроки лаконичный, покрытый тестами код, DRY, SOLID, это тоже фантастика? По своему опыту могу сказать, что да, окружающие скорее будут лихо гавнокодить простыни маловразумительных заклинаний, активно применяя паттерн «copy-and-paste», а перед дедлайном выкатят свой «продукт» с гордым «я сделяль», и он даже будет работать, в 95% случаев и при достаточно удачном положении звёзд. Будет работать до того момента, когда понадобится внести изменения или исправить баг, тут-то оно всё и посыпется… Начальство считает продуктивными именно их. А вас уволят за то, что вы «ничего не делаете», не засиживаетесь на работе во время авралов в поисках неуловимых багов, да и про ваш софт никто особо не слышит, он просто работает и не отсвечивает, времени на поддержку почти не требует, и с повышением з/п вас туда же отправят. Добро пожаловать в реальный мир.
Но есть одно «но». Вот честно, положа руку на сердце, часто ли нам, программистам, приходится решать задачи, которые требуют выглянуть из коробки? К сожалению, очень редко. Вот поэтому этот навык также постепенно утрачивается (у тех, у кого он был как-то развит), либо не развивается (у большинства). Чтобы его поддерживать, надо решать много разных, нестандартных задач. У большей части программистов таких задач просто нет.
В десять не в десять.
Но раз пять — бывает и не редкость.
А учитывая что зарплата при этом различается раза в три то более эффективные программисты все равно раз в восемь более выгодны.
Я видел отличия и более чем в 5 раз. 25 наверное не было, но отличия раз в 10 вполне бывают.
В основном за счёт более широкого «словаря». Одни программисты лучше владеют средствами языка, бибилиотеками, паттернами, алгоритмами, приемами композиции и декомпозиции кода.
Также банальный фактор фокусировки на задаче. Один быстро напишет говнокод, который таки решает проблему. Второй будет долго вылизывать архитектуру и пидарасить такты. В долгосрочной перспективе обе крайности плохие, а в краткосрочной первый даст офигенную разницу в продуктивности.
Дубль
Две правды, одна ложь: популярные концепции о «выдающихся программистах»