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

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

О, профиль компании поменялся!
Глянул последние 3 статьи корпоративного блога — ни одной строчки кода. И правда поменялся.

Справедливо. Но! На следующей неделе у нас будет статья со строчками кода.

Глядя на аватарку и имя я чувствую, что это будет в тинькофф-журнале)))

You got me!

Я так до сих пор и не понял, Король Разработки строчит вот эти посты вилами по воде для разных контор, чтобы их тут (на хабре) лишний раз пропиарить и баблишка намутить или как? Сколько вообще за это платят?
Компания нанимает популярного автора хабра для написания пиар-статьи? Никогда такого не было!
И ведь не просто строчит, а дичь какую-то строчит:
Если пуля врезается в стену, она останавливается. А если стена резиновая, то отскакивает. А если пластиковая, прошибает насквозь.

Ух ты, а мужики-то не знали что оказывается можно просто сделать резиновую броню на всей технике — и все начнет просто отскакивать, и пули и снаряды и даже ракеты с торпедами. Или побоялись что противник такую броню ножами разрежет и вытащит экипаж наружу?
Так это же известный сплав резины со сталью, чтобы снаряды отскакивали обратно
снаряды отскакивали обратно

в стреляющего.

Про жидкий вакуум забыли.

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

Одни идут, толкая пред собой и перекатывая мир в будущее, а другие бегут вокруг и причитают: «Боже! Куда катится мир!» Ⓒ :-)

… бегут вокруг _налегке_
vladkorotnev
а прикольно сказано то
Про разработчиков в авито не актуально в свете последних статей на хабре )
Почему в техподдержке так всё сложно (а точнее почему клиентам)?
Потому что могут!
Если совсем уж серьёзно, то все вышеперечисленное имеет место быть, но вместе с ним ничуть не реже бывает и:
— вот просыпаешься ты, и совсем не прёт работать. Да, задача понятная, но не прёт, и ты прокрастинируешь всеми возможными способами. На Хабре зависаешь, например. Другому работяге бы от работы не отвертеться, но мы-то можем себе такое позволить.
— а ещё мы можем делать всё тяп-ляп. Особенно если проект не интересный, клиент противный, начальник вредный,… или совсем не прёт работать. Так, впрочем, могут очень многие, и строители, и садовники, и ещё леший знает кто. Но нас на этом труднее поймать. Работа строителя-то на виду.
— а ещё мы действительно нередко занижаем сроки оценки. Не потому, что не видим всех деталей. Ну да, иногда не видим. Но если мы не совсем уж джуны, мы все равно делаем чаще то, что уже сто раз делали, те самые скрытые детали знаем, и более-менее достоверно можем оценить затраты. Но клиент же испугается. Да и времени точный анализ сам по себе много потребует, а это наше рабочее время и наши деньги.
Это я не к тому, что мы все такие плохие, а к тому, что бывает по-всякому, и жалобы клиентов тоже нередко бывают обоснованными.
а еще бывает, когда закончился день, ты встаешь с рабочего места идешь домой, а в голове крутишь проект, как его лучше сделать. Ешь ужин и думаешь, а потом идешь к компу, чтобы проверить пару гипотез. После ужина ты продолжаешь думать. А на утро приходишь на работу, и за чашкой кофе, тебе приходит решение, и ты пишешь 20 строк кода, которые решают проблему.

У меня нередко бывало, что решение приходило во сне, потому что когда я спал, мне снился текущий проект и нерешённая задача

Это особенности работы мозга
Интересно описаны в книге Барбары Оакли «Думай как математик. Как решать любые проблемы быстрее и эффективнее»
К примеру решая трудную задачу и засев в тупик, не обязательно ждать сна, достаточно просто переключиться на какую-нибудь рутинную задачу, в идеале физическую, помыть посуду, прогуляться, сходить в тренажерку, решаямая задача перейдет в фоновый режим, будет продолжать обрабатываться подсазнательными процессами(если можно так сказать). Когда после переключения вы вернетесь к задаче, вы поймете что если не решили проблему, то 100% продвинулись в ее решении.
В книге много интересного, описание разных исследований и их анализ, советую ознакомиться.
Имея широкий опыт применения этих и похожих советов на практике, могу сказать, что сон, как способ выйти из тупика, вне конкуренции с большим отрывом.
Это очень индивидуально. У меня, например, это ходьба и велосипед.
Не забывайте такую замечательную вещь, как зависнуть в душе от внезапно пришедшего решения!

А чего зависать? Надо быстрее выбегать и записывать-проверять решение!

Да, сон дает положительный результат в том числе и короткий дневной сон (10-20 минут) если есть такая возможность. Помогает перезагрузиться, расслабляет мышцы и позвоночник, главное лежа не зависать в соцсетях, пустая трата времени.

Хочу еще дополнить по поводу основной концепции вокруг которой построена вся ее книга.
Суть заключается в том что мозг работает всегда в одном из двух режимов.
Режим сосредоточенного мышления и режим рассеяного мышления. Каждый из них полезен по своему.
Но в сосредоточенном режиме очень легко зациклиться, известно что наше сознание не способно удерживать много объектов одновременно. В сосредоточенном режиме мы можем очень должно перебирать одни и те же идеи, не допуская новые. И если среди этих идей нет решения, мы впадаем в ступор.
И если мы не умеем переключаться, мы можем так долго проторчать, нервы подпортить, здоровье, это негативный стресс.
Рассеяный режим помогает увидеть более широкую картину. Мы как бы делегируем задачу подсознанию, которое в своем оперативном доступе обладает большей информацией (ранее загруженой) с которой способно оперировать. Сознание в этот момент не должно нагружаться, т.е. лучше делать операции которые не требуют постоянного сосредоточения, пока рассеяный режим работает.
Все конечно это моя интерпретация, в книге есть очень крутые зарисовки, более понятные, перепечатывать я их не хочу. Книгу советую.

Спасибо за рекомендацию, почитаю!

Ещё есть курс от Барбары Оакли на Coursera, называется «Learning How to Learn», книга + курс очень помогли мне в становлении джуном.
Спасибо огромное за книгу, мне как новичку очень пригодиться знать о таком
Прикольно. А у меня в душе или когда каким-нибудь физическим трудом занимаюсь.
У меня так решение, которое в итоге и ушло в релиз, пришло ко мне во сне, я вскочил в 4 утра, чтобы записать и не забыть))

Справедливости ради, так живут люди из очень, очень многих профессий.
И это не уникальная специфика IT или чего-то ещё, это неумение закрывать рабочую дверь и оставлять работу на работе.
Дописано
И зачастую – невозможность полностью отключаться, потому что ты знаешь, что если сейчас ты не сядешь за бук и не сделаешь то, что крутится в голове, то с большой вероятностью ты это упустишь и завтра уже не воспроизведёшь. Так что плевать, что полпервого и давно пора спать.

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

Это возможно только с однообразной механической работой.
Пока что в человеке нет переключателя режимов работа/дом/семья/отдых.

Невозможность отключаться называется недисциплинированность ума. Программистам когда-то сказали, что их профессия очень творческая, а они взяли, да и поверили — чисто дети. Но зато это позволяет им в массе продвигать своеобразное понимание дедлайна и оплаты, себе на пользу.
Кто же от такого откажется?!

Такое вот гиперболизированное мнение, сформулированное на личной практике. /тонкий юмор/
Вот кстати, еще одна причина, почему так много получаем. Потому что думаем о работе даже когда не за компом.
У Ричарда Хикки (создателя Clojure) есть отличное видео на эту тему — «Hammock Driven Development».
а ещё мы действительно нередко занижаем сроки оценки

Это замечено еще очень давно.
Ф. Брукс. «Мифический человеко-месяц».
Книга издана чуть ли не полвека назад.
просыпаешься ты, и совсем не прёт работать
Важный момент, не упомянутый в статье. Головой работать труднее, потому что починить разум труднее, чем руку или ногу, и способов надломить разум гораздо больше.
А если тебе тимлид говорит что ты 3 месяца ничего не делал, тогда как ответить? Он то тоже программист, должен понять :)

Тимлиду который говорит это раз в 3 месяца можно ответить что угодно.
Правильный тимлид задает вопросы о ходе работ чаще.
Первый: что сделал. Именно с приставкой "с" — Сделал, предъявляемый результат. Один из хороших критериев сделанности — можно дать на допиливание другому разработчику.
Второй: на чем забуксовал и где надо помочь.

