Как стать автором
Обновить

Комментарии 146

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

По профессиональной — тимлид, по карьерной — менеджер.
НЛО прилетело и опубликовало эту надпись здесь
Вариантов, в целом, куча. По обеим лестницам =).
В аналитика — это не профессиональный рост, это смена рода деятельности (практически фундаментальная).
НЛО прилетело и опубликовало эту надпись здесь
Если что, вы дали ссылку на программый анализ (в смысле «анализ с помощью программ») как дисциплину, должности там нет. И я не знаю ни одного человека, который работал бы в этой области.
разработка рекомендательных систем и анализ данных, разве нет?
Во-первых, нет (почитайте статью внимательно).

А во-вторых, нет, потому что разработкой систем принятия решений занимается (сюрприз!) все тот же «разработчик», что и раньше.
НЛО прилетело и опубликовало эту надпись здесь
И что там в должностных обязанностях?
НЛО прилетело и опубликовало эту надпись здесь
По ссылке в вики же есть упоминание Software Analytics Group, там люди работают

У них, вы думаете, у всех должность «software analyst»?

В гугле такую вот вакансию нашел еще.

Прекрасная вакансия! Теперь скажите мне, каким образом это карьерный рост для программиста, если все необходимые навыки программирования в этой вакансии сводятся к «Scripting/coding ability for automation and examination of software systems»?

Плюс есть таксономисты, датаминеры

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

У нас в конторе есть датаминеры и вроде даже таксономисты, но это не разработчики, а математики и пользуются они своим отдельным инструментарием.
НЛО прилетело и опубликовало эту надпись здесь
Или может так например. Приходит клиент, говорит «хочу мышью открывать окна». И ты не крутишь пальцем у виска, а берешь и реализовываешь то, о чем раньше и не думал что это возможно.
Почему вы считаете, что тимлид — это профессиональная («техническая») лестница? У нас в компании, например, это считается «менеджерской» лестницей.
НЛО прилетело и опубликовало эту надпись здесь
В разных фирмах всё по разному.
В софтверной фирме средних размер техдиректоры вроде уже непосредственно разработкой не занимаются. В технологиях разбирается, но больше организует работу разработчиков.
Или архитектор -> СТО или начальник группы-. проекта
Я честно не понимаю минусующих. У нас принято, что после чисто технических должностей рост происходит в руководящие/обучающие должности, которые требуют совершенно других навыков, нежели программирование. И почему программист, хороший технарь, должен становиться руководителем или тренером, если ему легко программировать? Легко — это не значит скучно. Это значит, что интересно и приятно решать задачи любой сложности.
Есть мнение, что рост очень часто упирается в уровень некомпетентности.
Или уровень интеллекта.
сменить язык, область. Что угодно.
В более хардкорные программисты, на менее простые задачи. Возможно, в другую контору / на другой язык.
НЛО прилетело и опубликовало эту надпись здесь
Как история с тем американцем, который делигировал свою работу китайцам =)
Имхо, если программисту работается легко, самое время двигаться дальше.
золотые слова, программер должен расширять границы дозволенного
>>>Всё дело в том, что те способы создания программ, те методологии управления программистами и те подходы к написанию кода просто не могли дать на выходе систему столь высокой сложности, как нынешние ОС. Люди работали на пределе сил, но в итоге сделали намного более простые системы.<<<

Не вдаваясь в общую философию поста (которая, как мне кажется, несколько ставит все с ног на голову, поскольку сложна не профессия сама по себе; будет сложно или нет, определяется человеком и его любовью к делу, которым занят), замечу, что это утверждение — неверное. Достаточно почитать про операционную систему Genera (Symbolics Lisp Machines) и посмотреть видео о ней.

На самом деле все что сложно — просто, я люблю сложные задачи, а если задача действительно сложна то и «погружаешься» в нее полностью и в итоге получается (для меня) было все просто.

