Pull to refresh

Comments 172

Нам платят, за то, что мы учимся каждый день!

А вот те, кто платит — они вот говорят, что платят за решение конкретных задач.
Одно другому не мешает.
Количество публикаций, посвящённых тому, что надо решать задачи быстро и качественно просто зашкаливает.

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

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

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

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

Брук, мифический человеко-месяц:

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

Горести ремесла
Не все, однако, радует программиста, и знакомство с горестями, присущими нашему ремеслу, позволяет легче перенести их появление.
Во-первых, надо работать очень тщательно. В этом смысле ЭВМ тоже напоминает волшебство из сказок. Если хоть один символ, один пробел в магической формуле не находится строго на своем месте, волшебство не работает. Люди не привыкли к совершенству, и лишь немногие области человеческой деятельности требуют его. Привыкание к требованиям совершенной точности является, по моему мнению, наиболее трудным в процессе обучения программированию)1).
Во-вторькх, задачи, стоящие перед программистом, определяют другие люди, они же отводят ему ресурсы v. снабжают информацией. Один человек крайне редко слм определяет обстоятельства своей работы, не говоря уже о ее целях. В административных терминах это означает, что'степень ответственности превышает объем прав., Однако, по-видимому, во всех областях созидательной деятельности формальный объем прав никогда не согласуется с ответственностью. В действительности же фактический объем прав достигается как только работа завершена.
Зависимость от других проявляется здесь особо, весьма болезненно для системного программиста. Он зависит от чужих программ. В то же время эти программы зачастую неверно спроектированы, плохо.реализованы, не полностью укомплектованы (например, нет программы на входном языке пли нет тестов) п слабо документированы. Поэтому программисту приходится часами разбираться в таких вещах, которые в идеальном случае должны быть вполне завершены, доступны и легко используемы.
Следующее обстоятельство сводится к тому, что приятно выдавать большие идеи, но какой же поистине «адский труд» — иногда поиск самой крошечной ошибки! Любая творческая деятельность подразумевает долгие часы кропотливого и скучного труда, и программирование в этом смысле — отнюдь не исключение.
П, далее, могло бы показаться, что чем меньше ошибок в программе, тем легче их найти, т. е. скорость отладки как бы обладает квадратичной сходимостью. Совсем наоборот — сходимость оказывается линешюп или хуже, т.е. в ходе отладки обнаружение последних ошибок требует гораздо больше времени, чем первых.
Последняя неприятность, а иногда и последнее разочарование заключается в том, что продукт, над которым вы трудились так долго, к моменту завершения (или даже раньше) уже устарел. Всегда коллеги и соперники гоняются за новыми и лучшими идеями. И вот уже'замена выношенной вами идеи не только задумана, но и внесена в план.
Да, знакомо, и вот такие задачи каждый день… А потом все эти хаки — это просто ад для поддержки в будущем. Видимо, автор имеет хорошую работу…
Ага, и на ней нет формально закрепленного уровня ответственности.
Разрабатывал бы он софт для систем жизнеобеспечения — пел бы совсем другую песню.
:-)
Просто нынче «разработчик» — слишком расплывчатое описание профессии. Чтобы понять сложность и уровень ответственности, нужно уточнять контекст.
Зависит от работодателя, наверное. Те, кто по-умнее понимают, что мы учимся каждый день. Те, кто попроще, считают, что последний раз в жизни люди учатся в институте, а дальше им платят только за решение конкретных задач.
Что мы учимся каждый день, они конечно понимают. Кроме того, работодатели обычно считают, что учёбой программист должен заниматься в свободное время. Иначе он плохой программист.
Это так, увы. Но хороший работодатель должен понимать, что для того, чтобы не перегореть, в свободное время (хотя бы иногда) работнику нужно отдыхать.
UFO just landed and posted this here
>> или перестают скрывать, что никогда не понимали

как много в этой фразе
Поправьте меня, программисты, если не прав.
Есть два утверждения:
Платят программисту за решение конкретных задач.
Для решения задач программисту нужно учиться каждый день.
По логике можно утверждать, что если программист не будет учиться каждый день, то ему не будут платить. Но, насколько я понимаю, нельзя утверждать, что «программисту платят ЗА то, что он учится каждый день».
Разные бывают обстоятельства. Я, например, вполне могу написать в таймтрекинг «изучение библиотеки такой-то — N часов» и если N будет разумным — заказчик не скажет ни слова, потому что применять библиотеку в проекте действительно надо, а сверх-людей, которые могут это делать без её изучения как-то не нашлось.