А может имеет смысл сразу тимлида спросить, как так вышло что человек в его команде 3 месяца ничего не делал?
Поверьте, бывают задачи и посложнее чем на 3 месяца простого обдумывания одним человеком.

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


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

Я не очень понимаю как «взять на буксир» ведущего, когда он зарылся в массиве входящих данных. Что бы просто войти в его контекст нужно потратить те же условные 3 месяца разработчиком не менее сильным, чем ведущей, т.е. удвоить затраты, когда первому может неделя и осталась. Второй разраб тогда только потеряет время, а это очень дорогое время. Второй момент что бы войти в контекст нужно, допустим, изучить некоторую теоретическую/практическую/математическую область, при этом не создав ни одного алгоритма, а приобретая новые навыки. Буксирующий разраб в таком случае на входе может получить три томика по 250 страниц не самой простой документации.

Явный признак того, что проблема выше. На задачу выделена малая мощность (один человек) с большим периодом отклика (условные 3 месяца).
Бить задачу на грубую и мелкую аналитику. 250 страниц скорее всего в виде нескольких разделов. Ведущий разработчик координирует усвоение материала ведомыми, которые помогают переваривать ему этот томик.
Собственно мы и подошли к еще одному ответу на часть вопроса, почему дорого. Потому что тот, кто умеет решать быстро и качественно (или достаточно качественно для бизнеса), это делает (управляя не только собой), а остальные 3 месяца читают в одно жало 250 страниц документации.

Чтобы разбить задачу, кто-то все равно должен прочитать эти 250 стрениц, понимать контекст и быть в состоянии адекватно разбить. В противном случае, получим 10 задач, 10-ти разработчикам и всем придется по 250 страниц читать)

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

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

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


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


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

Соответственно, если бы я брал вас на буксир на работе по такому процессу, то к вам был бы приставлен стажер, которого вы бы учили тому, что осваиваете факультативно.

А если это никому не интересно, кроме меня?


Ваша цель какая?

В данном конкретном случае — понять, как решать одну задачу, которая что-то пока не решается.


То есть, в итоге там, конечно, тоже будет либо статья, либо реализация какая-то, но до этого ещё надо дожить. Пока измеримого внешне выхлопа ноль.

В одной компании история была, человеку поставили большую задачу. А потом проект свернули, задача потеряла актуальность. Но сказать об этом ему как-то забыли. В итоге два месяца еще он ее честно пилил.
У меня была история, как я полгода пилил задачу, а когда отдал на приёмку, оказалось, совсем не то, что нужно было заказчику. На вопрос, что за @#$%^, вам же высылали ТЗ, вы сказали, что всё ок, делаем, ответили: «Ой, а мы этот файл не открывали, мы думали, вы только то, что в письме, просили утвердить»
А почему результат их работы при этом часто бесплатен?

Потому что пользователи думают, что они потребители этого результата, а не товар.

Потребители — товар программиста? Извините, но не понятно.

Потребители смотрят рекламу, за которую платят рекламодатели. Т.о. софтверная компания продаёт внимание пользователей рекламодателям.

Какую рекламу вы видите, например, при использовании google docs? Телеграма? Eclipse?

тут давеча фильм вышел — "Социальная диллема". Вот вам бы его посмотреть.

НЛО прилетело и опубликовало эту надпись здесь
Собрали статистику. Чем зарплату платят программистам, презентациями?
НЛО прилетело и опубликовало эту надпись здесь
Статистику же не просто собирают, чтобы любоваться. Если говорить про гуглы/яндексы, то все эти Воллмарты, Амазоны и прочие ЛуиВиттоны покупают у онлайновых сервисов данные о потребительских интересах за вполне себе весомые деньги.
Чем зарабатывает Телеграм в свете того, что TON не взлетел — вопрос открытый. Но чудес не бывает, это же не благотворительный проект, какая-то монетизация у него будет.
Eclipse живет на деньги спонсоров. Причём спонсоров, обильно продающих коммерческие решения, как железные, так и софтовые — Oracle, IBM, SAP.
Замечательно! А почему это работает только для ПО? Можно отдав свою статистику Воллмарту, Амазону, ЛуиВиттону без посредника получать их товар бесплатно? Ведь они сейчас её покупают, плюс тратятся на обработку.
Хм. Ну им-то не ваша статистика нужна, а ваши деньги. А статистика — это просто информация о том, с какой стороны к вам лучше зайти, чтобы больше денег собрать.
Ваши данные — не статистика. Данные миллионов — статистика.

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

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

Как только сможете дать Амазону или Воллмарту статистику, получите от них деньги или может на бартер договоритесь
Для грубой прикидки

Ваши данные стоят где-то 1-5% стоимости товаров что вы покупаете (размер скидок по картам лояльности или кешбекам). Предположим, что это 5 рублей в день при тратах 500 рублей в день. Это стоимость данных для самого магазина (не считая системы сбора, хранения и анализа).

Вот тут и вырисовывается рынок, когда мы продадим данные миллиона пользователей по 1 рублю в день
Сбор данных в интернете требует постоянных усилий, потому что идёт война защиты и сбора. Собирать напрямую в магазине не проще? И почему фонды спонсируют разработку ПО и раздают его бесплатно, но не производство хлеба или колбасы для бесплатной раздачи и сбора данных? Могли бы шильдики с рекламой на нее клеить.
Собирать напрямую в магазине не проще?

И что вы соберёте? Ценность данных возрастает при росте их объёма. Стоимость знания о том, что вы покупаете шампанское в рандомные дни, равна нулю. Стоимость знания того, что перед покупкой шампанского вы переписываетесь со своей любовницей, «бесценна».
Потому что себестоимость лишней копии ПО ничтожна, в отличие от себестоимости палки колбасы.

Почему не работает? Все эти акции формата "заполни анкету и выйграй подарок", скидочные карты, программы лояльности, мобильные приложения магазинов, etc — это вполне себе обмен каких-то ништяков на ваши данные.

Замечательно! А почему это работает только для ПО?


Кто сказал «только для ПО»?
Вот вы пришли к… не знаю ЛуиВиттону как постоянный покупатель, получили скидочную карточку и теперь он не тратится на рекламу вам, а просто даёт вам скидку… 1.5-2% от того, что потратил бы на привлечение ;)
Вы получили ПО бесплатно. Каждую новую версию — тоже. Это такие же затраты на разработку, покупку средств разработки. Почему же ЛуиВиттон 1% скидка, а ПО, разработку которого ведут высокооплачиваемые специалисты, бесплатно?
НЛО прилетело и опубликовало эту надпись здесь

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

Вы бы платили разработчикам раздавая результат бесплатно? Как долго? ОК, есть войны за завоевание рынка, а дальше? Отсутствие конкуренции и деградация после того, как остался один выживший?
Ваш вопрос слишком общий, для начала хороши бы понять чью роль на себя мне нужно примерить :)
А так, в общем, я бы занимался монополизацией рынка а конкуренцию бы устраивал уже внутри своей компании (по сути некоторые гиганты этим и заняты, на мой взгляд). Ведьлюди могут разрабатывать любое по, главное чтобы оно работало в моей операционной системе, запущенной на моём железе и использовало мою СУБД, и не за бесплатно и не могло быстро срулить :)
НЛО прилетело и опубликовало эту надпись здесь
Вы бы платили разработчикам раздавая результат бесплатно? Как долго?

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

Очень много хайпа в IT, фреймворки и прочее — это по большей части отговорки, в других профессиях люди учат действительно сложные вещи и не ноют, а здесь «ой, у нас новый фреймворк, нейронов в мозге мало». Проблема в низкой квалификации, лени, и не желании повышать свой уровень и развиваться, ибо «а че если мне 300К за перекладывание байтов из базы во фронт платят, можно и дальше новый фреймворк ковырять и ныть на хабре».
Про то, что большинство программистов делают перечисленные ошибки, я согласен, а вот насчет остального…

Сколько по вашему разработчик должен тратить личного времени на самообразование в свободное от работы время, чтобы не считаться ленивым? По 500-1000 неоплачиваемых часов в год на самообразование мне кажется тратит каждый второй.
Насчет развития — если человек развивается в направлениях, которые не относятся к работе, это тоже лень?)