Только последнее время заметил что «простые» задачи начинаю сам раздувать в сложные, когда думаешь наперед, а вдруг что изменят… а вдруг нагрузка… а вдруг данных сильно больше. Из-за этого времени уходить сильно больше чем решал бы скажем года два назад.
И это пройдет.
А пройдет в какую сторону?
НЛО прилетело и опубликовало эту надпись здесь
Совершенно верно. Хотя некоторые так и застревают в этих астралах думания наперед.
Большинство задач — шаблонны и просты. Редко вкусное попадается, а жаль )
Это Вам так кажется по эту сторону, а если просто сменить работу или должность то со временем захотите сбавить обороты) Из личного опыта пример: я всю жизнь стремился к сложным задачам и ставил себе невыполнимые цели, постоянный мозговой штурм, постоянная погруженность в проект и сон по 5-6 часов, но реально с годами хочется уже сбавить обороты, просто придумать, разработать архитектуру, прототип или вообще только написать и нарисовать, а делают пусть другие, мне хватает просто подпитывать интересными задачками мозг. Только в моём случаи я сам себе хозяин, захотел сделал, думаю при работе на кого-то это был бы ощутимый скачок назад по зарплате. Так что всё относительное, это как с офисной VS выездной работой, каждый мечтает о противоположенном :)
Странно, если честно. Вы пишете довольно интересные технические статьи, поэтому трудностей с выбором интересной работы у вас быть не должно. Просто укажите в профиле хоть какой-нибудь способ связи с вами, и предложения появятся.
Интересной работы просто очень мало. За такие места люди держатся, а среди вакансий сплошная системная интеграция и корпоративщина. Среди стартапов тоже интересное поискать надо.
Не соглашусь, интересной работы достаточно, просто очень часто такие работодатели не публикуют вакансии на hh (я не знаю, почему так происходит), а просто предлагают работу авторам интересных статей или блогов.
Тогда SunexDevelopment не жаловался бы на скучные задачи :)
Про hh вообще можно забыть, если ищешь интересное место для программиста. Лучше специализированные ресурсы, вроде хантима, айтимозга.
Вы не совсем правы. Меня через HH нашла контора, которая делает суперкомпьютеры NUMA используя межпроцессорную шину AMD на обычных серверных материнках. Звали OpenBIOS пилить. Но тогда у меня уже было другое предложение и я от суперкомпьютеров отказался. Регулярно натыкаются там на моё резюме и зовут делать какие-то низкоуровневые штуки, связанные в вычислениями на видеокартах, но приходится пояснять, что это было всего лишь хобби и надо будет многому учиться :) Эйчары практически любой компании прежде всего туда идут, когда хотят найти работников в IT сфере.
приходится пояснять, что это было всего лишь хобби и надо будет многому учиться

А это их отпугивает?
Так я сам сейчас не планирую менять место работы :)
Так вопрос не про вас, а про них :)
А кто ж знает, я на собеседование не ходил, сразу давал отказ эйчарам с вот такой вот формулировкой.
В данной конкретной области не скажу, но вообще частенько отпугивает, если связываются именно эйчары, а не потенциальные непосредственные начальники или даже коллеги.

UPD: До этапа собеседования.
Наверное, низкоуровневое программирование само по себе интересно и вакансий, как и специалистов, не много. А вот в веб-разработке (и, наверное, в десктоп-) очень много треш-вакансий, среди которых сложно найти что-то хорошее.
Чисто по хабру могу сказать, что и комментариев в профильных топиках может быть достаточно.
НЛО прилетело и опубликовало эту надпись здесь
Когда легко иду сюда с новым языком Coder Charts и Project Euler
Почему вы противопоставляете «сложно» и «не включать голову»? Почему вы считаете, что в «простых» задачах голову включать не надо?

А вообще про это прекрасно сказал еще Дийкстра: computing is the only profession in which a single mind is obliged to span the distance from a bit to a few hundred megabytes, a ratio of 1 to 109, or nine orders of magnitude. А сейчас можно смело набрасывать еще порядков 7-8 как минимум (даже МакКоннел пишет о 1015, а это девять лет назад).
Пять лет назад мне казалось что программировать ооочень просто. Вот IDE, вот Java, вот Интернет, что сложного? В это время, были две попытки «научить» программированию двух моих друзей, которые совершенно до этого момента не представляли что такое программирование. Обе попытки провалились, несмотря на то что у меня был опыт и программа преподавания основ программирования и Java в моей компании. Правда один из них все-таки устроился в IT контору, но тестером. После этого я понял что программировать — это сложно 8).
Мне нравится рассказ о том, как буддистский монах читал лекцию в тюрьме. После лекции заключенные, заинтересовавшись, принялись расспрашивать его о том, о сем, и в частности о том, какая в монастыре жизнь. Оказалось, что распорядок дня в монастыре жестче, чем в этой тюрьме. Что встают монахи рано, что много и усердно работают, что много молятся и медитируют, а телека у них совсем нет (как и многих других привычных для буржуинской тюрьмы удобств). В конце концов ошеломленные заключенные предложили монаху переехать к ним, в тюрьму.

В чем же разница между тюрьмой и монастырем, спрашивает рассказчик? Разница в том, что в монастыре люди *хотят находиться*. :)