Но бывают и другие фирмы\проекты\заказчики — там «только реальные задачи», это грустно.
Спасибо! В отличие от предыдущего поста, этот пропитан мотивацией «садись и программируй уже сейчас». Буду показывать сомневающимся.
Кто бы что там не говорил о разбившихся марсоходах или глюкнувшем рентген-аппарате, в большинстве случаев цена ошибки программиста невысока. Ну, «поплывёт» блок текста на страничке, ну отработает функция на секунду дольше, ну упадёт программа с исключением. Всё может быть пофикшено. Мы, в отличии от хирургов или строителей мостов, чаще всего можем позволить себе ошибиться, получить сообщение об ошибке, исправить её и сделать вид, что так и должно быть. Нас, как правило, не садят в тюрьму и даже не увольняют за ошибку, если мы способны её исправить за разумное время и предложить какой-то способ избежать подобных ошибок в будущем.
Безответственный подход…
UFO just landed and posted this here
Цена ошибки программиста может стоить сотен тысяч жизней, а то и больше… думаю, на АЭС тоже есть софт (-:
Чаще — да, разная, но всё же. Самолёты тоже могут падать из-за ошибок в софте…
Но а так да, согласен (-:
Тут надо учитывать, что хирург может убить человека сам по неосторожности. Для АЭС же проводится много много тестов и работает несколько разработчиков. Это тоже самое, что если бы перед каждым шагом хирурга, 10 человек подтверждали так надо или же нет.
Много-много тестов проводится именно потому, что цена ошибки программиста чудовищно велика.
Мы создаем новые миры… Нескромно. И, разумеется, цена ошибки очень велика. Не осознавать этого — верх самонадеянности и безответственности. Самонадеянным и безответственным людям действительно легко и просто жить.
много-много тестов проводится от того, что все участники понимают, что все участники процесса работают с ошибками, включая тех, кто пишет тесты и пишет сценарии тестов
Цена ошибки программиста, пишущего очередное приложение для мобилки равна сотням тысяч жизней? Ведь далеко не все пишут управляющий софт для АЭС. И если ты собрался писать софт для АЭС — ты должен осознавать свою ответственность.
Но вот цена ошибки в каком-нибудь твиттер-клиенте — слегка потрёпанные нервы пользователей. Я даже не уверен, что мелкая ошибка в таком случае повлечёт за собой хоть какие-то финансовые потери.
В большинстве случаев софт пишется для зарабатывания денег: каждая ошибка может привести к оттоку клиентов, особенно когда продукт находится в состоянии жесткой конкуренции.
Старая история про амазон: когда они уменьшили время загрузки основной страницы, то получили рост прибыли.
Тем не менее, деньги — это намного менее ценная вещь, чем жизнь.

Более того, возвращаюсь к примеру с врачём:

Если врач сделает что-то не то и сразу это поймёт — разрез уже сделан.
Если программист сделает что-то не то и сразу это поймёт — он нажмёт ctrl-z

Если врач ошибётся и не заметит этого — его может поправить только медсестра, которая наверняка имеет меньше знаний и опыта, чем врач.
Если программист ошибётся ошибётся и не заметит этого — у него есть: unit-тесты, ревью кода и тестеры. А так же наперник, если это парное программирование или просто над проектом работают несколько человек.

Если врач допускает ошибку и никто не замечает этого во время операции — операцию придётся повторять, начиная реабилитацию пациента сначала.
Если программист допускает ошибку и никто не замечает этого во время цикла тестирования — компания выпускает hotfix.

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

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

Я к тому, что такое сравнение неуместно. Не надо искать красивые слова о «цене ошибки» и пытаться оправдать собственные. Ошибка — это всегда ошибка. Независимо от её… ммм… цены.
Речь о том, что 99% программистов делают ошибки, которые не приводят к угрозе здоровью и жизни, и поэтому не настолько критичны. В реальной жизни все так-же, не нравится пример хирурга — возьмите пример пилота авиалайнера, или водителя рейсового автобуса (максимум — проверка на перегар перед выездом). Да, для ответсвенных специальностей людей готовят долго, но никто не говорит что программировать марсоход или систему управления АЭС дадут студенту-самоучке. Там тоже есть сертификация и жесткий отбор.
Речь о том, что 99% программистов делают ошибки, которые не приводят к угрозе здоровью и жизни
Но ведь это не значит, что можно так наплевательски относиться к ошибкам, как сказано в статье.
Если хирург заденет опасную артерию, то ничего исправить он может уже не успеть. А автопилот можно заставить сотню часов отлетать на симуляторе, который можно разбивать сколько хошь. Думаю, автор про это.
Артерии не опасны. Хирург в операционной скорее всего сможет исправить, на то он и хирург и операцию проводит обычно с ассистентами.
Вот тут согласен: 99% программистов создают миры игр, всяких социальных сетей и т.п. фигни, которая фактически только развращает человека, уводя его в мир грёз. И чем больше ошибок в этих продуктах будет, тем больше шансов, что от них откажутся, что пойдет исключительно на пользу людям.
Ошибайтесь чаще и больше!
Рациональный. Есть цена ошибки, есть прогнозируемое время на разработку в условиях когда эта цена не высока. Вспомните о правиле 85 -15
Почему-то у меня из текста статьи сложилось впечатление, что автор пытается себя подобным образом оправдать, не более.
Безответственный подход…

Чистая прагматика. Вы не сможете стать хирургом или архитектором мостов, не беря на себя ответственность за чужие жизни каждый день. Вы можете стать программистом, у которого максимальной проблемой в работе будет «ой, что-то количество лайков у фоточки неверно обновляется». И, заметьте, я не говорю, что программировать можно плохо или что ошибки не надо фиксить. Я говорю о том, что программист может легко не доводить себя до нервного истощения, если пожелает этого.
… А в это время пользователь бьется головой о неработающий банкомат, т.к. до следующего он добежать уже не успеет, а сегодня — последний день оплаты ипотечного кредита…
Скажите, Вы программируете для своего удовольствия или решаете реальные проблемы в коммерческой фирме?
Вам приходилось писать мерзкий код через жопу, потому что результат нужен через час?
Сопровождать чужой мерзкий код, написанный через жопу?
Работать целый год не имея возможности выучить ни одну новую технологию, потому что для решения поставленных перед Вами задач это действительно не нужно?
Как все знакомо. Это полезный опыт, но через год подобных радостей понимаешь, что нервы дороже денег и надо менять работу.
UFO just landed and posted this here
Есть и приятные моменты, но как то ВЫ все в розовых красках описали
Меняйте работу. Вряд ли есть места, где можно получать удовольствие по всем пунктам, описанным в статье. Но разумное сочетание плюсов и минусов вполне возможно найти.
Да нет, у меня не все так плохо, просто не хватало в статье этих деталей
UFO just landed and posted this here
У меня бывало и хуже. Например сопровождать чужой код, написанный через жопу на языке, на котором я вообще не пишу и не собираюсь. #Тыжпрограмист
Ага, еще и админом поработать :-)
Никто не мешает вам этот код переписать, сделав его «своим и красивым». Не можете? Это уже ваш недостаток, а не того кода.
Если начальство не заинтересовано кто же вам позволит просто взять и переписать.
Переписать его можно, да, только делать это придется разве что в свободное время — за это никто не заплатит.
UFO just landed and posted this here
Вы программируете для своего удовольствия или решаете реальные проблемы в коммерческой фирме?

С третьей попытки я нашел фирму, где я решаю её коммерческие проблемы в своё удовольствие.

Вам приходилось писать мерзкий код через жопу, потому что результат нужен через час?

Да. А потом в 9 случаях из 10 к следующей версии эти куски переписывались вдумчиво и нормально.

Сопровождать чужой мерзкий код, написанный через жопу?

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

Работать целый год не имея возможности выучить ни одну новую технологию

Нет. Ума не приложу, как можно работать на такой работе. Надо сразу тактично сваливать.
Кто хочет — ищет способы, кто не хочет — причины.
В свободное от работы время вам кто-то мешает изучать «новую технологию»?
В свободное время можно хоть орхидеи разводить, но к работе программиста, а значит и к теме поста, это не имеет отношение
UFO just landed and posted this here
Потому что речь идет не об области человеческой деятельности «программирование», а об профессии.

Заниматься фотографией как хобби — кайф, а фотограф — то тяжелая и малооплачеваемая профессия. Видите разницу?
UFO just landed and posted this here
Мы, в отличии от хирургов или строителей мостов

Мне одному здесь кажется влияние одного небезызвестного подкаста?
Поясните, пожалуйста.
Umputun, ведущий подкаста Радио-Т, постоянно сравнивает программистов именно со строителями мостов.
Программировать легко и весело пока твоя задача не выходит на коммерческий уровень. А еще легче жить если ты никогда не увидишь (не будешь отвечать на вопросы) пользователей своей же системы. Типа программируешь — и все отлично! Наделал ошибок, программа неудобна — ну и ладно, заказчик же платит. Это удобная практика для «заокеанских заказов», где часто есть свой отдел саппорта, а также армия тестировщиков. Но возьмите вариант — «сам себе бизнесмен программист» — и вам придется и ТЗ составить, и общаться, и в ситуации «все пропало, помогите!» спасать клиента. Так что не все так весело.
А я не писал статью «Как весело и прекрасно быть бизнесменом». По моему мнению это тяжело и безрадостно, я поэтому в это и не лезу.
Складывается такое впечатление, что автор любят прыгать по верхам, а также обучать новичков программированию.
На этом этапе естественно все легко, красиво и просто.
Вы правы где-то наполовину — новичков программированию и правда люблю обучать, детей учил информатике, студентов учил, сейчас перевожу с английского некоторые учебные курсы. По поводу «прыгать по верхам» — ну в основном проекте я работаю 4 года, до этого был другой проект — 5 лет. Вроде бы не «по верхам».
Автор молодец. Он правильно видит свое предназначение и получает удовольствие от своей работы. Вот именно с такими программистами приятно работать.
Угу. И именно такие, как правило, тихо сливаются при первых трудностях на продакшне, при первых неудобных вопросах от пользователей. Именно за такими, как правило, приходится разгребать кучу хлама, стараясь аккуратно ничего не поломать.
Отлично.
В каком это месте я написал, что трудности на продакшене надо игнорировать, на вопросы пользователей не отвечать и оставлять за собой кучи хлама? По всем этим пунктам в статье есть комментарии, и они строго противоположны. Или Вы просто не согласны с оптимистами в принципе?
Нас, как правило, не садят в тюрьму и даже не увольняют за ошибку, если мы способны её исправить за разумное время и предложить какой-то способ избежать подобных ошибок в будущем.

Я как-то размышлял по этому поводу. Задуматься только — для программистов существуют специальные люди, которые проверяют их работу, находят ошибки и, что самое главное, это считается нормальным техпроцессом. Для других профессий таких прелестей не предусмотрено в общем случае. В конечном счете я пришел к выводу, что именно из-за сложности и возникло такое снисходительное отношение.
На любом серьёзном производстве существует ОТК. А качество ПО это что? В первую очередь отсутствие ошибок и документированное поведение. А какая там лапша внутри, jvm или clr, С++ или Haskell, на архитектуру, на историю коммитов, на документацию — конечному пользователю, простите, срать. Работает отлично, без ошибок? — Качественное ПО.
Всё что внутри (вверху перечислил), программисты сами для себя делают, что бы облегчить себе задачу в будущем.

Да даже мясо животных, выращенных дома, нельзя продавать без предварительной экспертизы.
Воздушные замки слоёв архитектуры и абстракций строятся без всяких усилий, и так же перестраиваются.
Ну-ну…
Я завидую этому программисту
Ну уж всяко легче чем перепроектировать что -то материальное, двигатель автомобиля, например
С чего вдруг? Двигатель автомобиля можно перепроектировать в САПР. Концерны этим занимаются каждое поколение автомобилей. Все время новые платформы выдумывают. При этом вполне можно представить такое ПО, перепроектирование которого окажется неподъемной задачей просто. Собственно, и там и там наблюдается похожий подход — в архитектуру закладывается модульность на этапе проектирования, чтобы потом можно было рефакторить отдельными кусочками, чтобы это было подъемно. Поэтому и получается, что там двигатель переделали, там коробку передач совершенно новую сделали. И возможно это за счет сохранения единого интерфейса между компонентами — вон мерседес например свою 7 скоростную АКПП спроектировал так, чтобы она влезла на место 5 скоростной практически без изменений всего остального.
«95% программистов из математики используют 4 арифметических действия, проценты\корни\степени да чуть-чуть помнят что такое логарифмы и матрицы.»
А кислород, которым все дышат, был открыт только в 1774 году…
Если бы программисты знали матемитику, которую на самом деле используют, было бы гораздо лучше.
Не хочу никого обидеть, но такое впечатление сложилось, после чтения статьи, что автор либо программил только последние пару лет либо программит для собственного удовольствия свои же проекты (может игры) и при этом под одну платформу, на одном языке и скорее всего под веб, а если автору что-то не понравится или вдруг станет сложно, он просто поменяет работу. А то что существует огромный слой корпоративного программирования, где постоянно нужно бегать между отделами (иногда между фирмами) и согласовывать различные API, иногда жертвовать хорошим кодом/архитектурой в пользу скорости и совместимости с другими и вставлять впопыхах «костыли» (в том числе и для тестирования), программировать 15 лет на Visual Studio 6.0, только потому что миграция будет стоить «дорого» и как-бы острой необходимости (кроме хотелок-перделок молодых программистов) особо и нет, а возраст половины отдела уже перевалил за 45, автор как бы упустил из виду.

Советчикам аля «ну поменяй работу» сразу отвечаю: «нет, мне не нужно менять работу, меня все устраивает, мне по барабану на чем программировать на MSVS 6.0 или на MSVS 2015». Если мне платят хорошие деньги я хоть в нотепаде виндовом могу программировать, и да это может быть сложно!
программировать 15 лет на Visual Studio 6.0, только потому что миграция будет стоить «дорого» и как-бы острой необходимости (кроме хотелок-перделок молодых программистов) особо и нет, а возраст половины отдела уже перевалил за 45, автор как бы упустил из виду.
Всплакнул.
Да, когда в 2005-ом закончил универ, сам бы не поверил, что на 6.0 кто-то программирует в 2005-ом. Со временем понял, что это еще не самые суровые будни, кто-то досих-пор на бейсике под DOS фигачит и продает при этом за хорошие деньги :)
UFO just landed and posted this here
Я в любом корпоративе буду писать так, как считаю нужным.


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