Вообще, это работа нужна для того, чтобы улучшать качество жизни, а не жизнь нужна, чтобы улучшать качество работы)
Просто так сложилось что даже низкокачественная слепленная фиг пойми как система даёт бизнес эффект, успешно автоматизируя / развлекая / etc.
Там где в других областях требуется длительное обучения фундаментальным вещам, зрелость людей в профессиональном и личностном плане и т. д. разработка софта всё прощает. Научился делать hello world и го в продакшен фигачить.
Это не синдром самозванства, это и есть low skill, просто cпрос на этот low skill превышает предложение, это не делает low skill чем то другим.
Ну, я не в курсе, где спрос на low skill превышает предложение. Может в низкобюджетном фрилансе или совсем мелких конторах, где на готовых скачанных темплейтах простые проекты фигачат. Я знаю десятки компаний в своем городе, но ни одной такой.
Возьмем для примера веб-направление. Только фронт, без бека. Самый простой способ новичку устроиться в какую-нибудь компанию — пройти отбор на стажера, потом пройти отбор среди стажеров по результатам испытательного срока в 3 месяца. За эти 3 месяца помимо азов (язык, структуры, алгоритмы, базовое понимание ООП), которые уже знал, минимум нужно будет учиться работать с системой контроля версий в команде, таск трекером, знакомится с правилами написания чистого кода, с HTML, CSS, CSS препроцессорами, кроссбраузерной версткой, Bootstrap, Webpack, c NPM или YARN, линтерами, JS, AJAX, REST, Jest, фреймворк-ом. В качестве фрейморка возьмем, например, React. Тогда к списку добавляется JSX, Redux, Redux Saga или Thunk, Reselect, React Router, какой-нибудь плагин для форм, плагин для таблиц. И вот это минимум начинающего джуниора за зарплату где-то в 30к.

Не буду отрицать, что для перекидывание данных с бека на страницы — это перебор. Но, так уж вышло. Чтобы работать фронтендером в какой-нибудь компании, сейчас нужно знать хотя бы это.
… а потом они говорят что фронтэнд не переусложнён, когда в подавляющем большинстве случаев достаточно было бы просто html + css (и иногда ajax из чистого жса, если действительно нужна динамика)
пользователю уже не достаточно просто сухих страниц с информацией, он хочет интерактивности, платой за которую является весь тот ворох технологий, который выше перечислили.

точнее пользователю нужна интерактивность -> разработчик не хочет страдать от лапшевидного кода и императивного управления dom (плюс на него давит бизнес «фича нужна была неделю назад») -> разработчик берет более удобное -> вес итоговой сборки больше, выполняется на клиенте дольше -> пользователь мирится с тормозами в обмен на интерактивность
Ну, я не в курсе, где спрос на low skill превышает предложение. Может в низкобюджетном фрилансе или совсем мелких конторах, где на готовых скачанных темплейтах простые проекты фигачат. Я знаю десятки компаний в своем городе, но ни одной такой.

Ну я работал программистом (в основном на C++) вместе с кусочками дата сайентиста.


Контору, где я мог бы по полной применить свои навыки плюсов, пришлось отдельно искать (и на 100% я не был загружен даже в том месте, которое в итоге нашёл). И это, кстати, была не крупная контора уровня фаанга, а мелкая тусовка HFT-шников на десяток программистов и десятка три трейдеров-аналитиков. Среднее собеседование в околофаанг — «напишите свой auto_ptr».


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

Если бы сидели за делом только high skill профессионалы, у вас был бы мир супер дорогой разработки, и кучи нерешенных проблем, большей части веба и приложений не было бы, потому что умные ребята вместо того чтобы сделать инструмент (архитектуру, абстракцию, либу, фремворк) снижающий порог входа и стоимость разработки — делают фичи, которые нужные здесь и сейчас. А у бизнеса никогда почти нет времени и денег на исследования, им лучше чтобы 10 идей попробовали, вот только те кто понял это и начали делать так, чтобы потом 10 идей эти не пришлось с 0 писать.
Весь бизнес мог бы помолчать и многое простить программистам как профессии, за то что есть opensource который вобще не про бизнес, но в итоге решает его задачи. И что-то я не вижу примеров подобного в других областях где


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

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

По 500-1000 неоплачиваемых часов в год на самообразование мне кажется тратит каждый второй.

У меня есть впечатление, что гораздо меньше. Даже 500 часов в год — это уже 10 часов в неделю вне работы. Большинство людей, с которыми я имел честь работать, не тратят столько времени. Да и на хабре так часто рассказывают про семью-детей-хобби-вне-работы, что не верится, что люди тратят много времени вне работы.

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

в других профессиях люди учат действительно сложные вещи и не ноют

Интересно узнать по каким критериям вы судите, что действительно сложно, а что нет? В каждом ремесле есть свои нюансы и сложности и всегда есть чему учиться. Даже в той же верстке. А еще интересно узнать, с чего вы взяли, что эти люди не ноют?

— делают ненужную оптимизацию не там где узкие места а потому что «ну это же не оптимально так писать
— страдают НИХ синдромом


с этим согласен

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

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

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

Редко встречал ноющих ученых или ноющих бизнесменов.

Вы то кем работаете?


организовать коммерчески успешное предприятие.


Не так и сложно. ИП можно открыть бытовой химии или кормов для животных. Будет успешно, но не так много денег.

организовать коммерчески успешное предприятие. Не так и сложно. ИП можно открыть бытовой химии или кормов для животных.

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

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

Или наоборот, думает всю жизнь "это не моё", пока не приспичит.

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


Читал/слышал об успешных предпринимателях — сколько у них было неудач.

Лично знаю про родственницу — бултыхалась в бизнесе с переменным успехом лет 20.

Куча прогоревших проектов. Квартиру, заложенную под кредиты под бизнес, отдала банку. Жила в съемных. На старости лет это неудобно.

И вот спустя 20 лет усилий — очередной её бизнес-прожект выстрелил. И как выстрелил! Квартиру себе новую купила (без ипотек) за полгода.

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

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


Она смеется над вами с берегов Испании, где у неё сейчас домик. Один из домиков.

Ключевая особенность для бизнеса — настойчивость.

Это вам и Роберт Кийосаки подтвердит.
У него там так и написано хочешь быть богатым — тебе нужна «железная жопа». Сидишь и занимаешься бизнесом. Делаешь как бы не было лениво, нудно, грустно…

Сначала вы написали про квартиру без ипотеки, потом это уже стало "смеётся с Канарских островов", потом это стало "один из домиков на берегах Испании".
Вы там определитесь, пожалуйста, где живёт ваша родственница.
В любом случае, вы сами написали, что в её успехе был сильный фактор случайности – "спустя 20 лет очередной бизнес выстрелил".

Сначала вы написали про квартиру без ипотеки, потом это уже стало «смеётся с Канарских островов», потом это стало «один из домиков на берегах Испании».


Я привел пример скорости роста её дохода после удачи.

Или, когда вам выпадают деньги, вы покупаете только ровно одну вещь, пусть и дорогую, и на этом останавливаетесь? Несмотря на то, что бизнес работает и деньги капают?

В любом случае, вы сами написали, что в её успехе был сильный фактор случайности – «спустя 20 лет очередной бизнес выстрелил».


Ну как случайность…
Если опустить руки через 19 лет — можно сказать, не повезло.
А если стараться 20 лет, то это уже не одна случайность. Но и ваша настойчивость.

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

Продажа книг и тренингов нереальное предпринимательство?

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


Не-а.
Она решила на пенсию уже пора.
Денег хватит до конца жизни.
И детям тоже.
Сейчас бизнес передан в руки сына.
Она отдыхает.
Ну и советы дает иногда.

А сколько подобных "бизнесов" не выстрелило?

А сколько подобных «бизнесов» не выстрелило?


Это совершенно нормально.

Если вы хотите гарантий — то вам не в предпринимательство, а именно что в работу по найму. Гарантирована зарплата.

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

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


И они, что-то бубня, водили мышкой по экрану, добавляли точки, проводили новые линии и добавляли буквочки.


Я минут пять смотрел на эту магию, а потом спросил "Ребята, как вы в этом разбираетесь?".


Они посмотрели на меня и спросили: "А как ты в том, как делать сайты разбираешься? Мы вот попробовали и нихрена ваще не поняли".


Я ответил: "Ну там же все просто..."


"Так и у нас всё просто", ответили мне ребята и попробовали объяснить....


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


Такие дела.

Да нет, в прикладной геодезии действительно не так много сложного, и практикум по топографии студенты сдают уже после первого курса. Там не требуется ничего такого, с чем программист или, шире, инженер, не сможет разобраться. Помню, вел переписку по работе с субподрядчиками, пытаясь доказать, что у них ошибка в каталоге координат. На том конце провода уже скатились до доводов вида "я 30 лет в геодезии!" (дословно), но еще через пару итераций признали ошибку и выслали исправленный вариант.


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