Так что нет, это не вопрос сложности или простоты. Это вопрос желания быть программистом. Если ты находишься где-то по собственному желанию (а не из-за отсутствия вариантов и не по принуждению), тебе и море по колено.
Отличная история. Вообще у моих подопытных было желание. Мы довольно долго занимались, я даже уже начал думать что они начали понимать как это делается. Ан-нееет.
Разница все-таки даже не в том, что в монастыре *хотят находиться*. Это скорее следствие. Причина в том, что они имеют цель там находиться, которую считают несравненно выше всех мелких неудобств
Ценимая цель, это точно. Мотивацию где-то подцепили, то есть соответствующий патч в систему ценностей кто-то подсунул…

И средства имеют, чтобы этой цели добиваться — ресурсы организма, обстоятельства жизни и всё такое.
Очень часто работа программиста содержит немалую исследовательскую составляющую: разобраться с работой нового/неизвестного инструмента (будь то IDE, OS, ЯП, фреймворк или компилятор), причём для эффективного использования этого иструмента требуется часто достаточно глубокое понимание его работы, это заставляет программиста копаться в исходниках gcc/linux kernel/darwin/Qt и прочего. Хотя, это, конечно, зависит от конкретной задачи и от того, насколько программист мотивирован делать свою работу хорошо.
Да, все мы немножко следователи/исследователи
Бывало, когда жизнь казалась слишком простой, я просил подкинуть задачку «поинтереснее», а потом сидел, разбирал свалившееся «счастье» и думал «Дурилка! Ну что, теперь ты доволен?!»
Я только начинаю постигать все прелести Openlayers, но уже разрабатываю шаблонные действия с картами на ура. Поэтому некоторые задачи согласен, даются с легкостью. Я не считаю себя программистом и еще долго считать не буду. Но сама амбиция и цель стать таковым — это отличный стимул. Поэтому разрабатывая новые продукты, я всегда испытываю на практике разные технологии построения кода. И каждый раз приходится думать таким образом, каким не сможет думать просто «нерожденный программист». У нас отличается состав ума. В то время, когда одни ищут что-то хорошее во всем, мы всегда ищем что-то плохое. «А почему это не работает? А почему тут ошибка? Где же этот баг?» и т.п.
Имхо, в программировании самое сложное — это писать простые рутинные вещи.
Ну которые не требуют ни изысканий ни исследований. Просто пишешь и все.
Хороший программист всегда думает о том, как автоматизировать рутину.
Как бы заавтоматизировать трансляцию алгоритмов из мозга в код… над осмыслением задачи потратишь 5 минут, кодишь потом пол-часа…
Странно, у меня обычно на физическое написание кода уходит времени меньше, чем на обдумывание.
Сильно зависит от того, над чем думаешь. Ну и индивидуальные особенности — мне проще продумывать детали, когда уже есть скелет кода.
Увы, не всякий менеджер одобрит, что рутина будет выполняться тупым бездушным скриптом, а не его дорогим подчинённым.
Если менеджер такой идиот, то можно ему про скрипт и не рассказывать))
У нас начальство было в восторге, когда был автоматизирован один из этапов работы. Потому что робот никогда не спит и в отпуск не уходит. А научить людей пинать его в нужные места при необходимости — намного реальнее, чем научить хоть кого-нибудь выполнять этот этап вручную (проверено экспериментально).
Да как в любом деле — сложна не профессия. Сложно:
— Заставить себя не опускать руки при неудаче.
— Определить, какую информацию читать и какой верить, и какая важна на столько, что проверять нужно самому.

Как говорит мой отец — «проигравших мало — много сдавшихся».
<сарказм> Да ладно, ребята, работа у программистов не пыльная — сиди, кнопки дави — ничего сложного ведь! </сарказм>
Это не сарказм )
Мне этот вопрос обычно задавали в другом контексте. Ну, типа, сложно ли научиться и всё такое. Ну т.е. едешь, например, на такси, поговоришь с водителем о том-о сём, и такой вопрос.
Считаю, удачный ответ — «а водителем работать сложно?».
Кстати, мне чаще проще работать — обычно получается представить всё «в голове».
НЛО прилетело и опубликовало эту надпись здесь
ну очень широкий вопрос получился.
все равно что спросить: «легко ли художником быть».
Много аспектов в программировании от научных изысканий до работы в «подмастерьях».
В маленьких командах можно и с заказчиками пообщаться, а в крупных и не доведется.
Как и во всякой области есть место и планктону и гениям. К сожалению планктона становиться с каждым днем все больше.
У меня одного такое подозрение, что вариант «Я вообще уже не понимаю, что делаю» популярен в силу формулировки? :-)