Если я не уложусь в сроки, это проблема менеджера


Это далеко не всегда и не везде так. Обычно это зависит от уровня вашей зарплаты. Чем она выше тем это меньше проблема менеджера и больше уже ваша.

дедлайны абсолютно всегда высасываются из пальца


Иногда они диктуются рынком. Например, ваш конкурент пишет не такой качественный код, зато новые нужные фичи добавляются каждую неделю и вы делая ставку на качество отстаете от него, например, на пол года и соответственно теряете рынок и деньги. Вспомните хотя бы историю, как Microsoft захватывал рынок ОС и какая винда была глючная вначале и как она висла на презентациях, ну и где они теперь? А если бы они пилили все качественно и продуманно, то и делили ли бы сейчас рынок ОС с Apple не в соотношении 10 к 90, а может в лучшем случае 50 на 50.

Так-что подход «давай быстро, быстро, завтра надо релиз хоть какой-нибудь нагавнякать» не всегда плох, а для большинства стартапов и вообще единственно правильный.
Когда читаю про качественный и железобетонный код, всегда почему-то вспоминается bash.im/quote/420672. Уж очень жизненно.
А мне лично посчастливилось побывать в роли «Пети» из истории, когда делал собственные проекты. Обычно все проекты загибались на стадии планирования архитектуры, так даже и не успев толком родиться. :) Потом через некоторое время кусал локти со словами «Вот же гады, они сперли мою идею, реализовали и поднялись!».
Ну тут «Вася» скорее проявил предпринимательские, чем программистские навыки, но все же. Я бы сказал, что мастерство программиста как раз в том, чтобы находясь в положении «Васи», все равно пытаться делать все как можно более качественно и продуманно. Скилл он как раз в том, чтобы в условии ограниченных ресурсов принимать правильные на перспективе решения. Ведь когда есть много времени на подумать, каждый сможет.
Я разделяю пока программистов успешных программистов на три категории: 1. крутые профи, которые просто любят и умеют делать качественный код (возможно vsb к ним и относится). Таким спецам важно именно писать качественный код, им по большому счету на класть на менеджеров, они делают все технически грамотно не обращая особого внимания на бизнес, им важен сам процесс. Если им начинают мешать они тупа меняют работу и для них это не проблема. 2. Это фанаты предметной области. Например, такие как Маркус Петерссон, который просто любит делать игры на том, на чем просто тупа умеет. Не важно, что на C++ больше возможностей по оптимизации и интеграции, чем на Java (в области геймдева), зато важно сделать это побыстрее, чтобы самому увидеть и показать всему миру свое творение и получить моральное, эстетическое и возможно финансовое удовольствие. И 3. это «семейные», которым важно заработать деньги, эти ребята наверно самые гибкие в плане технологий и сроков. Если им скажут сделать завтра, то они сделают хуже и завтра, если им дадут на недельку больше, они сделают лучше через недельку. Тупа профессионалы-исполнители, сделал в срок, получил деньги, умыл руки, если больше не нужно ничего делать.

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