Кхм, простите, а где надо заниматься высшей геодезией? А чего офис не угодил? Ну, вот, скажем, если председатель РАН сидит в офисе – он тоже ерундой низкопробной занимается, получается?

Вот так и знал, что кто-нибудь прицепится к словам. По-моему, из контекста с высокой долей достоверности следовало, что автор комментария общался именно с прикладниками.

Простите, а программисты в офисе прям все сложное делают? Сложное делают единицы — основная клепает простые формочки :)

Там не требуется ничего такого, с чем программист или, шире, инженер, не сможет разобраться.

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


Ну и, если каталог координат еще постижим разумом программиста/инженера, то "как нарисовать топографический план на основании данных трех топосъёмок" — тайна тайн. Даже при наличии софта.


Этому, всё таки, пять лет учат.

Увы, но вот как раз-таки этому не учат. Это искусство, которое постигают на практике. Но тут дело такое — каждый исполнитель может свести данные по-своему, и уровень мастерства определяется степенью правдоподобности: углы у зданий прямые, горизонтали лежат ровненько и не пересекаются и т. д. Здесь нужен тренированный глаз и практика, но какой-то фундаментальной сложности нет. А каталоги координат наоборот — на вид цифры и цифры, что в одной системе координат, что в другой, но поскольку вся топосъемка опирается на них, то маленькая ошибка в каталоге может иметь очень большие последствия потом, когда результаты съемки не будут сходиться.

Проработал три года геодезистом после пары лет работы эникейщиком/сисадмином/немного программистом после института в геодезической конторе.
Двух- трехкратное увеличение зарплаты занесло меня на путь геодезии.
Могу сказать, что все это становится просто после пары месяцев "вкатывания". Нет там ничего сложного, кроме горы всяких СНиПов.
При этом я единственный писал точки съёмки в память тахеометра и скачивал их потом с тахеометра в рабочий софт, а не писал их на листочке и перебивал вручную. Разобрался и научил других работе в RTK на GPS, написал кучу полезных скриптов для автокада и освоил высотную съёмку с формированием правильных чертежей.
Это всего лишь подход, когда ты стремишься понять, что ты делаешь, а не запоминаешь последовательность нажатия кнопок.
Все как в программировании: самообразование, гугл, обдумывание. Никто из коллег этим себя не утруждал. И профильное образование им не помогало.


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

Ну разумеется :)


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

Байты перекладывать — легко. А, к примеру реальную научную статью написать и привнести что-то новое (да хотя бы просто понять чужую)

Тут момент очень важный, между «Байты перекладывать» и «научную статью написать» (10% всего IT), остается как раз «да хотя бы просто понять чужую» — 90% спроса и предложения на рынке труда.

К сожалению по незнанию у нас очень много людей, которые еще раз симфонию Баха сочинили. С одной стороны хорошо что есть соображающие люди, с другой стороны сними невозможно работать. И уж совсем плохо когда прописные истины выдают за «творение твоего гения». И те и другие разбавляют 90% подходящих кандидатов и работодателей.
«ой, у нас новый фреймворк, нейронов в мозге мало»

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

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


А, к примеру реальную научную статью написать и привнести что-то новое (да хотя бы просто понять чужую) — сложнее.

Привнести что-то новое — сложно, а статью написать — легко. Даже цитируемую статью написать легко.


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


Стыдоба.

Под написать статью я имел ввиду реальный SOTA с новизной, а не то что у нас там принято.

Но современный мир устроен так, что на SOTA с новизной всем плевать, а не плевать на публишабельность.


Скрытый текст

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

Никому не плевать. Полезную новизну сделать сложно — нужно выбрать правильное направление куда копать, упорный труд, хай скилл, да ещё и везение. А признание и зачастую внедрение получают достаточно быстро. Недавние (условно) примеры из CS — CNN или Attention, из биологии CRISP/CAS, да и в других областях тоже прогресс есть. Только двигают его не перекладыватели байт а настоящие ученые.

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


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

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

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

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

Мне кажется, сложность в IT в том, что здесь приходится иметь дело с колоссальным объёмом колоссальных абстракций. Какой-нибудь, скажем, химик-технолог может знать целую вселенную про производство бздюлек из полимергептилфреона, но там есть изрядная, скажем так, наглядность (не путать с визуализацией), логичность, прямота и линейность знаний и массивов информации. Тут же – абстракция на абстракции, абстракцией погоняет. Математики ближе всех, как мне кажется.

Математики ближе всех, как мне кажется.

Вот как бывший математик, возражу, в программировании крайне мало общего с математикой. Программирование по духу куда ближе к современной электротехнике или чему-то подобному. Куча всяких разнородных финтифлюшек от разных вендоров, причем от одного вендора обычно друг с другом стыкуются, а от разных — как повезёт, но нередко приходится обрабатывать напильником. И конечный результат надо набирать из этих финтифлюшек, соединяя их нехитрыми алгоритмами.
В программировании с математикой бывает по-разному, и есть технологические ниши где ее предостаточно (вот например то, что будет в ближайшем мажорном релизе GHC — arxiv.org/pdf/1710.09756.pdf). Там где ее больше, интерфейсы страдают от плохой согласуемости меньше. Проблема в том, что в индустриальном программировании математически-ориентированный подход к решению бизнес-задач, к сожалению, считается плохим тоном и элитизмом, потому что дефолтный Engineering Manager мыслит категориями «мало кто осилит» и «если Васю-математика собъет автобус, нам будет дорого нанять десять других математиков, чтобы во всем разобраться». Проблема во-многом надуманная и раздутая до размеров слона, но такова реальность индустрии.
В программировании с математикой бывает по-разному,

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

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


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

А разве есть такая проблема? Простой и понятный код, решающий какую-либо задачу, и вписывающийся в требования по производительности, ресурсоёмкости, всяко лучше сложного и непонятного кода, решающего ту же задачу.


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

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

Классический пример — бухгалтерия. Это простая фиксация фактов и арифметические операции, в основном, сложение.


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

Ну так компиляторы — сами по себе в какой-то мере наукоёмкая предметная область, как и движки СУБД, например.
Если за критерий простоты мы берем легкость с которой случайный человек с улицы читает некий код, то даже среднее по индустрии формошлепство будет слишком сложным процессом

Давайте возьмем критерий, имеющий практичную ценность: легкость, с которой случайный программист с улицы читает некий код. Этот критерий вполне объективен и логичен.
И математические абстракции нам в этом помогут.

Уверен, что нет. Абстракции — это не средство от сложности, а лекарство от сложности. Ну т.е. имеют рекомендованную дозу. И если сильно переборщить, будет тяжелое отравление.
Сложение в бухгалтерии тоже бывает нетривиальным. Что с чем можно складывать? В какой системе счисления работает валюта данного экономического региона (не везде она десятичная) и как нам конвертировать транзакции из валют других стран? Да и сам учет в двойной записи подразумевает, что в этой предметной области нужно уметь отделять множество правильных последовательностей операций от множества неправильных последовательностей, которые несут в себе финансовые издержки для бизнеса.

Я вам могу достаточно уверенно сказать, что ни одной из перечисленных вами проблем в бухгалтерии нет вообще ни в каком виде :) Не существует учетных систем, которые работают не с десятичными системами счисления, равно как и не существует потребности в них. Не существует вопроса, как конвертировать транзакции из валют других стран, т.к. правила конвертирования валют регламентированы. Если даже повезло работать в стране, где нет жесткого государственного регламента, у вас все равно будет или МСФО, или корпоративный регламент.
Как нам закодировать эти множества максимально точным образом и возможно ли это в принципе — это вопрос,

Вот это замечание я вообще не понял. Любой учёт, и бухгалтерский в том числе, это просто фиксация фактов, в их оригинальном виде. Кодировать эти множества надо так, как есть, там нет никаких вопросов и недопониманий, ну кроме возможных расхождений в законодательстве вида «Амортизацию сепулек стоимостью от 5000 рублей отражать на счете 0245», и в другом подзаконном акте «Амортизацию всех сепулек необходимо отражать на счете 0250». И вот думай, как тебе правильно её отражать. Но математика-то тут вообще не причём.
Я вам могу достаточно уверенно сказать, что ни одной из перечисленных вами проблем в бухгалтерии нет вообще ни в каком виде :) Не существует учетных систем, которые работают не с десятичными системами счисления, равно как и не существует потребности в них. Не существует вопроса, как конвертировать транзакции из валют других стран, т.к. правила конвертирования валют регламентированы. Если даже повезло работать в стране, где нет жесткого государственного регламента, у вас все равно будет или МСФО, или корпоративный регламент.


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

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