PS автор — надо было делать мультиселект, потому что переодически фазы меняются с «легко» на «а не послать бы всё...» и все промежуточные :-)
это потому что очень много рутинных задач. Планктон тоже вполне себе нужен.
Самое сложное в программировании развить образ мышления под парадигму языка. Выделять процессы и связи в предметной области, часто не явно выраженные. И управлять сложностью разрабатываемых программ при постоянном изменении требований.
На развитие этих навыков могут потребоваться годы.

Часто слышу мнение что нужна хорошая математическая подготовка. На мой взгляд программирование скорее философия, чем математика. Математика нужна только для разработки новых математических алгоритмов (функций).
Я считаю, что для решения бизнес задач, хватит математики на уровне школы. Для реализации неких научных задач уже требуется знать и высшую математики и желательно численные методы, что бы не отвлекаться на понимая сути вещей. Отдельная каста это системные программисты, которые в моем понимаю есть философы.
Хорошая математическая подготовка как раз развивает те самые навыки выделения главного и укладывание этого в используемые парадигмы.
Это развивает не только математическая подготовка, но и некоторые другие тоже. В частности — написание курсовых, дипломных и прочих научных работ с последующим их рецензированием и защитой.
Защита дипломной работы, кстати, очень хорошо работает как первый опыт выступлений на публику.
У правильных студентов к моменту защиты такого опыта уже вагон и маленькая тележка.
Первый? Поздновато. Я к этому моменту защитил две курсовых и имел еще сколько-то выступлений безо всяких научных работ.
Курсовые не считаются, обычно их защита проходит в узком кругу на кафедре. А вот выступления с защитой серьёзной работы или с докладом о продукте, который долго разрабатывали командой, да ещё и для требовательной (типа доклада на конференции) — это опыт другого рода, и далеко не у каждого студента он есть. Есть небольшая разница между выступлениями с курсовой пред своими преподами и своей группой, и дипломом, когда приходят всякие умные дядьки и вообще если накосячишь — то запорешь себе диплом. И выступление перед залом в несколько сотен человек о штуке, которую твоя команда делала не один месяц, сравнимо с дипломом по волнительности.
Вот, правильно говорите. У меня товарищ, программировал еще чуть ли не на компьютере 80х с кассетами с самого детства,
Потом, учась уже в КПИ на программиста, до сих пор говорит, что та самая высшая математика, которую всем даже в нетехнических вузах/специальностях (у меня, например менеджмент в Киевском колледже связи) насильно пичкают, за весь программерский стаж всех его сотрудников в конторе (порядка 300 человек от 25 до 45, они ради интереса в конторе для всех опрос устроили) пригодилась едва ли десятку, и то, там вся группа пришла из програмерской конторы, которая писала какой-то около-биржевой софт, где аналитики, тервера и прочих сложных и умных знаний было едва ли не 80%.
Вы когданибуть шейдеры писали? Вот я пожалел что нам в универе обстоятельно векторной математики не преподавали.
хорошо пишете. Приятно читать текст.
Спасибо, приятно читать комментарии
Не понимаю пунктов опроса. Имеется в виду «сложно-трудно» или «сложно-неочевидно»?
Я на работе головой пользуюсь, но думать — это не трудно ( если привыкнуть ;) ). Трудно — это когда время поджимает, нервишки шалят и приходится думать на скорость в некомфортных условиях. Если же имеется в виду второе, то едва ли себе представляю как на любой работе может быть всё очевидно.
Сложность работы программиста, как правило, не осознается им самим, потому что основную работу выполняет интуиция. Она выдает только ответ, а решение остается незаметным для сознания. Программист легко может объяснить свое решение, и ему кажется, что решение настолько просто и очевидно, что даже стыдно становится брать деньги за свою работу. Кажется, что секретов своего мастерства раз-два и обчелся, и что если кто-то узнает эти секреты — то сможет программировать не хуже, чем ты сам. Однако это заблуждение. Несостоятельность этой иллюзии проявляется всякий раз, когда программист пытается что-то объяснить непосвященным или научить их программированию. Он даже может сообщить им самые сокровенные секреты своего успеха, но это, как правило, не помогает. Нельзя легко научить другого программированию без того, чтобы он сам прошел тот же путь, что и ты: практика, практика, теория, практика…