Так вот мое мнение, что если вот этим последним бизнесменам начать поднимать уровень программирования, то они быстро потеряют предпринимательскую хватку и попадут в категорию 3.

Если я не уложусь в сроки, это проблема менеджера, пусть бегает, отодвигает.

дедлайны абсолютно всегда высасываются из пальца и тем же пальцем двигаются

А Вам не кажется, что это безответственная позиция с Вашей стороны?
UFO just landed and posted this here
Если я не уложусь в сроки, это проблема менеджера, пусть бегает, отодвигает.

Ну вот согласовал с Вами менеджер сроки, а вы не укладываетесь, и говорите, что он должен бегать. Где тут ответственность?
UFO just landed and posted this here
Да, от статьи веет какой-то неистовой наивностью. Прям как будто ее написала эта синеволосая девочка из мультика, она примерно такими же категориями мыслила. Какова бы ни была работа мечты, рано или поздно всегда наступает момент, когда приходится:
  • яростно фигачить код в преддверии дедлайна, а то и на продакшене у заказчика
  • общаться с идиотами, которые считают себя самыми важными и полезными
  • исправляя баг, добавлять еще три
  • исправлять чужой говнокод
  • выполнять рутинную нудную работу
  • вставлять костыли и надеяться, что завтра/на следующей неделе ты про это вспомнишь и у тебя будет время это исправить
  • выкидывать из кода тщательно обдуманные и реализованные дорогие сердцу куски кода просто из-за того, что какие-то требования забыли или наоборот, перестали быть актуальными