Для российского — Центробанком РФ. Учитывать и тугрики, и австралийские доллары в бухучёте РФ вы будете в рублях. Да и в любой другой бухгалтерской системе у вас будет базовая валюта, в которой будет вестись учёт.
И вот в холдинге расчет оптимальных алгоритмов (счетов в данном случае) списания это вполне себе поиск экстремума функции численными методами (а с НДС все веселее).

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

Я это прекрасно понимаю, а ещё в бухгалтерии бывают очень важны софтскиллы, владение законодательством на уровне юриста и так далее, но вот математика там нужна на уровне простой арифметики, и не выше. Что-то посложнее на предприятии есть, но это уже управление запасами, логистика, планирование, а не бухгалтерия.
Эээ, вы точно это когда-то делали?
бл*буду! и были вещи и посложнее: свести к минимуму НДС, прибыль, распределение кредиторских и дебиторских задолженностей и распределения активов у участников холдинга на ограниченном железе за очень ограниченное для таких задач время при расчете сотен тысяч документов. Вы то думаете что первичку принесли и это «незыблемое дано». А первичку то можно сгенерить, и не один раз. Бумага терпит. Но это, впрочем, не главное.

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

UP: и за наличие таких вот формул по счетам, позволяющим получить итоги пусть хоть и с приблизительной точности кое кто в холдинге где вся первичка между участниками генерится в целях оптимума прибыли довольно много бы дал. Потому что одно дело прогнать «простыми операциями, в основном сложения» пять итераций на имеющимся железе и выбрать из них оптимальную, или сгенерить всю прикидочную матрицу возможных вариантов документооборота по прикидочным же формулам и выбрать для конечного варианта лучшие условия. Это был бы уже следующий уровень управления/планирования.
бл*буду! и были вещи и посложнее: свести к минимуму НДС, прибыль, распределение кредиторских и дебиторских задолженностей и распределения активов у участников холдинга на ограниченном железе за очень ограниченное для таких задач время при расчете сотен тысяч документов.

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

Как и любой человек, который не раз автоматизировал отечественные предприятия, я ничего подобного не думаю, естественно. Но оно в общем-то тоже без математики обычно делается :)
(вот например то, что будет в ближайшем мажорном релизе GHC — arxiv.org/pdf/1710.09756.pdf)

Тут довольно иронично, что это достаточно прикладное описание, и до хардкорной линейной логики а-ля Жирар со всеми этими coherence spaces ему далеко.


По крайней мере, папир на линейный хаскель легко читается перед сном, а P&T лично я с первого захода не осилил — матана не хватает.

Собственно, посыл был именно в том, что с математикой в программировании по-разному, и это даже не доменная область, а тулинг общего назначения. Кто-то будет это читать перед сном и считать это беллетристикой, кто-то будет рассказывать что ничего кроме simple haskell не нужно, а кому-то дженерики не нужны, потому что кодогенерация.
нам будет дорого нанять десять других математиков, чтобы во всем разобраться». Проблема во-многом надуманная и раздутая до размеров слона, но такова реальность индустрии


Не так. Сейчас нанимать нынешних monkey coders — дорого. А вот нанимать математиков на их место будет ОХ… О ДОРОГО. Так что дилемму эту бизнесы, скорее всего очень хорошо понимают.

Зарплата аспиранта среднего американского вуза — 25-30к в год. Зарплата среднего софтваре инженера зависит от города, от каких-нибудь 40-50к в год в Усть-Дикхединске в Оклахоме (где, впрочем, и вузов нет) до минимум 200к в год в Долине или Нью-Йорке.


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


Наверное, дело не в дороговизне специалистов, а в том, что это всё нафиг не нужно, и фигак-фигак-продакшен-дривен-девелопмент оказывается на порядки быстрее всего этого матана.

Наверное, дело не в дороговизне специалистов, а в том, что это всё нафиг не нужно, и фигак-фигак-продакшен-дривен-девелопмент оказывается на порядки быстрее всего этого матана.


[в королевском научном обществе]
— А нафига нам нужно это ваше «электричество», господин Фарадей?
— Однажды вы начнете брать с него налог, сэр

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

Ну, если честно, тут средний аспирант не сильно уступает среднему инженеру, увы.

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


Чё-то вы преувеличивайте: уже как минимум отдельная профессия по апгрейду и даунгрейду на целевой машине (админы, DevOps).

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

Совместная разработка — это всего лишь несколько навыков как вести разработку в разных ветках и не ломать код коллег. За неделю разберетесь.

Матан это матан. После того как математические модели построены, их еще нужно переложить в код, а после увязать с бизнес логикой, которая вокруг этой модели крутиться.
И аспирантов, я уверен, нанимают, чтобы что то особо сложное построить.
Во-первых, человек абстрактной науки привык именно что «решать» проблемы, удовлетворяя личное любопытство за счет платящей стороны, а не get things done, что обычно подразумевает бизнес. Во-вторых, с таким подходом срок выполнения работ становится эластичней латексного изделия, что в итоге приведет 100% к просеру и по срокам и по деньгам. Так что это будет именно что супердорого и астрономически долго. Примерно как чайной ложкой рыть Беломорканал.
Куча всяких разнородных финтифлюшек от разных вендоров, причем от одного вендора обычно друг с другом стыкуются, а от разных — как повезёт, но нередко приходится обрабатывать напильником. И конечный результат надо набирать из этих финтифлюшек, соединяя их нехитрыми алгоритмами.

А что, в математике не так же? Разве что "финтифлюшки" почти все абстрактные.

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

Разбить трубопровод на куски, за каждый кусок назначить ответственного, разобраться с 30-ю сторонними потребителями и вариантом их подключения, в идеале свести все к единому стандарту фитингов, новых абонентов так же подключать стандартными фитингами. Схему трубопровода отрисовать и держать в доступном для монтажников месте, по мере роста абонентов — актуализировать.
Мне кажется, вся магия начинает пропадать?
А теперь добавьте сюда то, что у трубопроводчиков нет запасного трубопровода в теневом городе. У них нет возможности "откатить" новые подключения до лучших времен.

На словах-то оно всё очень просто…
Разбить трубопровод на куски, за каждый кусок назначить ответственного

Вот на этом этапе возникнет первая трудность (точнее, после этого этапа) — каждый кусок трубопровода в итоге будет иметь разную пропускную способность, разный материал, разные фитинги. И пока вы не пообещаете расстрел за несоблюдение стандартов, которые описаны в 250-страничном талмуде, всё везде будет разное.
новых абонентов так же подключать стандартными фитингами

Каждый новый абонент будет приходить к вам со своими хотелками, где будет свой, уникальный дизайн фитинга, пропускная способность трубы шириной с Амазонку, ну и по мелочи — захочет получать прямо бензин (если у вас нефтепровод) прямо на выходе из трубы.
Схему трубопровода отрисовать и держать в доступном для монтажников месте, по мере роста абонентов — актуализировать.

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

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

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

Вот это и есть ад разработки.

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

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

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

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

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

Посмотрите на застройку новых районов, когда квартиры начинают продавать еще на этапе котлована, потом вносят кучу изменений в проект по мере постройки дома.
Посмотрите на сети ресторанов быстрого питания и как они разворачиваются в городе, бывает что не успев открыться — они уже закрываются.
Посмотрите на сети интернет провайдеров в 2005-2010 годах, они так же росли без плана и с ежедневной корректировкой и переделкой.

Вы ошибайтесь со скоростью внесения изменений на несколько порядков.

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

Просто приведите мне пожалуйста пример в любой из упоминаемых вами индустрий аналога понятия «пивот», когда за один год ресторан привращают в пивоварню, затем в завод по производсту амиака, а затем в лабораторию по производству вакцин.

Это примерно тот уровень изменений архитектуры, который ожидается бизнесом от команды разработки в ИТ.

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

Просто приведите мне пожалуйста пример в любой из упоминаемых вами индустрий аналога понятия «пивот», когда за один год ресторан привращают в пивоварню, затем в завод по производсту амиака, а затем в лабораторию по производству вакцин.