Мне также рассказывали один случай. Был программист, работал в научной лаборатории с учеными, очень талантливый. Однажды, придя на работу, он обнаружил, что… не может программировать! Он не может писать программы. Вчера мог, а сегодня — совсем не может. Просто не идет ничего из головы, как раньше. Через некоторое время выяснилось, что у него опухоль мозга. Затронуты оказались как раз те области, которые отвечают за способность к программированию. А в остальном вроде бы ничего не изменилось в его собственном восприятии — до тех пор, пока опухоль не начала разрастаться, конечно. Он умер, в конце концов. Вот такая печальная история.
"оказались как раз те области, которые отвечают за способность к программированию" — звучит, как фраза из желтой статейки.
В мозге нет отдела, отвечающего за программирование. Хотя бы потому, что когда он формировался, до появления первых компьютеров было, мягко говоря, далековато.

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

>В мозге нет отдела, отвечающего за программирование. Хотя бы потому, что когда он формировался, до появления первых компьютеров было, мягко говоря, далековато.А если затронуты области, связанные с абстрактным мышлением, то у него никак не должно было «ничего не измениться» в остальном, он бы пролетел в очень многих областях сразу. Это было бы заметно на любых задачах, в том числе и в общении.
Ваше доказательство предполагает, что все отделы мозга, обеспечивающие функции программирования, обязательно выполняют и другие функции, причем, как вы говорите, «много». Но это предположение ничем не обосновано. Известно, что мозг перестраивается в процессе обучения. Например, у глухих людей часть областей, которые у обычных людей отвечают за слух, перестраиваются на обработку зрительной информации, что улучшает зрительное восприятие глухого по сравнению с нормальным человеком, после достаточного времени адаптации. Так вот, что по-вашему мешает каким-то областям мозга перестроиться исключительно на программирование в процессе обучения ему?
Обосновано, если вы попробуете чуть-чуть подумать.
Например, о том, что некорректно приводить в пример глухих или слепых людей, т.к. изменения в мозгу происходят при отключении одного из фундаментальных органов чувств (обработка которого выработалась эволюционно). «Программирование» — не орган чувств, для него нет отдела мозга.

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

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

Чем отличаются сами задачи? То же самое решение абстрактных задач, отличия нет. Как и нет отдела мозга, «отвечающего за программирование», потому что вы до сих пор не можете мне сказать, что это значит «отвечать за программирование».
Ниже человек уже сказал вполне четко:
http://habrahabr.ru/company/infopulse/blog/166609/#comment_5760849:

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

Это вам понятно? Нет никакого абстрактного «разучился программировать», «отвечает за программирование». Есть конкретные навыки, все в той или иной мере используемые в решение других задач. Есть концентрация, есть кратковременная память. Есть даже более размытое понятие «абстрактное мышление», с которым тоже соотнесен определенный отдел мозга. А «умения программировать» как единой сущности — нет.

Этот «пример из жизни» вам рассказал какой-то человек, который был знаком с тем программистом, это испорченный телефон.
Вы спросили, чем отличается программирование от шахмат с точки зрения работы мозга. И далее утверждаете, что ничем не отличается, что это в принципе одно и то же: "То же самое решение абстрактных задач, отличия нет". Но это утверждение ничем не обосновано. Точного ответа на вопрос, чем отличаются, с точки зрения работы мозга, указанные задачи, наука не знает. На таком уровне неизвестна метрика пространства задач, и невозможно сказать, какие задачи больше похожи друг на друга с точки зрения работы мозга, а какие — меньше. Или, могут ли две различные, но в чем-то близкие задачи решаться полностью одной и той же структурой в пределах мозга. Но я привел довод в пользу существенного различия этих задач с точки зрения работы мозга потому, что один навык не эквивалентен другому. Шахматист не может без обучения программировать, а программист не может, соответственно, играть в шахматы на высоком уровне. И тут не помогает развитие таких навыков, как «абстрактное мышление» или «концентрация». Чего-то не хватает, чтобы превратить шахматы в программирование. И это «что-то» вполне может быть локализовано в пространстве мозга.
Это что-то — память. Развитие абстрактного мышления — помогает, концентрация — тоже — в случае, если осталась память о приемах (комбинациях ходов и стратегиях в шахматах или решении типовых задач, паттернах и т.п. в программировании).
Про кратковременную память вам уже сказали. Потеря памяти — это не то же самое что «разучиться программировать», и это совсем не «области мозга, отвечающие за программирование», хотя в ней и хранятся эти знания.
Даже если допустить, что это память. Память о приемах в шахматах или программировании не может быть локализована в одной точке пространства. Поэтому в принципе возможно потерять память об одном, но не потерять память о другом при повреждении малого участка мозга.

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

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

Поэтому я против «желтых» формулировок «области, отвечающие за способность к программированию».
Можно не потерять память «глобально о программировании» целиком; достаточно потерять какой-то критический участок этой памяти, чтобы нарушилась вся функция (программирование). Это как если на жестком диске компьютера затереть загрузочный сектор (boot sector). Вроде бы почти вся информация осталась на диске, но компьютер больше не загружается.

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

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