И многое-многое другое. Программировать действительно приятно и здорово, но убеждать новичков в том, что это легко и просто — это заложить в них основы для огромного и неизбежного разочарования (либо в работе, либо в себе). Легко и просто программировать только в сферическом мире в вакууме. Если автор живет в таких тепличных условиях, остается лишь порадоваться за него, но начинающим программистам представление о жизни портить не стоит.
Так это же всё прекрасно, ну право-слово!
яростно фигачить код в преддверии дедлайна, а то и на продакшене у заказчика
— это же супер! Это же яростно фигачить код! Я как-то прямо в серверной дописывал куски демона одного прямо по ходу того, как мой коллега демонстрировал его же работу в конференц-зале. Это же такой драйв!

общаться с идиотами, которые считают себя самыми важными и полезными
— ну Вы ведь знаете, что они идиоты, а Вы — умнее. Чего ещё надо?
исправляя баг, добавлять еще три
— ну так баг же исправили!
исправлять чужой говнокод
— отлично, меньше в мире говнокода стало.
выполнять рутинную нудную работу
— немножко можно, голова разгружается. Если приходится много и часто — либо пытаться автоматизировать, либо менять проект.
выкидывать из кода тщательно обдуманные и реализованные дорогие сердцу куски кода
— да это вообще счастья, когда я могу выкинуть куски неважно чьего, неважно как реализованного кода. Лучший код — отсутствующий код.

Ну и многое-многое другое. Запугивать новичков смысла не вижу. Лучше дайте мне 10 оптимистично настроенных джуниоров с горящими глазами, чем двух скептичных циников, оставшихся после волны вылитого на них негатива.
Ладно, я не вижу смысла спорить. Циники оттуда и берутся, что им потом приходится разгребать воздушные замки, которые строят 10 джунов с горящими глазами.
>> Лучше дайте мне 10 оптимистично настроенных джуниоров с горящими глазами, чем двух скептичных циников, оставшихся после волны вылитого на них негатива.

"… и мы напишем с ними такой кривой и непродуманный софт, который нужно будет патчить риалтайм в серверной за демонстрационным стендом!".

Судя по вашим цитатам и ответам, вы не программист, а оптимист. Я бы на таких как вы и сваливал бы весь чужой говнокод, который сам чистить не хочу. Ненуачо, ваши слова:

>> отлично, меньше в мире говнокода стало.
>> ну так баг же исправили!
Не самый лучший пример, но все же напишу, обратился ко мне знакомый и попросил реализовать некую программу, я с таким никогда не сталкивался, но идея заинтересовала. В итоге я взял с него за реализацию 70% от оговоренной суммы, и поблагодарил за оплаченную учебу.
Всегда считал что надо ловить кайф от своей профессии, если не нравиться — надо менять работу.
Всегда считал что надо ловить кайф от своей профессии, если не нравиться — надо менять работу.


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

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

И что же мешает им сменить работу на такую, от которой они будут получать кайф?
Учитывая, что работа не волк и в лес не убежит, то возникает очевидный вопрос: если все будут убегать с неприятной работы и щимиться туда где без нас хорошо, то кто же тогда будет делать эту работу?
Как кто? Роботы!

Автоматические кассы, автоматические линии фасовки и автоматизированные станки уже существуют.
В автоматизации труда грузчиков я принимал участие сам.
Самоводящиеся машины на подходе.

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


Вот совсем свежее опровержение :)

// Вызов MarkChanged выполнен асинхронно с задержкой. Это сделано из за того, что CommandBar при моментальном изменении
// IsChanged и уведомлении, что команда сохранения поменяла CanExecute, не обновляет состояние кнопки сохранения.
// А так как значение уже установлено в true последующие уведомления не приносят результата,
// кнопка остается неакивной , пока не закроешь страницу.
UIService.InvokeAsync(async () =>
{
	await Task.Delay(500);
	MarkChanged();
}).LogAsyncError();
Программисту не нужно глубоко знать математику

Автор, поспорю — математику знать сейчас уже желательно. Новые сервисы строятся на множестве графической информации и фичах — ну взять к примеру работу с метками-картами, выделение областей, крутые анимации. Они требуют представлять и понимать что и как происходит. И хоть программист и может всё это довольно быстро наверстать(математика позволяет себя понять в сжатые сроки благодаря куче формул и доходчивых разъяснений к ним), но в некоторые моменты это может стать критично или даже стеной, через которую пробиваться — недели экспериментов/изучений.
Знавал я такого «программиста», который считал, что не особо нужно знать математику. А потом реализовывал направо и налево алгоритмы экспоненциальной сложности с комментариями в духе «компьютеры быстрые, посчитают, не переломятся».
В теории алгоритмов и структур данных математики не так много. Допереть, почему в массив элемент вставляется вот за это время, а в хеш-таблицу за вот это — можно и без интегралов. Писать самому классические алгоритмы 99% программистов не приходится, ну а тем, кто в Гугле поиск пишет — им да, хорошо бы знать что к чему, но они об этом в курсе.
Вы когда-нибудь писали оптимизирующие трансляторы? Там как бы без продвинутой теории графов вообще никуда. Или писали бы Вы когда-то системы видеонаблюдения, например? Это в чистом виде проективная геометрия, алгебра, и еще куча всякой интересной математики. Работа со звуком — сплошные дифуры. Функциональное программирование — теория категорий. Дальше продолжать? Я бы не сказал, что подобной работой занимается очень мало людей. Знаешь C++ и не боишься математики — найдешь без проблем очень неплохую работу сейчас. Или для Вас программирование — это втаптывание формочек на php?