Плохая аналогия подобна котёнку с дверцей в боку.

Ты забываете о важном отличии:

Если в работе ресторана есть множество материальных вещей, то с программой, как с продуктом мысли — всё проще.

Из шашлычной вы не сможете сделать рок-площадки банально из-за нехватки площади. Это физический параметр. И только в фантастике помещение может быть больше внутри, чем снаружи.

В программировании начать обрабатывать в 10 000 больше данных вам может позволить, к примеру, простое включение кэша на определенном уровне обработки данных внутри вашей программы.
Извините, но вы апеллируете мне моими же аргументами. Я выше писал:
Но сравнивать разработку с проектированиям трубопровода крайне не корректно, поскольку доступность внесения изменений в ПО гораздо ниже, чем в трубопровод, и бизнес ожидаемо пытается выжать из скорости разработки максимум, а это значит что изменение требований будет настолько часто, насколько это позволяет команда разработки.
Не я начал вереницу плохих аналогий. Я просто утверждаю, что любой бизнес пытается выжать ту скорость изменений, которая конструктивно возможна. Для разработки ПО это несравненно более высокая скорость, чем для других бизнесов, и потому проводить аналогии между проектированием ПО и проектированием водопровода или сети ресторанов просто не корректно.

Это просто совершенно разный класс проблем. В проектировании ПО в основном цена ошибки значительно ниже, но и размерность задачи (количество параметров, которые необходимо принимать во внимание) на порядок выше.

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


Да это банальная нехватка людей-профессионалов.
Джуны-разработчики сейчас копейки уже зарабатывают, ибо происходит насыщение.

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


Это касается только специалистов высокого уровня.

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

В итоге через 10 лет команда, проектировавшая разводку воды по деревне занимается (условно) логистикой в масштабе Земли, с применением всех видов транспорта, учетом погоды, изменения цен и дипломатических отношений, с применением искуственного интеллекта, арендуя транспорт у поставщиков. Это буквально то что происходит с разработкой – то, что еще 10 лет назад делалось вручную сеньйорами, сегодня автоматизировано, а серьйоры отвечают за оркестрацию более высокого уровня.
То есть по вашему джуны и мидлы тупо пишут код и вообще мозг не включают?


Вы считаете, что мозг не был включен 15 лет, а потом так резко переключателем щелкнули — и ты сразу архитектор за мега-бабки?

Что можно по щелчку вот так сразу научиться?
Я считаю что мозг был включен всегда у всех разработчиков. Я говорю, что как только мы достигаем точки «вообще не ваша проблема как придумать такую архитектуру» тут же добавляется еще один уровень абстракции, из-за которого «думать» – все еще «наша проблема», даже если мы – джун или мидл.
То есть по вашему джуны и мидлы тупо пишут код и вообще мозг не включают

Судя по нескольким проведённым мною собеседованиям последнего времени, обычно заканчивавшимся — со стороны кандидата — словами "я поискал что-то подобное на %любимый_клон_stackoverflow%, не нашёл, так что извините за беспокойство, до свидания" — я не уверен, что там вообще есть, что включать.

… и тут я вспомнил Livestreet, который изредка приходится допиливать.


Его бы и выкинуть на свалку, но альтернативы нет.

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

Но по какой-то причине ни первого, ни второго не происходит.
1) ЗП у проектировщиков энергосетей / коммуникаций такие же как и разработчиков. Даже у монтажников (тех кто потом по разработанной схеме всё это прокладывает) не сильно меньше (если брать не СНГ а, к примеру Европу).
2) Сложность и оплата хоть иногда и коррелируют друг с другом, но далеко не всегда, я думаю вы сами сможете быстро вспомнить примеры профессий где хорошо платят и сложности вообще никакой нет, и наоборот.

Да, врачи тоже удивляются такому раскладу вещей.

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

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

Нет, это про NIH-синдром. "Not invented here"

а че если мне 300К за перекладывание байтов из базы во фронт платят, можно и дальше новый фреймворк ковырять и ныть на хабре»


Все так любят употреблять это выражение, как будто это что-то простое. Ученые вообще вон какие-то загогулинки на доске и в тетрадки рисуют, то ли дело грузчик, вот он тяжести таскает, да? Нужно знать тысячу нюансов: правильная ли тут архитектура, не заблокирую ли я тут транзакциями что-нибудь? А если вон тот сервис отвалится, то продолжит ли мой работать? А какое у меня будет количество запросов, может сделать шардирование? А будут ли у меня аналитические данные, может предусмотреть партиционирование? И всё это ради банального CRUD
делают звездолет вместо простых решений

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

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

И это делают не джуны бывает, просто подумать о том чтобы подсказать серверу как данный запрос обрабатывать (после того как первые n подходов дали переполнение temp-а в много гигабайт) и немного искусственно разделить его на части может потребовать некоторых изысканий (до недели) и при этом может и не дать результатов… :)

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

Да задача решаемая :) в т.ч. в цикле(что видел глазами) :). Отказ… для внутренней разработки это не вариант часто, особенно если задача под требования регулятора.
Про технологии вы сильно усложняет задачи бывают центральные и те которые лишь небольшой кирпичей в системе, основой которой может быть, как пример, корпоративное хранилище данных :)

Так я же сказал, что в рамках нефункциональных ограничений нерешаема, а не вообще. :) Ну работает в цикле 12 часов формирование отчёта для регулятора на хранимках. А просит внутренний заказчик в реалтайме практически его. И готов даже выбить из топ-менеджмента аж 50 или даже целых 100 долларов в месяц на дополнительный сервер специально для этих отчётов

Из реальности: "Эх если бы на хранимках ..." видел по одному запросу на строчку извне с nested loop в плане выполнения по "очень большой таблице" :) а потом серверу не хватает процессоров ...

считают что их код и архитектура красивая, продуманная, крутая и вообще непогрешима, а чужой код и чужая архитектура ужас, кто это писал, как так можно было, руки поотрывать

Притом что свой же код через 3 месяца переходит в разряд «чужой», и только Git иногда может показать, кто тут наследил.

А что программисты сами себе придумывают работу?
Представим две ситуации — бизнес + программист, бизнес + консультант (вот есть кпмг например или ey или Accenture они вполне себе по ИТ работать могут) + программист.
В первом случае сроки даёт программист, и может что-то себе "добавить" во втором будет т.з. и сроки… И вот бизнесу выбирать какой вариант ему "выгодней" и вот в этом месте у небольшого бизнеса выбор не богат...

— Почему программисты так много получают?
Чтобы хватало на психотерапевта.

У сильного всегда бессильный виноват:
Тому в Истории мы тьму примеров слышим...

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

"Работает — не трогай" (тм). Вот они и не трогают…

Проблема в том, что ИТшники в массовом сознании стали чем-то типа официантов, водопроводчиков или уборщиц.

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

"Бытовые" редакторы для фото, видео, аудио чем-то схожи с играми по юзкейсам. Тут скорее не то, что обслуживание других секторов экономики, а уничтожение их "бытовых" сегментов. Соцсети пока не превратились в рекламные/пропагандистские площадки


Профессиональный ИТ-софт (компиляторы и прочий дев-тулинг, администрирование ИТ-инфраструктуры и т. п.) — продукты, создаваемые ИТ-сектором для самого себя. Средства производства средств производства для обслуживания других секторов экономик.

«Бытовые» редакторы для фото, видео, аудио чем-то схожи с играми по юзкейсам.

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

Здесь согласен, про такой софт я забыл.

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

Но продукты сектора «хобби» становятся чистым ИТ-продуктом.

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

Игры компьютерные — это отдельный жанр игр, они не заменяют те же настольные игры.

Потому никакого
превращая секторы традиционной экономики в подсекторы ИТ-индустрии.

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


Э? Почему не было?
В моём советском детстве все это было. Любительское оборудование советского производства.
Где-то на границе 70-х и 80-х отец купил первую кинокамеру.
А станок для нарезки и склеивания кинопленки — до сих пор у меня лежит.
Было и устройство синхронизации звука и монтажный столик с экраном.
Всё так же — советского производства.

В моём советском детстве все это было. Любительское оборудование советского производства.

Я о том, что было не так распространено, как в США. Т.е. если фототехника не была чем-то необычным, то видео занималось очень мало людей.
Я о том, что было не так распространено, как в США. Т.е. если фототехника не была чем-то необычным, то видео занималось очень мало людей.