Мне известны и другие истории подобного плана, хотя и с меньшими подробностями. Например, в США есть один знаменитый джаз-музыкант, гитарист. Однажды он попал в аварию или перенес инсульт (точно не помню), в результате чего (помимо других последствий) утратил свой навык игры на гитаре. Однако, поскольку он выжил — то в течение последующих 10 лет он научился играть на гитаре заново и снова вернулся в джаз.
>Если сопутствующих нарушений оказалось мало (на той стадии развития опухоли) — то они вполне могли оказаться незамеченными.

Ну так это же именно то, о чем я и говорю!

>… утратил свой навык игры на гитаре. Однако, поскольку он выжил — то в течение последующих 10 лет он научился играть на гитаре заново и снова вернулся в джаз.

Я именно об этом. О том, что это не «область, отвечающая за способность к программированию», а участок памяти — и, вероятнее всего — вместе с какими-то еще воспоминаниями, потому что так локализовать повреждение маловероятно, одно зависит от другого.
Соответственно, если бы все не так сложилось, и этот программист бы выжил, вероятнее всего, он смог бы заново обучиться. Вот что я и хотел сказать.
Если быть совсем точным, то это (вероятнее всего) не участок памяти, а моторные навыки (я надеюсь, вы помните, что игра на гитаре — это преимущественно моторный навык?). А инсульт моторные навыки задевает в первую очередь (в частности, потеря координации).

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

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

Где-то прочитал такую аналогию: мозг новорожденного, в той части, что отвечает за умения и навыки мышления, подобен пустой многокомнатной квартире, где у каждой комнаты нет функционального назначения, и лишь хозяин решает что будет в той или иной комнате. Есть намеки хозяину типа раковины в комнате, говорящей о том, что тут будет неплохо смотреться кухня, но они необязательны к исполнению, можно в «кухне» жить, а в другой комнате готовить. Более того, при необходимости можно менять назначение комнат. Вроде науке известны случаи, когда при локальных повреждениях мозга человек утрачивал какие-то способности, но под действием целенаправленных тренировок они восстанавливались — за них начинал отвечать другой участок мозга.
Я немного изучал этот вопрос в научно-популярной литературе, и должен сказать, что все-таки размазаны. Между прочим, именно это обстоятельство и позволяет нервной ткани восстанавливать утраченные способности: повреждение носит локальный характер, а для мозга характерна некоторая избыточность заложенного в извилины «софта».
Если человек разучился программировать, то это могло бы быть выражено разным образом. У него могут быть проблемы с концентрацией, или кратковременной памятью, или абстрактным мышлением, или умением распознавать значки на экране. Это по-разному будет влиять на его не-программистские аспекты жизни, но одинаково будет мешать ему заниматься кодом. Если проблемы с концентрацией, абстрактным мышлением или там каким-нибудь механизмом, отвечающем за перевод мыслей на строго заданный язык программирования проявлены в небольшой степени, то это может не мешать ему жить в целом — у многих людей вокруг проблемы с логикой и вниманием. Но тем не менее, проблемы есть, они затрагивают много разных аспектов, в том числе — не дают программировать)

Я это говорю к тому, что рак мозга не может избирательно заставить забыть принципы программной архитектуры или лицо своей бабушки, не затронув при этом еще какие-то, возможно, малозаметные, вещи.
Спасибо, именно об этом я и говорю.
Почитайте замечательную книжку на эту тему:
Оливер Сакс. Человек, который принял жену за шляпу

Сознание человека и не такие фокусы выкидывает. И никакой желтизны, только клинические наблюдения.
Зависит от задачи.
Когда пишешь что то новое, особенно если есть ТЗ, а не просто смутные пожелания, нет ничего сложного сделать практически что угодно. Этого процентов 90% в работе.

Сложнее работать как troubleshooter.
Когда есть плавающая проблема, нужно найти ее причину и таки исправить. Хорошо, когда это качественный open-source продукт, обычно с этим проблем не возникает.
Взрыв мозга начинается когда нужно переписать несколько сотен тысяч строк чужого кода, написанного со всеми известными анти-паттернами и без документации так, что б это работало и работало без багов.

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

С кодированием нового алгоритма или фичи такие шансы тоже есть. Но когда представишь себе эту пропасть, через которую надо прыгать в 10 прыжков, и осознаешь, что на полпути тебя могут отвлечь так, что код в дело может и не пойти, становится гораздо сложнее.
Для чего нужно ООП? Чтобы стало проще и понятней. Зачем нужен UML? Уменьшить хаос. Интерфейсы? Управляемые языки? MVC? MVVM? Всё на тот же алтарь.
Orly?! Зачем нужен UML? Затем что бы объяснить всю эту ООП кашу.