Я не говорю, что всем или даже большинству программистов сегодня нужно знать математику, чтобы выполнять свою работу. Но это общая культура, и, по моим наблюдениям, те, кто ее не знают или знают плохо, далеко не пойдут, им просто базы не хватит. Как можно считать себя технарем и не понимать математику хотя бы на университетском уровне?
Как, по-вашему, соотносятся объёмы рынка для программиста-математика на С++, и для втаптывателя формочек на РНР, в 2015 году?
Понятия не имею. Но вот эта штука говорит, что C++ — третий по популярности язык сейчас, и эта популярность растет. Да и многим программистам на C (второй по популярности) также не чужды объемные вычисления.
Я не знаю, как считали свой рейтинг они; но вот вам результаты пятисекундного эксперимента: hh.ru находит 1892 вакансий с упоминанием С++, и 2613 с упоминанием РНР.
Там написано, как они его считали.
The ratings are calculated by counting hits of the most popular search engines.

Иными словами, С++ — третий по обсуждаемости язык.
К платежеспособному спросу на С++-программистов этот рейтинг не имеет отношения.
Спрос еще очень сильно от региона зависит. Одно дело смотреть статистику например по Перми, а другое дело например по Лос-Анджелесу или Мюнхену, где центр автомобильной индустрии и спрос на PHP тут в разы ниже чем, например на хорошего Си программиста или даже на разработчика микросхем.
У меня статистика не по Перми, а по рунету в целом (75% вакансий — в РФ, из них половина — в Москве).

Предлагаю и вам тоже поискать какое-нибудь количественное подтверждение своим словам.
Без обид, но Россия в целом больше формочки клепает, чем индустриальные штуки производит. Именно поэтому и статистика такая.

В подтверждение моих слов достаточно зайти на сайт stepstone. de и набрать в поле Was: php а в поле Wo: München, видим результат 92 предложения, теперь проделываем то же самое но с C++ и видим 195 предложений. То есть результат обратный тому что предлагает нам hh. Ну можно думаю то же самое проделать и на всяких job monster-ах и прочих поисковиках.
1) мы всё-таки на Хабре, а тут тоже 75% публики из РФ, из них половина — из Москвы, и состояние дел в Мюнхене тут не многих волнует.

2) по поводу Мюнхена вы правы. Но, похоже, это всё-таки Германия такая особенная. Берём www.jobsite.co.uk — видим 712 вакансий на С++ и 731 на РНР. Берём jobsearch.monster.com — видим 919 вакансий на С++ и 1000+ (подробнее неизвестно) на РНР.

Разрыв, действительно, всюду небольшой, но РНР всюду впереди.
состояние дел в Мюнхене тут не многих волнует.


Так я Мюнхен привел, как пример своего тезиса про то, что все от региона зависит. И мировая статистика далеко Россией не ограничивается.

Разрыв, действительно, всюду небольшой, но РНР всюду впереди.


Опять же мы почему-то сконцентрировались на С++, но давайте посмотрим на www.jobsite.co.uk стату по Java или C# и увидим что она рвет и C++ и Php вместе взятых. А сложность проектов на Java и C# в большинстве случаев не ниже плюсовых и значительно выше, чем клепание формочек на PHP.
UFO just landed and posted this here
Сложность проектов измеряю задачами, которые ставятся перед разработчиками в проектах. Предвидя, что сейчас дискуссия может свестись к обсуждениям вроде «а че на пхп серьезные проекты не делаются?», но не вижу смысла обосновывать тезис «на пхп большинство проектов это клепание формочек». Но при желании можно думаю брать конкретные вакансии и делать какие-то приблизительные выводы о серьезности проектов. Я свои выводы сделал из своего опыта.
UFO just landed and posted this here
Просто из моего опыта подавляющее большинство интересных проектов делается конкретно на плюсах.


Интересность проектов еще куда более «субъективная» вещь чем сложность. Сложность хотябы можно как-то измерить в затратах времени и денег (например в уровне зарплат специалистов), а интересность ну вообще, разве что в количестве полученного кайфа на единицу времени конкретным программистом.
UFO just landed and posted this here
Я в первую очередь говорю о сложности, которая в наукоёмкости, новизне, и так далее.


Вот как раз я об этом же! Наукоёмкость из моего опыта пропорциональна колоссальным затратам денег на высококвалифицированных специалистов и времени на реализацию проектов. Да, от такой работы можно получать кайф, а можно и не получать, но нельзя сказать про такую работу «это легко», что делает автор статьи.
UFO just landed and posted this here
Рассматривать Россию в данном контексте считаю не совсем уместным, т.к. основная тема в нашей стране по большей части это торговля, отсюда спрос на наукоемкие или индустриальные штуки заметно ниже востребован, чем на интернет магазины на пхп. А вот если по миру смотреть, думаю ситуация скорее в пользу пропорциональной зависимости наукоемкости и затратам.
С++ и РНР выбрали для сравнения вы сами:
Знаешь C++ и не боишься математики — найдешь без проблем очень неплохую работу сейчас. Или для Вас программирование — это втаптывание формочек на php?

Совершенно верно, что клепатели формочек на Жаве и C# востребованы не меньше, чем клепатели формочек на РНР :-Р

