Ну будем честные, код со всеми этими оптимизациями стал не слишком читаемым и поддерживаемым. Все-таки обычно мы бизнес-код пишем, а не олимпиадные задачи решаем и очки в бенчмарках набираем.
Потом, не только лишь все могут взять и проделать то, что проделывает автор. На рынке не то, чтобы очень много сеньоров, которые хотят в ассемблерном коде ковыряться фулл-тайм.
Насчет серверов. Если уж совсем быть честным, то на сервере мы можем поставить не десктопный корэ-ай-семь, а парочку AMD EPYC по 64 ядра каждый, и тут я даже не знаю, какие силы надо с Эльбрусом выставлять? Сразу ЦОД строить, чтобы сопостовимо было? Про цены этого сопоставления я вообще молчу.
Но даже если предположить, что мы тут хотя бы десктопных проц трехлетней давности пытаемся догнать, то чтобы результаты из статьи как-то заработали, надо еще nginx переписать под это дело, или TensorFlow, или v8, или какой-то еще софт. Будет Сысоев, интересно, nginx переписывать, чтобы на Эльбрусах все быстро было? Вопрос, конечно, риторический.
То есть да, какую-то работу они показывают. Оно даже работает, если завтра в ЦБ РФ запретят поставлять intel/amd/etc, мы сможем закупить контейнер Эльбрусов, установить их и даже получить какие-то положительные результаты (вопросы о производстве пока отбросим). Но это ваще не конкуренция. Это вещь в себе, которая нужна на каком-то локальном рынке решать какие-то локальные проблемы без претензии на технологичность. Это как Москвич в автомобилестроении, жил, пока ничего другого не было, и сразу умер, как появилось. Мы опять идем по этому пути и опять придем к таким же результатам.
Перед тем, как начать разработку ПО обычно выбирают архитектуру.
Ой ли! Современный мир таков, что мы пишем продукт, а потом нам приходит осознание, что какая-то крупная компания выпустила, скажем, M1, и теперь наш продукт нужно собирать на ARM. И хочется, чтобы все проблемы ограничились настройкой тулчейна под целевую платформу. И это, кстати, отличный пример, как новый проц довольно быстро оброс софтом и большей произвоидельностью без таких уж сильных приседаний.
Ну и будем честны, вряд ли в общим случае какой-то разрабочик/компания скажут: "штош, начну-ка я пилить свой новый проект чисто под Эльбрус". Как я уже писал выше, кроме оборонки и некоторой госухи я больше никого не вижу.
А вот труд разработчиков ПО сильно подорожал.
Поэтому Эльбрус сделал платформу, в которой мы должны тратить время разработчика на оптимизации из приведенной Вами статьи? :)
Ну вы только в кучу всех не мешайте, пожалуйста. Хейтили Маска те, кто сейчас Эльбрус восхваляет. А те, кто говорил, что Маск вполне понятно и результативно развивается (что и было), говорят, что Эльбрус непонятно и нерезультативно развивается. SpaceX с 2002 года начала свой путь, и уже по запускам Россию обогнала, а МЦСТ свой путь начал в 1992, но догнать мы не можем даже десктопный процесс десятилетней давности (а уж про массовость и остальное я вообще молчу).
Конечно, делать выводы по нативному исполнению и эмуляции некорреткно, это понятно. Но эмуляция x86 для Эльбруса стратегически правильное решение, потому что есть куча софта, которые портировать не получится, а запускать надо.
Но основное сравнение: это все-таки нативный код для e2k и нативный код для x86.
Свидетели Отечественных Процессоров на Хабр ботов завезли, что ли?
Какой софт каким конкурентам будет проигрывать? Речь у нас про то, что софт под Эльбрус проигрывает по скорости конкурентам Intel, AMD и далее по списку. Рынок не у Эльбруса, чтобы он задавал тренды, если что :)
Под привычную нам архитектуру x86 большинство оптимизации делает компилятор, не разработчик. Эльбрусовский же компилятор за вас не делает ту работу, которая нужна дла VLIW процов. Есть даже инструкция, как с этим жить.
А то, что вы тут пишите про какие-то коллекции и поиски элементов за линию, говорит лишь о том, что вы вообще не понимаете, о чем тут речь и к чему все претензии. Алгоритмы и структуры данных работают одинаково на всех существующих платформах, потому что это математика.
Потому что можно использовать свежие SSE и прочие AVX-512, которые дают сильный буст на математике.
А использование всего оптимизационного добра на e2k хоть и дают сильный буст, но только в рамках их архитектуры - остальным они все равно сильно проигрывают. Поэтому ребята из magma и всех других расчетных софтов вряд ли будут пилить какую-то серьезную поддержку нашей архитектуры, потому что зачем? И отдел стратегического планирования МЦСТ должен это понимать: никакой массовости не будет, никто специально поддержку пилить не будет, значит, большинство кода на платформе будет использоваться as is.
Не очень понял, о чем Вы. Да, Эльбрус имеет бинарный транслятор, но это все-таки дополнительный бонус для историй, когда код под платформы по каким-то причинам пересобрать нельзя. Наверное, разработчиков в первую очередь интересует история, когда код собрать можно.
Ключи оптимизации являются инструментом компилятора, они, естественно, должны быть выбраны максимально эффективно для целевой платформы, но я говорю не про них.
В моем понимании "оптимизация" - это затачивание тестов под конкретную платформу. e2k архитектура подразумевает, что вы знаете о широкой команде, и стараетесь писать код так, чтобы эту широкую команду максимально заполнить для параллельной обработки. Если вы делаете так, вы действительно получаете сильный буст, но проблема в том, что 99.999% кода написано без оглядки на такие архитектуры, а, следовательно, никаких преимуществ вы тут не получите.
Поэтому интересны такие тестовые кейсы:
1) Мы берем любой стандартный бенчмарк и компилим код as is под x86 и e2k и смотрим, какая разница в попугаях. В подавляюшем большинстве это то, на что нужно смотреть, потому что вряд ли люди будут переписывать openssl или какой-нибудь jsoncpp.
2) Пишем максимально эффективный код для x86 и e2k и смотрим, насколько архитектура реально эффективно тащит задачу. Этот кейс ок, когда вы самые ресурсоемкие части своего продукта сразу пишите с оглядкой на платформу e2k. Не представляю, кому это, кроме МО РФ и некоторой госухе, надо.
И я на всякий случай напомню, что VLIW в Intel умер. Да и не только в Intel, были разные идеи сделать что-то похожее, потому как сама идея выглядит вполне себе ок, но на практике оказалось, что писать эффективный компилятор под этой дело крайне сложно, а заставить всех разработчиков быть умными и сразу писать эффектиный код под архитектуру не получилось.
Пользуясь случаем, спрошу: а кто-нибудь подскажет марку светодионых лампочек, который с годами не меняют своих характеристик? Вот чтобы я ее купил, а через 5 лет мог пойти и купить такую же.
Меня жутко бесит, когда через пару лет лампа перегорает, ты едешь в магазин, но точно такой же нет от того же производителя, есть +- 300К, мощность +- 0.5Вт и т.д., в итоге, заменяя одну лампу, получаешь ее в каком-нибудь отличном оттенке, и она мозолит глаза, хочется сразу поменять все. Запас ламп помогает, но полностью проблему не решает.
Есть ли производители, которые с годами стабильны?
Что значит "тесты оптимизированы"? Для разработчика должно быть все по дефолту: взял код, собрал, проверил, отправил в прод. То, что там есть какая-то связь с компилятором - прекрасно, но я же не буду оптимизировать десятки миллионов строк плюсового кода, чтобы они как-то по-особенному стали работать на Эльбрусе. Разработчики процессора это подразумевают, но не уверен, что с ними согласны разработчики софта.
И первая и вторая будут получать зарплату, только первая будет постоянно бегать там где платят побольше, потому что пришла сугубо из-за денег, а вторая пришла потому что ей нравиться это делать/получается
Вы привели очень хороший пример, который как раз в IT работает не так, как вы описываете. Люди, которые в IT часто меняют компании, имеют багаж знаний и умений на порядок больший, чем люди, которые сидят по 10 лет на одном месте (исключения составляют большие компании типа Яндекса, Google и далее по списку, но и там, как правило, люди внутри ротируются, меняя задачи и стек технологии). Так что сеньор, проработавший 10 лет в каком-нибудь КБ не равен сеньору из условного Гугла.
А вот насчёт примера выше с ЗП: почему бы не работать водителем на поставки за 150к, а на оставшейся время пилить любые пет-проеты, вместо того, чтобы пилить какие-то проекты фулл-тайм за 50к? Вот это и есть рыночек.
Сначала подумал, что ууххх, заплюсованная статья-разоблачение, 400+ комментов, будет жара.
Но прочитал статью с улыбкой и сочувствием к автору.
Почти что все, что описано в статье - типичные будни разработчика. Когда бизнес нихрена не может сформулировать, что он хочет; когда неправильный символ в коде можно неделю искать; когда ты копаешь в чужом коде, которому уже 20 лет и автор которого уже, может быть, даже умер; когда документации на внутренние инструменты нет в принципе, и никакое stackoverflow про них ничего не знает; рабочий день, который из 8 часового легко превращается в 15 часовой (мой личный рекорд - 21 час); неадекватные дедлайны и т.д. и т.п. Ну и вишенка на торте - это то, что интенсивное обучение проходит не год, не два, не десять лет, а ВООБЩЕ всю твою жизнь в IT. И это не просто громкие слова, а суровая действительность: новые языки, новые подходы, новые фреймворки, новые языки, новые базы. И в каждой компании все по-разному. Во фронтенде тем более, еще вчера все работали с jQuery, а сейчас уже даже React можно считать легаси. Я бы сказал, что у многих просто происходит перегорание в освоении новых технологии - ну просто уже не хочется браться за что-то новое, потому что этот цикл изучение-использование-выкидывания ты уже тысячи раз прошел.
И вот за все это говно ты получаешь печеньки, кофе, мощный ноут и хорошую зарплату. Кого все это прет, задерживается надолго. Но я скажу, что лет за 15 все сильно поменялось. Если раньше были все с горящими глазами, то сейчас ну если 50%, то уже отлично. Это все немного перешло в тупо ремесло, куда потянулся народ за баблом. И их я тоже пониманию, потому что лучше уж так, чем за 24к за комбинате работать.
В статье есть еще интересный момент, в которой автор пишет про 21 собес, из которых 20 он не прошел. Я бы сказал, что это очень тревожный звонок. Как человек, который провел сотни собеседований, могу сказать, что джунов/стажеров берут не за знание, а за горящие глаза. Ты не ждешь, что он завтра будет закрывать бизнес-задачи пачками, исправит все баги в проекте и т.д. Ты ждешь, что он погрузиться с головой в проект, будет копать, отнимать разумное количество времени, но через какое-то время (хочется, чтобы быстрое) вырос до мидла и уже самостоятельно пилил таски. То, что автору отказали 20 раз, говорит не о плохих знаниях, а о том, что никто из этих людей не увидел в авторе потенциал быстрого роста. И только одни в прямом смысле слова "за еду" решил попытать удачу. Это ОЧЕНЬ плохой звонок, прямо-таки колокол, который кричит, что автор делаете что-то не то.
Для меня статья автора, наоборот, звучит так, что парни в Практикуме сделали годные курсы, которые в целом чему-то могут научить и дадут понюхать пороху. Я учил бы плюс-минус также. То, что там 1/3 в итоге заканчивает курс - это прям даже какие-то замечательные цифры. Из того, что вижу я вокруг, ставил бы на то, что только каждый пятый дойдет до финала. Это был бы нормальный процент тех, кто в будущем станет реально ок спецом.
В любом случае, автору желаю удачи и в его нелегком пути. И, думаю, пост будет полезен тем, кто думает про Практикум и вообще про вкатывание в IT: выучить C++ за 21 день такой же миф, как и стать разработчиком за 9 месяцев.
Сидишь так в небольшой конторке из 10 человек, автоматизируешь им процессы на делфи, а потом через 10 лет пишешь статью на Хабр, что знания внезапно протухли и работу не найти. Профит!
По-моему, у вас отличный пример, который показывает, что условные программисты:
1) не покупают в вашем городе недвижку за 10 млн
2) не делают ремонты в этих квартирах за 12-16
Со всем уважением, но если это не Москва, то я бы тоже так делать не стал. Перевод денег в пассивный доход (ценные бумаги, например), покупка недвижки в Москве, переезд в другую страну - да, это все понятные кейсы. Зачем делать ремонт на 15 млн в квартире в стране, где с каждым днем ухудшается IT-климат (и не только он) с профессией, которая проще всего позволяет завести трактор в случае чего - загадочная загадка.
Так что, думаю, у вашего друга просто другая целевая аудитория.
Который использует бэкенд LLVM, который написан на C++. Огонь.
Ну будем честные, код со всеми этими оптимизациями стал не слишком читаемым и поддерживаемым. Все-таки обычно мы бизнес-код пишем, а не олимпиадные задачи решаем и очки в бенчмарках набираем.
Потом, не только лишь все могут взять и проделать то, что проделывает автор. На рынке не то, чтобы очень много сеньоров, которые хотят в ассемблерном коде ковыряться фулл-тайм.
Насчет серверов. Если уж совсем быть честным, то на сервере мы можем поставить не десктопный корэ-ай-семь, а парочку AMD EPYC по 64 ядра каждый, и тут я даже не знаю, какие силы надо с Эльбрусом выставлять? Сразу ЦОД строить, чтобы сопостовимо было? Про цены этого сопоставления я вообще молчу.
Но даже если предположить, что мы тут хотя бы десктопных проц трехлетней давности пытаемся догнать, то чтобы результаты из статьи как-то заработали, надо еще nginx переписать под это дело, или TensorFlow, или v8, или какой-то еще софт. Будет Сысоев, интересно, nginx переписывать, чтобы на Эльбрусах все быстро было? Вопрос, конечно, риторический.
То есть да, какую-то работу они показывают. Оно даже работает, если завтра в ЦБ РФ запретят поставлять intel/amd/etc, мы сможем закупить контейнер Эльбрусов, установить их и даже получить какие-то положительные результаты (вопросы о производстве пока отбросим). Но это ваще не конкуренция. Это вещь в себе, которая нужна на каком-то локальном рынке решать какие-то локальные проблемы без претензии на технологичность. Это как Москвич в автомобилестроении, жил, пока ничего другого не было, и сразу умер, как появилось. Мы опять идем по этому пути и опять придем к таким же результатам.
Ой ли! Современный мир таков, что мы пишем продукт, а потом нам приходит осознание, что какая-то крупная компания выпустила, скажем, M1, и теперь наш продукт нужно собирать на ARM. И хочется, чтобы все проблемы ограничились настройкой тулчейна под целевую платформу. И это, кстати, отличный пример, как новый проц довольно быстро оброс софтом и большей произвоидельностью без таких уж сильных приседаний.
Ну и будем честны, вряд ли в общим случае какой-то разрабочик/компания скажут: "штош, начну-ка я пилить свой новый проект чисто под Эльбрус". Как я уже писал выше, кроме оборонки и некоторой госухи я больше никого не вижу.
Поэтому Эльбрус сделал платформу, в которой мы должны тратить время разработчика на оптимизации из приведенной Вами статьи? :)
Ну вы только в кучу всех не мешайте, пожалуйста. Хейтили Маска те, кто сейчас Эльбрус восхваляет. А те, кто говорил, что Маск вполне понятно и результативно развивается (что и было), говорят, что Эльбрус непонятно и нерезультативно развивается. SpaceX с 2002 года начала свой путь, и уже по запускам Россию обогнала, а МЦСТ свой путь начал в 1992, но догнать мы не можем даже десктопный процесс десятилетней давности (а уж про массовость и остальное я вообще молчу).
У автора статьи тесты собраны как нативно под платформу, так и с бинарной трансляцией. Тут можно поискать со словом RTC: https://github.com/EntityFX/anybench/tree/master/results
Конечно, делать выводы по нативному исполнению и эмуляции некорреткно, это понятно. Но эмуляция x86 для Эльбруса стратегически правильное решение, потому что есть куча софта, которые портировать не получится, а запускать надо.
Но основное сравнение: это все-таки нативный код для e2k и нативный код для x86.
Свидетели Отечественных Процессоров на Хабр ботов завезли, что ли?
Какой софт каким конкурентам будет проигрывать? Речь у нас про то, что софт под Эльбрус проигрывает по скорости конкурентам Intel, AMD и далее по списку. Рынок не у Эльбруса, чтобы он задавал тренды, если что :)
Под привычную нам архитектуру x86 большинство оптимизации делает компилятор, не разработчик. Эльбрусовский же компилятор за вас не делает ту работу, которая нужна дла VLIW процов. Есть даже инструкция, как с этим жить.
А то, что вы тут пишите про какие-то коллекции и поиски элементов за линию, говорит лишь о том, что вы вообще не понимаете, о чем тут речь и к чему все претензии. Алгоритмы и структуры данных работают одинаково на всех существующих платформах, потому что это математика.
Потому что можно использовать свежие SSE и прочие AVX-512, которые дают сильный буст на математике.
А использование всего оптимизационного добра на e2k хоть и дают сильный буст, но только в рамках их архитектуры - остальным они все равно сильно проигрывают. Поэтому ребята из magma и всех других расчетных софтов вряд ли будут пилить какую-то серьезную поддержку нашей архитектуры, потому что зачем? И отдел стратегического планирования МЦСТ должен это понимать: никакой массовости не будет, никто специально поддержку пилить не будет, значит, большинство кода на платформе будет использоваться as is.
Не очень понял, о чем Вы. Да, Эльбрус имеет бинарный транслятор, но это все-таки дополнительный бонус для историй, когда код под платформы по каким-то причинам пересобрать нельзя. Наверное, разработчиков в первую очередь интересует история, когда код собрать можно.
Или о чем был комментарий?
Ключи оптимизации являются инструментом компилятора, они, естественно, должны быть выбраны максимально эффективно для целевой платформы, но я говорю не про них.
В моем понимании "оптимизация" - это затачивание тестов под конкретную платформу. e2k архитектура подразумевает, что вы знаете о широкой команде, и стараетесь писать код так, чтобы эту широкую команду максимально заполнить для параллельной обработки. Если вы делаете так, вы действительно получаете сильный буст, но проблема в том, что 99.999% кода написано без оглядки на такие архитектуры, а, следовательно, никаких преимуществ вы тут не получите.
Поэтому интересны такие тестовые кейсы:
1) Мы берем любой стандартный бенчмарк и компилим код as is под x86 и e2k и смотрим, какая разница в попугаях. В подавляюшем большинстве это то, на что нужно смотреть, потому что вряд ли люди будут переписывать openssl или какой-нибудь jsoncpp.
2) Пишем максимально эффективный код для x86 и e2k и смотрим, насколько архитектура реально эффективно тащит задачу. Этот кейс ок, когда вы самые ресурсоемкие части своего продукта сразу пишите с оглядкой на платформу e2k. Не представляю, кому это, кроме МО РФ и некоторой госухе, надо.
И я на всякий случай напомню, что VLIW в Intel умер. Да и не только в Intel, были разные идеи сделать что-то похожее, потому как сама идея выглядит вполне себе ок, но на практике оказалось, что писать эффективный компилятор под этой дело крайне сложно, а заставить всех разработчиков быть умными и сразу писать эффектиный код под архитектуру не получилось.
Последние, что я пробовал, были OSRAM. В течении времени не деградировали (из запаса светит также), но в продаже уже немного другие.
Пользуясь случаем, спрошу: а кто-нибудь подскажет марку светодионых лампочек, который с годами не меняют своих характеристик? Вот чтобы я ее купил, а через 5 лет мог пойти и купить такую же.
Меня жутко бесит, когда через пару лет лампа перегорает, ты едешь в магазин, но точно такой же нет от того же производителя, есть +- 300К, мощность +- 0.5Вт и т.д., в итоге, заменяя одну лампу, получаешь ее в каком-нибудь отличном оттенке, и она мозолит глаза, хочется сразу поменять все. Запас ламп помогает, но полностью проблему не решает.
Есть ли производители, которые с годами стабильны?
Что значит "тесты оптимизированы"? Для разработчика должно быть все по дефолту: взял код, собрал, проверил, отправил в прод. То, что там есть какая-то связь с компилятором - прекрасно, но я же не буду оптимизировать десятки миллионов строк плюсового кода, чтобы они как-то по-особенному стали работать на Эльбрусе. Разработчики процессора это подразумевают, но не уверен, что с ними согласны разработчики софта.
Интересно, а отсутствие отечественной ОЗУ как класса не является угрозой национальной безопасности? А тоже самое, только с видеокартами?
Вы привели очень хороший пример, который как раз в IT работает не так, как вы описываете. Люди, которые в IT часто меняют компании, имеют багаж знаний и умений на порядок больший, чем люди, которые сидят по 10 лет на одном месте (исключения составляют большие компании типа Яндекса, Google и далее по списку, но и там, как правило, люди внутри ротируются, меняя задачи и стек технологии). Так что сеньор, проработавший 10 лет в каком-нибудь КБ не равен сеньору из условного Гугла.
А вот насчёт примера выше с ЗП: почему бы не работать водителем на поставки за 150к, а на оставшейся время пилить любые пет-проеты, вместо того, чтобы пилить какие-то проекты фулл-тайм за 50к? Вот это и есть рыночек.
Сначала подумал, что ууххх, заплюсованная статья-разоблачение, 400+ комментов, будет жара.
Но прочитал статью с улыбкой и сочувствием к автору.
Почти что все, что описано в статье - типичные будни разработчика. Когда бизнес нихрена не может сформулировать, что он хочет; когда неправильный символ в коде можно неделю искать; когда ты копаешь в чужом коде, которому уже 20 лет и автор которого уже, может быть, даже умер; когда документации на внутренние инструменты нет в принципе, и никакое stackoverflow про них ничего не знает; рабочий день, который из 8 часового легко превращается в 15 часовой (мой личный рекорд - 21 час); неадекватные дедлайны и т.д. и т.п. Ну и вишенка на торте - это то, что интенсивное обучение проходит не год, не два, не десять лет, а ВООБЩЕ всю твою жизнь в IT. И это не просто громкие слова, а суровая действительность: новые языки, новые подходы, новые фреймворки, новые языки, новые базы. И в каждой компании все по-разному. Во фронтенде тем более, еще вчера все работали с jQuery, а сейчас уже даже React можно считать легаси. Я бы сказал, что у многих просто происходит перегорание в освоении новых технологии - ну просто уже не хочется браться за что-то новое, потому что этот цикл изучение-использование-выкидывания ты уже тысячи раз прошел.
И вот за все это говно ты получаешь печеньки, кофе, мощный ноут и хорошую зарплату. Кого все это прет, задерживается надолго. Но я скажу, что лет за 15 все сильно поменялось. Если раньше были все с горящими глазами, то сейчас ну если 50%, то уже отлично. Это все немного перешло в тупо ремесло, куда потянулся народ за баблом. И их я тоже пониманию, потому что лучше уж так, чем за 24к за комбинате работать.
В статье есть еще интересный момент, в которой автор пишет про 21 собес, из которых 20 он не прошел. Я бы сказал, что это очень тревожный звонок. Как человек, который провел сотни собеседований, могу сказать, что джунов/стажеров берут не за знание, а за горящие глаза. Ты не ждешь, что он завтра будет закрывать бизнес-задачи пачками, исправит все баги в проекте и т.д. Ты ждешь, что он погрузиться с головой в проект, будет копать, отнимать разумное количество времени, но через какое-то время (хочется, чтобы быстрое) вырос до мидла и уже самостоятельно пилил таски. То, что автору отказали 20 раз, говорит не о плохих знаниях, а о том, что никто из этих людей не увидел в авторе потенциал быстрого роста. И только одни в прямом смысле слова "за еду" решил попытать удачу. Это ОЧЕНЬ плохой звонок, прямо-таки колокол, который кричит, что автор делаете что-то не то.
Для меня статья автора, наоборот, звучит так, что парни в Практикуме сделали годные курсы, которые в целом чему-то могут научить и дадут понюхать пороху. Я учил бы плюс-минус также. То, что там 1/3 в итоге заканчивает курс - это прям даже какие-то замечательные цифры. Из того, что вижу я вокруг, ставил бы на то, что только каждый пятый дойдет до финала. Это был бы нормальный процент тех, кто в будущем станет реально ок спецом.
В любом случае, автору желаю удачи и в его нелегком пути. И, думаю, пост будет полезен тем, кто думает про Практикум и вообще про вкатывание в IT: выучить C++ за 21 день такой же миф, как и стать разработчиком за 9 месяцев.
>функции совместного редактирования документов в режиме реального времени
О, Google Docs заехал спустя 15 лет.
я джва десятилетия ждал
Мимокрокодил:
А что там с времен Office 2007 вообще добавили из нового для тех, кто в танке и не следит?
Сидишь так в небольшой конторке из 10 человек, автоматизируешь им процессы на делфи, а потом через 10 лет пишешь статью на Хабр, что знания внезапно протухли и работу не найти. Профит!
По-моему, у вас отличный пример, который показывает, что условные программисты:
1) не покупают в вашем городе недвижку за 10 млн
2) не делают ремонты в этих квартирах за 12-16
Со всем уважением, но если это не Москва, то я бы тоже так делать не стал. Перевод денег в пассивный доход (ценные бумаги, например), покупка недвижки в Москве, переезд в другую страну - да, это все понятные кейсы. Зачем делать ремонт на 15 млн в квартире в стране, где с каждым днем ухудшается IT-климат (и не только он) с профессией, которая проще всего позволяет завести трактор в случае чего - загадочная загадка.
Так что, думаю, у вашего друга просто другая целевая аудитория.