Ну в нашем маленьком городке, тысяч 100 жителей — кинопленка любительская в продаже была.
И цветная в том числе.
Не занимались, полагаю, потому что это муторно — там даже для черно-белой киносъемки процесс проявки состоял не из 2 этапов как для фото, а аж из 6.

А к эпохи появления уже видеотехнологий, когда пленку не нужно проявлять — видеосъемкой уже никого не удивить было, настолько не редкое явление.

Профессиональный ИТ-софт (компиляторы и прочий дев-тулинг, администрирование ИТ-инфраструктуры и т. п.) — продукты, создаваемые ИТ-сектором для самого себя. Средства производства средств производства для обслуживания других секторов экономик.

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


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

Причём тут более или менее хорошее? Я о том, что нельзя относить ИТ-отрасль исключительно к отрасли, обслуживающей другие отрасли, даже исключить геймдев.

Почему собственно нет? Та же электроэнергетика обеспечивает остальные отрасли довольно универсальным источником энергии, но сама по себе она не производит ничего, т.е. конечный продукт — энергия, которая сама по себе никому не нужна, но которая упрощает производство товаров прямого потребления человеком. Или водоснабжение, сантехника. В этом плане в чем отличие ИТ сектора? Зарплатой в отдельных регионах?

Электроэнергетика тоже производит товары и услуги прямого потребления. Или если я включил свет в комнате, это индустрия энергетики обслуживает индустрию освещения?

Или если я включил свет в комнате, это индустрия энергетики обслуживает индустрию освещения?

А разве нет?

Это я помощью индустрий энергетики и индустрии приборов освещения обеспечиваю себе освещение сам, прямо потребляя у этих индустрий их конечные товары и услуги, не являясь потребителем индустрии освещения (есть вообще такая?).

Конечный продукт освещения это (внезапно) свет…

Так я сам этот свет вот прямо сейчас произвожу для себя. Я — производитель индустрии освещения?

Ну да. Конечное звено. В чем вы видите проблему? Дешево паковать свет в коробки не научились — продают средства производства для обеспечения освещенности на местах. Это нормально.

В том, что вы меня пытается записать в индустрию, производящую свет как продукт. Я производством таких продуктов не занимаюсь, на какой-либо рынок с ними не выхожу.

Когда вы котлеты жарите, конечный продукт какой? Вот фарш это электричество, а лампочка — сковородка.

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

Производство для личных нужд больше не производство?

Производство для собственных нужд не является производством продуктов и такой производитель не является частью соответствующей индустрии. Он является просто конечным потребителем соответствующих средств производства и сырья.

Ок. Тогда лампочка это средство производства, а электричество — сырье.

Если для собственных нужд, то в экономике они превращаются в продукты конечного потребления. Часто это хорошо заметно по НДС — кто платит полностью НДС без возвратов и/или зачёта, тот и потребитель, а не производитель.

Электроэнергетика тоже производит товары и услуги прямого потребления. Или если я включил свет в комнате, это индустрия энергетики обслуживает индустрию освещения?

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

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

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

Если про потребление в каком-то «философском» смысле, то наверное не потребляю. Если в экономическом, то потребляю.

Я про буквально — в чистом виде мне электричество не нужно, только как сырье для устройств.
Сектор ИТ в принципе в очень редких случаях делает продукт, который сам по себе (кроме игр ничего в голову сходу не приходит), чаще — обслуживание других секторов экономики.

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

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

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

Написание игр можно считать "обслуживанием интересов" индустрии развлечений.

MS — часть индустрии развлечения? )

Та самая MS, которая разработчик XBox? Наверно, да.

Как по мне, то она в данном контексте — представитель ИТ-индустрии, покусившаяся на на рынок индустрии развлечения. Где-то она обслуживает её, предоставляя софт, а где-то с ней конкурирует. Как по мне, то типичный представитель ИТ-индустрии, стремящийся на рынке B2B2C избавиться от посредничества второго B не просто войдя в классическую индустрию развлечений как ещё один B2C игрок, а предлагая на нём B2C ИТ-продукт, а не просто продукт, созданный при помощи B2B ИТ-продуктов.


Єто скорее представители классической индустрии развлечения вынуждены становиться частью ИТ-индустрии, предлагая ИТ-продукты конечным пользователям вместо классических.

Єто скорее представители классической индустрии развлечения вынуждены становиться частью ИТ-индустрии, предлагая ИТ-продукты конечным пользователям вместо классических.

Фирма просто расширила свой профиль еще одной отраслью, но не «стала частью новой отрасли». Это ведь не что-то новое в истории.
Иначе если оружейная фирма Штайр в начале 20 века начала производить автомобили, то она стала частью автопромышленности. Но как быть с производством оружия? Она ведь его не прекращала. Осталась она частью оружейной промышленности? Или просто фирма занята в двух отраслях, без того, чтобы стать частью чего-то?

В вашем примере фирма просто занята в двух отраслях, предлагая в них соответствующие продукты, никак не конкурирующие друг с другом. Ну кроме редких случаев, когда покупатель думает "вот есть у меня N шиллингов, лучше купить на них винтовку или автомобиль?"

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

Так и компьютерная игра с программой для создания 3Д-моделей в общем тоже не конкуренты. Связь же такого же уровня — металообрабатывающая промышленность в моем примере или ИТ-сектор в примере с Майкрософт.
Написание игр можно считать «обслуживанием интересов» индустрии развлечений.

Нет, это самостоятельная часть индустрии развлечений. А вот Unreal Engine — уже обслуживание.

А является ли написание игр частью ИТ-индустрии?

А является ли написание игр частью ИТ-индустрии?

Я с этого и начинал — да, является, как исключение из общего обслуживающего характера всей отрасли.
Я пишу про то, что целью ИТ-сектора является удовлетворение спроса других отраслей

Написание игр можно считать «обслуживанием интересов» индустрии развлечений.

Пример в рамках отрасли/индустрии не показателен — там же ничего не видно и не понятно.

Берите конкретное предприятие — и сразу все станет на свои места.

Занимается ли конкретный ИТ-шник обслуживание ИТ-подсистемы конкретного предприятия, которое предоставляет совсем другие услуги/продает совсем другие товары?

Например, торговля продуктами питания.

А вот если это предприятие продает именно игру — это другое дело.