Мировая статистика Россией не ограничивается; но как я показал, в России статистика такая же, как в Британии и как в США. Лишь Германия стоит особняком.
Уважаемый, так Вам шашечки или ехать? Человек написал статью про то, что программировать здорово и приятно. Я с этим согласен, но интересно в первую очередь решать сложные задачи. Вы знаете людей, которые фанатеют от втаптывания формочек (на любом языке)? Да, это тоже оплачивается, но статья про другое.
Зависит от сложности формочек. Что-то нетривиальное сделать так же бывает интересно.
Я знаю даже людей, которые фанатеют от работы кассиром, потому что можно целый день болтать с разными людьми, а мозги напрягать не приходится вообще.

Вкусы у всех разные.
Я знаю даже людей, которые фанатеют от работы кассиром


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

Легко и приятно — не одно и то же, конечно же.
UFO just landed and posted this here
Это не моя цитата )
Но я в данном контексте смело добавлю к слову C++ еще и Java, стек технологий .NET. Потому-что сейчас многие серьезные проекты, которые раньше можно было реализовывать только на C++, мигрировали на Java и .NET. Но математики на них стало не меньше, т.к. предметная область не изменилась.
Приношу извинения, что приписал вам цитату 0x13 :-)

На Жаве сейчас всё подряд — от серьёзных вычислений до телефонных игрулек и от бухгалтерских печатных форм до веб-интерфейсов к БД. Странно всё это мешать в одну кучу и высчитывать «среднюю температуру по больнице».
Совершенно верно, что клепатели формочек на Жаве и C#


Ну если так уже называть это все, то тогда давайте разделять еще клепателей формочек, т.к. клепатели формочек на Java или .NET, почему-то по рынку больше получают чем клепатели формочек на PHP. Да еще их вон в России днем с огнем не сыскать почему-то.
Между прочим не велика разница, учитывая, что плюсовики скорее не ищут работу на hh по моему мнению.
UFO just landed and posted this here
У нас в свое время завкафедрой любил про все эти hh.ru рассказывать случай, когда представитель одного очень крупного рекрутингового агенства ему заявил, что его кафедра в СПбГУ говно, мол про нее никто у них в компании не знает. Он над ними просто поржал тогда, ведь всех выпускников сразу же с руками отрывали, им просто не приходилось в агентства обращаться. Топовых профессионалов не через hh.ru нанимают, их направленно хантят.
Я им тоже никогда не пользовался для поиска работы. Сейчас зарабатываю на хлеб низкоуровневым кодингом на С++, но до этого были и формочки на Делфях, и бэкенды на РНР, и макросы на VBA, и реверсинг х86-бинарников… Ни к какой из своих работ я не отношусь с пренебрежением. Спрос есть на всё.

Что же касается hh.ru — я его привёл в пример потому, что там проще всего сравнить количество различных вакансий. Если вам известен способ сравнить число вакансий, которые сами находят программистов — поделитесь им.
UFO just landed and posted this here
UFO just landed and posted this here
Среди моих знакомых — ни плюсовики, ни похапешники не засиживались без работы подолгу.

Думаю, что во всех предметных областях, связанных с программированием — спрос до сих пор превышает предложение.
Это все прекрасно, вот только разговор был о том, нужна ли программистам математика. И C++ я привел не просто так, а потому что там математика используется чаще всего, и такие специалисты нужны. А если кому нравится php или дельфи, так кто же мешает.
UFO just landed and posted this here
И C++ я привел не просто так, а потому что там математика используется чаще всего, и такие специалисты нужны.

Вот это выглядит странным подходом. Какую часть среди специалистов на С++ занимают математики? А какую все остальные? Да и почему именно С++? Если в математике для вашей задачи нет большого количества векторных операций, требующих прямой работы с процессором, то С# ничем не хуже, а писать на нём проще. А часто более удобным может оказаться какой-нибудь Matlab или Maple… И наверняка, многие по старинке пишут на Фортране (обосновывая это тем, что там библиотек больше).
www.sql.ru/forum/466654/s

я просто оставлю это здесь
Вы предлагаете все 114 страниц читать? Прочитал первую, ничего интересного не нашел.
Там можно увидеть пример неверной оценки популярности и эффективности языков.

И да, я не понял, по какому принципу TIOBE оценивает популярность. Написано там слишком размыто. Четко написано только то, что не по количеству строк кода, хотя бы это радует.
По количеству хитов в поисковиках.
Вот этот то метод я и не понял. Можно подробнее?
Вы рассказываете о крутости С++ человеку, написавшему о С++ на Хабре с полсотни статей и занимающем второе место в рейтинге авторов хаба С++. И да, работа с видео и аудио — мой хлеб последние 10 лет. Математика там есть, но она сложна только в глубинах кодеков, написанием которых занимается не так много людей. Всё, что уровнем выше — редакторы, плееры, стриминг, захват — совершенно не критично к математике.
Геймдев плачет от ваших слов по поводу математики, ах если бы её ненужно было знать.
А что в геймдеве сейчас серьезного с математической точки зрения необходимо знать и применять?
Серьёзного особо ничего, в основном матрицы, векторы, кватернионы, иногда гармоники. Просто всё это нужно хорошо знать, чтобы придумывать кучу хитростей, которые везде используются (в основном шейдеры). Хотя возможно я неправильно понял и математика для автора, это исключительно дифуры, интегралы и прочее. Тогда да этого не так много.
UFO just landed and posted this here
Я учил математику в вузе. 4 семестра вышки, дискретка, анализ, теорвер и т.д. Из этого всего за 10 лет работы пригодилось 5% — графы, метод Монте-Карло, чуть-чуть статистики. А что Вы такое программируете, что Вам математика нужна в больших объемах?
UFO just landed and posted this here
Я не физмат заканчивал, а «программное обеспечение автоматизированных систем». Математики было в меру, но как по мне — то и этого много. Лучше бы больше было предметов по проектированию ПО.
UFO just landed and posted this here
взаимодействия с другими исполнителями, а с людьми, опять же. Как этому учить, я представляю плохо, впрочем.