Интерфейсы только усложняют код, делают конечную систему более запутанной. Вместо того, что бы иметь один класс (конкретную реализацию) у вас есть два — интерфейс и реализация. Как это может упростить систему? Я не знаю, как 2 может быть проще чем 1

Windows 8 и iOS 6 были созданы в 2012 году не потому, что 20 лет назад не могли нарисовать их дизайн или не было подходящего железа. Всё дело в том, что те способы создания программ, те методологии управления программистами и те подходы к написанию кода просто не могли дать на выходе систему столь высокой сложности, как нынешние ОС.
Не хочу вас огорчать, но ядра современных ОС целиком и полностью написаны на кристально чистом, православном С.
sim0nsays.livejournal.com/31460.html вот здесь можете немного почитать о том, как пишут эти самые ОС…
>Интерфейсы только усложняют код, делают конечную систему более запутанной. Вместо того, что бы иметь один класс (конкретную реализацию) у вас есть два — интерфейс и реализация. Как это может упростить систему? Я не знаю, как 2 может быть проще чем 1

Вы либо не программист, либо ещё очень молоды. Коротко говоря — это неверное утверждение.

>ядра современных ОС целиком и полностью написаны на кристально чистом, православном С
Я разве что-то говорил о языках программирования?
Вы либо не программист, либо ещё очень молоды. Коротко говоря — это неверное утверждение.
К примеру то же самое вам мог бы сказать Линус Торвальдс, только в более жестком тоне. Но есть еще 3-й вариант — мой опыт разработки значительно отличается от вашего.

Я разве что-то говорил о языках программирования?
Вы говорили об ООП, а ниже, в том же абзаце — про ОС.
Я не знаю, как 2 может быть проще чем 1 — а вы правы 1 проще чем 2. И 1 намного проще 100, а теперь парадокс — система из двух (интерфейс — реализация), позволяет 100 представить как 1. Я понятия не имею насколько я уже надоел хабру своими росказнями как пишу свой просмотровщик изображений, но у меня есть для вас отличный пример: Вы прекрасно знаете сколько в нашем мире существует способов сохранить изображение — хотябы изза того сколько вам известно файловых форматов. А теперь вопрос — как извлечь из разных файлов массив с каналами для пикселей, линейные размеры, сколько каналов в каждом пикселе, сколько бит на канал, все это хранится по разному. Гдето в маркерах (Jpeg), гдето в тегах (tiff), гдето по смещениям (psd). Ну вот берем общие данные и записываем их в наш 1 класс — и все, приложение пишем так чтоб оно с одним этим классом умело работать — а создавать его не будем. Мы унаследуем от него классы самые-самые разные, в них мы реализуем и чтение тегов, и чтение маркеров, и вычисление смещений и алгоритмы распаковки, но разве холст об этом догадывается — он всегда получает указатель одного типа в котором уже все нужные данные есть, а все что нужно получить дополнительно работет за счет виртуальных функций.
Неожиданно я тоже гружу разные графические файлы в своем проекте. И загрузка разных форматов файлов вынесена в отдельные ф-ции, а не классы. В итоге у меня не 10, а 1.
Но вы правы. Я упустил то, что мое замечание про интерфейсы касалось случаев, когда в проекте есть один интерфейс и только одна реализация. Такое пишут опытные программисты, такое пишут начинающие программисты.
Опытные пишут такое, когда чуют, что одной реализацией не обойтись. Начинающие — когда увидят такое у опытных, но причин не поняли, а тупо используют подсмотренный паттерн.

Кстати, в том же C интерфейсы (как концепция) широко используются. .h файл только с объявлениями функций и констант по сути и есть объявление интерфейса. Модулю, импортирующему эти функции, реализация не важна, важны сигнатуры и всё, этого достаточно чтобы модуль скомпилировать. А конкретную реализацию (например, с отладочной информацией или без, или скомпилированной под одну платформу или под другую) подсунет уже линковщик.
Windows 8 и iOS 6 были созданы в 2012 году не потому, что 20 лет назад не могли нарисовать их дизайн или не было подходящего железа