Я бы еще аккуратно подчеркнул одну сторону проблемы. В остальных областях материального производства мы имеем более-менее стабильное «плато технологий». Ну то есть автомобиль, выпущенный 10-20 лет назад принципиально не отличается от текущего (имея в виду железо и собственно ездовые функции). Аналогично, я бы сказал про авиацию, строительство и прочие вещи. В софте у нас идет «планирование от достигнутого». Если сегодня группа разработчиков делает state-of-the-art проект, завтра десять компаний начнут делать его клоны, а через 5 лет проект такого уровня и функционала будет считаться абсолютной нормой. Приведу пример — в 40-х 50-х годах весь бухгалтерский (суммовой и количественный учет) промышленного предприятия (на минуточку, магнитки, КМК, да еще мало ли чего!) делался на счетах. Теперь его автоматизировали. И что, он стал менее трудоемким? Да фиг там — сначала правила бухучета хитровывернули, чтобы предприниматели не скрывали прибыль. Потом (привет кто помнит!) сделали отдельный налоговый учет со своими регистрами и правилами. То есть как только софт и хард позволили легко решать текущие задачи — их (задачи) немедленно усложнили. И это продолжается и продолжается — и конца-края этому не видно… :-(
НЛО прилетело и опубликовало эту надпись здесь
Почему программисты считают что много получают?


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

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

Так сколько времени они тратят на изучение возможности переезда или смены профессии вне работы?

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

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

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

НЛО прилетело и опубликовало эту надпись здесь

Ценность разработчика в организме "динозавра" не только во владении технологиями (новыми, старыми, развивающимися). Можно упорно саморазвиваться, перейти из одной компании в другую с очень похожей технической базой (языки, инструменты), но быть для нее менее ценным и начать приносить реальную пользу как самостоятельный боец только через несколько лет. Ибо теми же инструментами идет моделирование других бизнес-процессов, иные традиции, иные заказчики. Отсюда и повышение оценки долго работающих продуктивных сотрудников. Ибо через какое-то время основным инструментом работы все-таки становится голова (начинает снимать фотограф, а не камера).

НЛО прилетело и опубликовало эту надпись здесь

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


Следить за актуальностью навыков всё же надо.

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

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


Если вы занимаетесь пресловутым дата сайенсом каким-нибудь, то каждый день выходят новые статьи, у которых надо читать хотя бы intro и summary.


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


Я ещё не встречался с ветвью, где можно сесть, сидеть ровно и не переживать за будущее при утрате работы.

Java

Там же вроде тоже какие-то стандарты новые появляются, версии, все дела. Котлин какой-то ещё на пятки наступает.


По крайней мере, у меня сложилось такое впечатление при чтении новостей про новые версии джавы и комментарии к ним.

Давайте будем честны до конца — получая несколько лет такую зарплату и забив на самообразование этот айтишник будет иметь крупные проблемы при попытке найти следующую работу с такой же зарплатой


Не-а.
У меня коллега уже 20 лет работает на PHP.
До сих пор сидит на допотопной версии PHP4, что уже не поддерживается.
JS не освоил (хотя он как бы фулл стек).

И спрос на этого человека опережает предложение.
Скажите, а зачем постоянно регистрировать новые аккаунты? Очень легко узнать по формулировкам и пропагандируемым идеям.

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


Я больше под администрированию, но суть таже. Одно время для мониторинга был популярен zabbix. Но я в него не лез, ибо работал с самописанными костылями. Потом был популярен TICK например. Но я в него не лез, ибо работал с самописанными костылями
В этом году мне потребовалась система мониторинга, посмотрел что там сейчас в тренде, прочитал про prometheus и накатил его.
Много ли я потрел от того что не учил в свое время TICK и zabbix?


За 5-10 лет что ты работаешь, сменится 2-3 технологии "на хайпе". И станут за это время никому не нужными. Потребуется менять работу, подтянешь то что сейчас нужно на рынке.

некоторые другие профессии компенсируют это тем что им нужно учиться с раннего детства.

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

В танцах то?
Возьмите балет. Там возраст потолок. Причем не великий такой возраст.

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

В узком диапазоне, совпадающем с интересами конторы, как правило.


Да и не нужно оно особо после достижения какого-то уровня скиллов.

Нужно, потому что технологии уходят вперёд.

НЛО прилетело и опубликовало эту надпись здесь
Сколько нужно тратить времени чтобы не отставать в каждом из этих языков?

Мне сложно дать минимальную оценку.


Скажем так, я систематически, годами тратил по часу-два в день на пет-проект на современнейших плюсах (чтобы clang из транка надо было собирать для сборки проекта) вместе с ковырянием всяких новых инструментов (от санитайзеров в своё время до профайлера времени компиляции, кажется, в LLVM 8). Плюс к этим двум часам чтение всяких статей-блогов, плюс чтение пропозалов, плюс просмотр записей конференций. И я не уверен, что именно можно было бы сократить без вреда для результата.


И какова вероятность что скажем С++ перестанут использовать до того как он уйдёт на пенсию и что он из-за этого останется без работы?

Околонулевая. А вот вероятность, что C++03 перестанут использовать (или будут использовать в следовых количествах, примерно на одном уровне с коболом) до ухода на пенсию — уже вполне себе ощутима. Особенно если человеку сейчас, скажем, 30, а не 60.


Какова вероятность что он найдёт работу под новый язык так чтобы ему при этом платили как на его старом, где у него стаж и опыт?

Так технологии уходят вперёд даже в рамках одного стека.


Даже какой-нибудь несчастный cmake десять лет назад и сегодня — это немного разные best practices, разные фичи и разные стили.

НЛО прилетело и опубликовало эту надпись здесь
То есть грубо говоря если кто-то найдёт работу, на которой ему позволят один-два часа в день писать что-то полезное на "современнейших плюсах", то этого будет вполне достаточно чтобы не отставать и держаться на плаву?

Да, пожалуй. Ну и там если ещё статьи читать, видео смотреть, вот это всё.


Правда, не получится смотреть по сторонам, но это действительно не всем надо.


Честно говоря я бы не сказал что так уж сложно найти работу на таких условиях.

А я бы таки сказал. Не видел ни одной работы, где в 2016-м году, скажем, разрешали бы писать с -std=c++1z что-то разумное в прод, используя предрелизные версии компиляторов. C++14 в 2018-м году и миграция на C++17 в 2019-2020-м — куда ближе к стандартной практике.

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

Да, будет.


Ну то есть даже если вы решите сменить работу и там нужно будет ну вот совсем актуальную, то в такой ситуации будет не такой уж и большой проблемой догнать отставание.

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


Плюс, когда на основной работе обновляется эта самая версия, я уже её вдоль и поперёк изучил, и поэтому ко мне, как правило, обращаются, чтобы разъяснить моменты, объяснить команде что-то новое, скидывают там код-ревью всякие, чтобы я распространял best practices. Это прикольно, приятно и ведёт ко всяким плюшкам.


А во вторых на большинстве фирм есть какие-то внутренние вещи, на которых как раз обычно и проверяются новые технологии.

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


Ну вот я балуюсь у себя с умным домом. И там в общем-то делаю кучу всякой ерунды просто для себя. Начиная от эмбеддед и кончая UI. Но много оно мне даёт в профессиональном плане? Скорее нет чем да.

Ну а я вот, например, писал код на плюсах и занимался всяким дата сайенсом (и код на плюсах был соответствующий), но при этом параллельно смотрел на всякие низкоуровневые вещи, скажем. И несколько статей о том, как процессор ведёт себя при переходе от исполнения SIMD-инструкций с 128-битными регистрами к 256-битным в зависимости от поколения процессора позволило мне потом на всяком лоу-летенси HFT этим пользоваться и быть полезным.


Или там, не знаю, прочитанная где-то статья про поведение mmap в линуксе позволяет делать адски дешёвое асинхронное устойчивое к падениям журналирование.


Или там, не знаю, чтение блога preshing.com вместе с парой книг позволяет решать задачки на локфри на интервью, хотя я с этим никогда не сталкивался в работе.


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

Но вы будете знать, что такая область есть, и про своё отношение к ней.


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

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

Чтобы прочитать условный cppreference — да, меньше. Чтобы понять, как эти вещи друг с другом комбинируются, и обрести навык их использования — таки больше.


Это как, ну, интегрирование. Понятие простое, а вот научиться эти самые интегралы брать — нетривиально и требует времени и упражнений.


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

Конечно. Но это сужает количество доступных работ.


Скажем так, мне в 2016-м году делали оффер потому, что я уже имел опыт использования C++17 и имел некоторое представление о некоторых вещах, которые могут войти в C++20. При этом компания, в которой я на тот момент работал, только-только перешла на C++11 (или это было там в 2017-м году? не помню точно).


Для того чтобы знать какие области есть совсем не обязательно тратить на это много времени.

Для знания о существовании, да, нужно совсем немного времени. Для того, чтобы попробовать и понять, твоё или не твоё — уже чуть больше.


Да и не так уж часто эти самые новые области появляются.

Но вы не рождаетесь со знаниями про эти области.


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

Не думаю, что со мной сейчас согласились бы взаимодействовать, не знай я ничего в целевой области.

А вот вероятность, что C++03 перестанут использовать (или будут использовать в следовых количествах, примерно на одном уровне с коболом) до ухода на пенсию — уже вполне себе ощутима.


Не страшно.

1) Это не произойдет мгновенно. Даже инерция одного человека велика, а уж инерция групп людей — страшная сила. Изменения будут подавать тебе звоночки долгими годами.
Ты успеешь отреагировать.

2) Перейти на более свежий стандарт не так уж сложно, даже будучи в возрасте и обладая уже не таким гибким мозгом как в юности. Это же не полностью новый язык.
Изменения будут подавать тебе звоночки долгими годами.

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


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

Лямбдочку там написать — да и в какой-нибудь std::accumulate её передать — да. Понять, как применить folding expressions, чтобы код был выразительнее и чище, или как переписать шаблонную наркоманию на constexpr'ах, чтобы было выразительнее и компилировалось быстрее, или как применить концепты, чтобы компилятор выплёвывал не десятки мегабайт ошибок, а всего-то десятки килобайт, или как написать perfect forwarding дженерик-лямбду — это уже чуть сложнее.


Серьёзно, я наблюдал за очень разными людьми в очень разных контекстах.


Да и, говоря о вашей последней фразе — ИМХО C++11 и C++03 — это принципиально разные языки. C++17 и C++11 тоже отличаются довольно сильно.

Да и, говоря о вашей последней фразе — ИМХО C++11 и C++03 — это принципиально разные языки.

И сколько между ними лет? Лет со звоночками «обрати внимание, разберись»?