Возможно, типология Майерс-Бриггс в этом поможет.
В этой фразе (Оставшиеся 5% — разработчики научного софта, а значит математику можно считать не необходимым знанием, а их предметной областью (так же как разработчику софта для обсерватории пришлось бы изучать астрономию)). мне видится несколько неточностей.
1) почему «научного»? Математика в объёме, заметно большем школьной программы, нужна и тем, кто пишет роботов для Уолл-стрит, и тем, кто программирует беспилотные автомобили. И то, и другое — коммерческие разработки, которые не продвигают науку, а беззастенчиво ей пользуются. Скорее, это «наукоёмкий» софт, но никак не научный.
2) Разработчику софта для обсерватории понадобится и аналитическая геометрия, и оптимальное управление, и теоретическая механика — только для того, чтобы нормально сделать движение телескопа в нужную точку. Чтобы следить за участком неба, потребуется ещё немного дополнительного матана. Чтобы обрабатывать информацию с телескопа — обработка сигналов (тот же матан плюс статистика)… Так что математика в его «предметной области» будет занимать совсем немалую часть. Ну и к другим предметным областям это тоже относится — в той или иной мере.
Но насчёт 5% — сказать трудно. Выглядит похожим на правду, или даже чуть оптимистичным.
Программист использует математику в том объёме, в каком он её знает. И чем больше знает, тем больше думает, что математика нужна. И наоборот…
Думается, это две полярности. Истина где-то посередине и чуть плавает в стороны в зависимости от условий.
Истина каждому своя. Одному программировать в кайф, другому надо кормить семью и не важно как.
Думается всё же, что каждому своя — правда, а истина — это уже как раз правда без критериев, абсолютной категории. Подобно тому, как в формальной логике истинное утверждение не может быть ложным и наоборот. Но это уже философия, можно нечаянно перестараться и превратить хабр в хайямр. :) хотя философия и программирование неразделимы: не будешь хорошим философом — будешь плохим программистом.
Заметьте, из утверждения «программировать в кайф» совершенно не следует «Программировать это легко».
Кому-то в кайф например поднимать железяки весом 90 кг каждый день по 100 раз, но ведь это же нелегко.
Операция OR имеет вот такую таблицу истинности. Цикл for выполнится столько раз, сколько задано вот в этом условии. И это работает всегда!


В идеальном мире, может быть. Я не сказать что супер-пупер программист, но за те 10 лет, которые я программирую микроконтроллеры, я сталкивался и с кривыми компиляторами, инициализирующими static переменные мусором при размере кода=100кб (но нормально отрабатывающими при размере 99кб и 101кб), и с порчей стека, когда программа работает в одних условиях, но падает в самых странных местах при высокой сетевой загрузке, и с другими подобными чудесами. Поэтому я бы не был столь категоричен.

Программисту не нужно глубоко знать математику

Тоже когда-то так думал. Как я был неправ.
Мне кажется, что основной мыслью автора является тот факт, что у программирования достаточно низкий порог вхождения. Для того чтобы быть «синьором» действительно нужно иметь кучу опыта и самых разных знаний, однако «джуниором» можно стать за год-два. При этом по достижении определенного уровня, ИМХО, самым важным «направлением роста» становится коммуникация, т.к. мало уметь разрабатывать качественную архитектуру, надо еще уметь продать бизнесу идею о том, что нужно потратить кучу денег чтобы было «хорошо». И именно этот скил дается тяжелей всего людям с техническим уклоном.
Судя по постоянным примерам про «поплывший текст» и «неважность» математики, автор работает где-то в области веба, скорее всего, во фронтэнде.
Почитайте что-нибудь о разработке 3D-приложений, AI, серверах баз данных и еще чем-то сложнее сайта-визитки и скажите еще раз, важна ли математика, тервер, статистика и прочее. И, поверьте, этим занимается отнюдь не 5 процентов программистов.
Почитайте, например, о борьбе с багами в старых версиях Internet Explorer или об уязвимостях PHP 2012 года, или о стоимости и работоспособности различных операций для различных CPU, OS, версий видео-драйверов, и скажите, что программирование и поведение if так уж предсказуемо на 100%.
Почитайте о багах в speed trading ботах, взломах биткоин-бирж, судебных исках за утечку персональных данных итд, и скажите, так ли уж ошибка программиста всегда стоит дешево.
Привет, никогда в жизни во фронтэнде не работал, 10 лет пишу на С++ код связанный с обработкой аудио и видео. Драйвера тоже писал, да. И ещё писал софт, за теоретическое падение которого надо было заплатить пару миллионов штрафа. Остаюсь при своём мнении, изложенном в статье. А исключения только подтверждают правила.
По-моему, статья не выдвигает опровержения, что «программировать сложно». Да, иногда трудности преувеличивают. Но аргументы вроде «это просто наша работа» и «нам всего-то нужно сделать все правильно», как по мне, не противоречат утверждению, что научиться хорошо программировать — сложно. Программировать, конечно, несложно, если ты это умеешь.
Хирург хорошо понимает то, что делает, и, думаю, что он сможет назвать это «несложным». Но сколько он этому учился? Ни в коем случае не хочу задеть ни одного медика, но и болезни — тоже не все смертельные. Так что, подобное противопоставление мне видится неуместным.
Я в веду к тому что всему нужно учиться. И некритичность ошибки программиста компенсируется необходимостью почти непрерывного углубления в дебри постоянно расширяющейся предметной области.
За «Головоломку» не смог не плюсануть карму!
Sign up to leave a comment.