Железа как раз и не было. Достаточно посмотреть на использование памяти современными приложениями (bash, например, кушает ~2 мегабайта), чтобы понять, что на 640k это не взлетит. Тем не менее правильно подмечено, что раньше было сложнее. Но сложнее не только потому, что не было готовых фреймворков, а потому что эти фреймворки не могли эффективно работать без сегодняшних гигабайт и гигагерц. Мосье похоже забыл, каким был запуск, скажем, JVM году эдак в 1998.
«Завидую тем, у кого с головой всё в самый раз». Как аккуратно вы сформулировали. А вот есть еще суперпрограммисты, у них с головой избыток. Они помнят всю программу из 100500 строк, и поэтому не пишут комментарии — им то все и так ясно. Они находят эффектные оптимизации, которые правильно работают в заданных условиях и посыплются, когда человек со стороны сделает невинное исправление в, казалось бы, постороннем месте. Они очень возмущаются действиями этого человека — как же, он нарушил соглашение, которое хоть и не задокументировано, но должно быть ясно любому, который просмотрит все вызовы процедур a, b и c. Они против того, чтобы переходить на новые языки и оболочки — им комфортно и так.
А потом оказывается, что поддерживать их программу способен только суперсуперпрограммист, который в придачу ко всему вышеперечисленному способен разобраться в программе суперпрограммиста. Однако, проблема в том, что суперсуперпрограммисты, эти титаны мысли с шестнадцатью гигабайтами оперативной памяти мозга и 8-ядерным неокортесом, тоже иногда пишут программы…
Программистом работать легко. Кто считает иначе, никогда не пробовал вагоны разгружать и чугуний лить.
НЛО прилетело и опубликовало эту надпись здесь
А ты заставь грузчика писать программы. Легко будет ему?
Насчет чугуна вы не правы — не поверите но работа в металлургии часто требует от людей высшего образования, обширных знаний химии металов и флюсов, технического устройства печей — там я уверен и программистам местечко найдется и далеко не у печи.
Вагоны не разгружал, чугуний не лил, но вот фуры разгружал — с непривычки трудно, а потом легко, быстро втягиваешься. И тупеешь от монотонной работы после первичной оптимизации процессов.
Легко или сложно, по-моему зависит от способностей и склонностей: абстрагирование, декомпозиция и композиция, анализ и синтез, систематизация, построение иерархий, алгоритмизация и т. п. — если у человека с этим всё нормально, то обучиться программированию большого труда не составит. А вот если человек привык исполнять алгоритмы-инструкции, не вдаваясь в их сущность, не выделяя что-то общее в разных вроде бы задачах, то ему будет весьма сложновато. Хорошо если просто «кодер» из него получится, способный перевести уже сформулированные сущности и алгоритмы в простыню кода.

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

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

Сложно ли самому программисту работать? Т.е. работает ли он на пределе своих сил?
Зависит от способностей и подготовки самого программиста. Ничего конкретнее здесь не скажешь.

Сложно ли самому программисту работать? Т.е. напрягает ли его работа?
В большинстве случаев нет. Иначе нужно менять работу.
«Узкая специализация vs широкая» — с этим пунктом полностью не согласен.
по-вашему выходит, что специалист широкого профиля — это какой-то недоучка.
Чтож, буду защищаться.
Во-первых, в учебе я был не лентяем, а скорее наоборот — на голову опережал остальных. Мне было неинтересно вместе со всеми заучивать названия функций WinAPI, списки передаваемых параметров, и т.д и т.п. Но я запомнил основные принципы а также адрес msdn, на котором все необходимое есть.
Я не бросил, как некоторые в потоке, изучать программирование под windows, когда мы начали изучать ассемблер для RISC-процессоров и первые ARM. Но и эта область знаний у меня в голове отложилась.
В итоге в компании, где я работаю, я решаю все новые задачи. То, что еще неизведанно, где у нас нет опыта. Нахожу решение, прорабатываю архитектуру, и отдаю узким специалистам.
Я не напишу по памяти на листочке код для регистрации класса, создания окна и очереди сообщений. Мне это не нужно — засорять голову информацией, которую любой человек найдет в гугле. Я просто знаю, какие решения в каком языке нужно принимать, и что искать.
А еще я работаю на elance, и беру любые задачи. Надо быстрый сервис — я беру C++. Надо сложный backend с какой-то вычислительной работой — я беру Java. Простое десктоп-приложение — есть C#/WinForms. Чуть посложнее, да еще кроссплатформенное — C++/Qt.

Напоследок не могу не процитировать
Узкий специалист подобен флюсу: полнота его односторонняя
У меня другая проблема — мне чаще приходится админить чтобы что-то накодить. И вот с администрированием у меня начинают возникать проблемы. В итоге после вычленения какого-то продукта ты автоматом становишься его админом.

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

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

Другой вопрос — «интересно» или «не интересно»
Зарегистрируйтесь на Хабре, чтобы оставить комментарий