Восемь контринтуитивных трендов нынешней ситуации на рынке труда программистов. Спойлер: если вы читаете этот пост и любите и умеете программировать, то вам реально очень повезло в этой жизни.
После прошлогоднего напряга от всех этих карантинов конечно у людей накопилось прилично усталости, которая даёт себя знать спустя приличное время, много месяцев, причём причина её необычная, ранее такого никогда не было (и вот опять). И так как проблема в целом не рассосалась, и определённое давление остаётся весьма ощутимым, то и последствия тоже нестандартные.
Во-первых, возврат с удалёнки вроде как и радует, когда можно пообщаться в реале, однако уже желания торчать в офисе в большом коллективе сильно меньше чем когда-либо. Идеал -- работаем вживую 2-3 раза в неделю в небольших группах.
Во-вторых, на фоне этого всего существенно ослабли в плане мотивации не только деньги, но даже и интересные проекты. Людям хочется спокойной работы в стабильном и, главное, ненапряжном режиме.
В-третьих, запросы в плане денег реально уменьшились. На фоне памяти о карантинных мучениях на первый план прорезались таки истинные общечеловеческие ценности :) Условно, лучше я потеряю в зп на треть, но и работать буду в два раза меньше. Поэтому эйчары начали понемногу паниковать :) Что толку, что у компании дофига денег, если невозможно найти программистов, а классические карьерные пути и мотивашки начинают сильно проседать.
В четвёртых, в условиях известных ограничений и изоляции люди ощутимо озлились :) Поэтому команды становятся меньше и сплочённее ("кругом враги"), чужаков со стороны берут совсем неохотно, и это тоже стала новая сильная головная боль кадровиков; у разработчиков продолжает расти недовольство и раздражение ими -- в частности, унылые шаблонные мотивационные плюшки вообще перестали работать по вышеуказанным причинам.
Вдумчиво учитывайте это всё -- это реально классные специфические шансы, которые выпадают редко, раз во много лет.
окончание следует
После прошлогоднего напряга от всех этих карантинов конечно у людей накопилось прилично усталости, которая даёт себя знать спустя приличное время, много месяцев, причём причина её необычная, ранее такого никогда не было (и вот опять). И так как проблема в целом не рассосалась, и определённое давление остаётся весьма ощутимым, то и последствия тоже нестандартные.
Во-первых, возврат с удалёнки вроде как и радует, когда можно пообщаться в реале, однако уже желания торчать в офисе в большом коллективе сильно меньше чем когда-либо. Идеал -- работаем вживую 2-3 раза в неделю в небольших группах.
Во-вторых, на фоне этого всего существенно ослабли в плане мотивации не только деньги, но даже и интересные проекты. Людям хочется спокойной работы в стабильном и, главное, ненапряжном режиме.
В-третьих, запросы в плане денег реально уменьшились. На фоне памяти о карантинных мучениях на первый план прорезались таки истинные общечеловеческие ценности :) Условно, лучше я потеряю в зп на треть, но и работать буду в два раза меньше. Поэтому эйчары начали понемногу паниковать :) Что толку, что у компании дофига денег, если невозможно найти программистов, а классические карьерные пути и мотивашки начинают сильно проседать.
В четвёртых, в условиях известных ограничений и изоляции люди ощутимо озлились :) Поэтому команды становятся меньше и сплочённее ("кругом враги"), чужаков со стороны берут совсем неохотно, и это тоже стала новая сильная головная боль кадровиков; у разработчиков продолжает расти недовольство и раздражение ими -- в частности, унылые шаблонные мотивационные плюшки вообще перестали работать по вышеуказанным причинам.
Вдумчиво учитывайте это всё -- это реально классные специфические шансы, которые выпадают редко, раз во много лет.
окончание следует
В пятых, сильнее всего сейчас выгорают ребята среднего возраста 30-40 лет -- они в расцвете мастерства, ну их в период кризиса и превратили в слоников, навалив дофига задачек, а у многих маленькие детишки вдобавок. А вот кто постарше, всем этим уже были закалены неоднократно, поэтому переносят тяготы и лишения куда более спокойно.
В шестых, следствие, что теперь отпуск, лето, ждутся как манна небесная, берётся за свой счёт побольше дней вдобавок, а осень вообще сейчас многими воспринимается как переломный момент в жизни, поэтому на работах массово уже начинается определённый расслабон, и эйчары жутко паникуют: осенью начнётся небывалый вал миграции программистов в другие фирмы, которые вовремя просекли все эти нюансы :)
В седьмых, поколение Z - до 23 лет, насмотревшись извините моргенштерна и тиктокеров, зарабатывающих миллионы на пустом месте -- аки обезьяны в зоопарке корчащие смешные рожицы за лайки - вообще уже не понимают, что такое найм на постоянную работу и труд за зарплату )))
Ну и в восьмых: люди перестали заботиться о долгосрочных планах более чем полностью. Сейчас всё что больше года в планировании, не воспринимается всерьёз - внутренне люди не верят, что не возникнет новых помех (и зря кстати, но штош...). Поэтому и всяческие корпоративные программы карьеры от кадровиков перестали мотивировать. Вырастить хорошего миддла например, нужно года три "без отрыва от производства", а среднее время работы программиста в одной компании сегодня -- это полтора года.
Резюме такое, что если вам очень нравится программировать, а работа в офисе за хорошую зарплату не вызывает особого дискомфорта, то вам совершенно реально жутко повезло в жизни. Потому что идущие за вами следом скорее всего уже никогда не будут ценить эти вещи :) и за десяток лет возникнет огромная пропасть -- количество программистов, готовых реально трудиться, да ещё и подолгу и на одном месте, будет сокращаться с космической скоростью, и вы на этом фоне получите огромные конкурентные преимущества (которыми, конечно, ещё надо суметь правильно распорядиться), если например будете усиленно развиваться, да ещё и в одной организации. Хотя и больше 3-5 лет я тоже не рекомендую засиживаться нигде вообще, если зп не сильно выше среднерыночной.
В шестых, следствие, что теперь отпуск, лето, ждутся как манна небесная, берётся за свой счёт побольше дней вдобавок, а осень вообще сейчас многими воспринимается как переломный момент в жизни, поэтому на работах массово уже начинается определённый расслабон, и эйчары жутко паникуют: осенью начнётся небывалый вал миграции программистов в другие фирмы, которые вовремя просекли все эти нюансы :)
В седьмых, поколение Z - до 23 лет, насмотревшись извините моргенштерна и тиктокеров, зарабатывающих миллионы на пустом месте -- аки обезьяны в зоопарке корчащие смешные рожицы за лайки - вообще уже не понимают, что такое найм на постоянную работу и труд за зарплату )))
Ну и в восьмых: люди перестали заботиться о долгосрочных планах более чем полностью. Сейчас всё что больше года в планировании, не воспринимается всерьёз - внутренне люди не верят, что не возникнет новых помех (и зря кстати, но штош...). Поэтому и всяческие корпоративные программы карьеры от кадровиков перестали мотивировать. Вырастить хорошего миддла например, нужно года три "без отрыва от производства", а среднее время работы программиста в одной компании сегодня -- это полтора года.
Резюме такое, что если вам очень нравится программировать, а работа в офисе за хорошую зарплату не вызывает особого дискомфорта, то вам совершенно реально жутко повезло в жизни. Потому что идущие за вами следом скорее всего уже никогда не будут ценить эти вещи :) и за десяток лет возникнет огромная пропасть -- количество программистов, готовых реально трудиться, да ещё и подолгу и на одном месте, будет сокращаться с космической скоростью, и вы на этом фоне получите огромные конкурентные преимущества (которыми, конечно, ещё надо суметь правильно распорядиться), если например будете усиленно развиваться, да ещё и в одной организации. Хотя и больше 3-5 лет я тоже не рекомендую засиживаться нигде вообще, если зп не сильно выше среднерыночной.
Очередная мощная идея из математики -- схемы Гротендика, открытые им 60 лет назад, и связавшие сразу несколько крупных областей математики в одно целое (алгебраическую геометрию) -- добирается до мира ИТ.
https://arxiv.org/pdf/2104.09366.pdf
Оказалось в частности, что с их помощью можно разработать более простую теорию типов, которая будет не менее сильная, нежели зависимые типы, активно применяющиеся в пруф-ассистантах вроде Lean и Coq.
В работе показано, как аналогичную по мощности систему можно реализовать в Isabelle через т.н. локали (по сути, предикаты), из которых можно строить иерархии.
За этими всеми темками -- ближайшее будущее программирования!
Знание и умение применять теорию типов уже сегодня обязательно для любого уважающего себя программиста.
Гротендик кстати очень наглядно пояснял многие свои концепции наглядно, через так называемые "детские рисунки", благодаря чему можно понять полезные моменты вообще с нуля. Посмотрите, классное видео в тему -- "Детский рисунки и современная математика", просто понять тамошние картиночки уже сильно полезно.
https://www.youtube.com/watch?v=7PYhY8eXkoo
https://arxiv.org/pdf/2104.09366.pdf
Оказалось в частности, что с их помощью можно разработать более простую теорию типов, которая будет не менее сильная, нежели зависимые типы, активно применяющиеся в пруф-ассистантах вроде Lean и Coq.
В работе показано, как аналогичную по мощности систему можно реализовать в Isabelle через т.н. локали (по сути, предикаты), из которых можно строить иерархии.
За этими всеми темками -- ближайшее будущее программирования!
Знание и умение применять теорию типов уже сегодня обязательно для любого уважающего себя программиста.
Гротендик кстати очень наглядно пояснял многие свои концепции наглядно, через так называемые "детские рисунки", благодаря чему можно понять полезные моменты вообще с нуля. Посмотрите, классное видео в тему -- "Детский рисунки и современная математика", просто понять тамошние картиночки уже сильно полезно.
https://www.youtube.com/watch?v=7PYhY8eXkoo
Сегодня популярные онлайновые платформы поддержки программирования уже столь круты, что сами по себе представляют фактически готовые, простые и очень удобные движки для создания полноценного многомиллионного ИТ-бизнеса. Это так называемый PaaS -- платформа как сервис. Не надо заморачиваться арендой виртуальных серверов, их суппортом, деплоем нужных пакетов, администрированием...
Например, 20-летний пацанчик Soren из Сиэтла создал трейдинговый сервис blubbr.io (the global leader in real-time automated notifications for key events in the lifecycle of every SPAC....), который ежемесячно зарабатывает тысячу долларов, а разработал и задеплоил он его вообще без инвестиций, на популярном бесплатном сервисе для разработчиков https://replit.com/
Причём пилил он blubbr вообще как сторонний проект, в свободное время (Soren ещё учится и работает в финтехе).
https://blog.replit.com/blubbr
You have to code locally, push your code to the cloud, create a database, test your strategy, and then finally deploy to Google Cloud or Heroku. This process always takes weeks. With Replit, we had completed all of this in four days. The part of the development process for me that was simplified the most was deployment. This is because Replit deployment consists of two buttons: “always-on” and “run”.
Например, 20-летний пацанчик Soren из Сиэтла создал трейдинговый сервис blubbr.io (the global leader in real-time automated notifications for key events in the lifecycle of every SPAC....), который ежемесячно зарабатывает тысячу долларов, а разработал и задеплоил он его вообще без инвестиций, на популярном бесплатном сервисе для разработчиков https://replit.com/
Причём пилил он blubbr вообще как сторонний проект, в свободное время (Soren ещё учится и работает в финтехе).
https://blog.replit.com/blubbr
You have to code locally, push your code to the cloud, create a database, test your strategy, and then finally deploy to Google Cloud or Heroku. This process always takes weeks. With Replit, we had completed all of this in four days. The part of the development process for me that was simplified the most was deployment. This is because Replit deployment consists of two buttons: “always-on” and “run”.
Что серьёзному программисту полезно почитать на тему, как думать о сложных системах рационально и как решать программистские задачки по-научному -- учимся у математиков.
-- "Доказательства и опровержения" Имре Лакатос. Элегантно и увлекательно рассказывается о математической логике;
-- "Как научиться решать задачи" Фридман, Турецкий. Была рекомендована в СССР даже учащимся ПТУ :)
-- "Как решать задачу, когда не знаешь как" Кашуба -- совсем простенькая в методологическом плане, но была рекомендована в кружке мехмата МГУ например;
-- "Как решают нестандартные задачи" Канель-Белов, Ковальджи. Разбор решений нестандартных олимпиадных задач;
-- конечно, Пойя "Как решать задачу", "Математика и правдоподобные рассуждения".
Все книги хорошо понимаемы на уровне старшеклассников и дают классное множество эвристик решений, помогают в классификации задач.
Кто хочет похардкорнее, поглубже поизучать механику математического мышления, порекомендую "Исследование психологии процесса изобретения в области математики" Жак Адамар.
-- "Доказательства и опровержения" Имре Лакатос. Элегантно и увлекательно рассказывается о математической логике;
-- "Как научиться решать задачи" Фридман, Турецкий. Была рекомендована в СССР даже учащимся ПТУ :)
-- "Как решать задачу, когда не знаешь как" Кашуба -- совсем простенькая в методологическом плане, но была рекомендована в кружке мехмата МГУ например;
-- "Как решают нестандартные задачи" Канель-Белов, Ковальджи. Разбор решений нестандартных олимпиадных задач;
-- конечно, Пойя "Как решать задачу", "Математика и правдоподобные рассуждения".
Все книги хорошо понимаемы на уровне старшеклассников и дают классное множество эвристик решений, помогают в классификации задач.
Кто хочет похардкорнее, поглубже поизучать механику математического мышления, порекомендую "Исследование психологии процесса изобретения в области математики" Жак Адамар.
Серьёзные, но бедные ребята интересовались, как бы им обеспечить качество кода, близкое к формально доказанной корректности, но по дешёвке :) Потому что на профильных спецов денежек совсем нету.
Посоветовал им простой, но очень действенный способ: сохранять цикломатическую сложность всех функций/методов в проекте равной единице (ааа).
VS её например давным давно меряет, для питончика есть Radon, для Java во все еёные IDE тоже сколько лет метрика McCabe встроена, да и калькуляторов полно, вот например эталонно написан:
https://github.com/rodhilton/jasome/blob/master/src/main/java/org/jasome/metrics/calculators/CyclomaticComplexityCalculator.java
Ну и вторая фишка, очень рекомендованная к применению совместно с первой: использовать только иммутабельные типы данных.
Посоветовал им простой, но очень действенный способ: сохранять цикломатическую сложность всех функций/методов в проекте равной единице (ааа).
VS её например давным давно меряет, для питончика есть Radon, для Java во все еёные IDE тоже сколько лет метрика McCabe встроена, да и калькуляторов полно, вот например эталонно написан:
https://github.com/rodhilton/jasome/blob/master/src/main/java/org/jasome/metrics/calculators/CyclomaticComplexityCalculator.java
Ну и вторая фишка, очень рекомендованная к применению совместно с первой: использовать только иммутабельные типы данных.
Системный разбор Анатолием Георгиевичем Кушниренко темки "Программирование для математиков, 35 лет спустя" (там же ссылочка на видео) -- про школьную информатику и, соответственно, про массовое обучение программированию всех желающих.
https://ailev.livejournal.com/1568319.html
"Не опустить университетский курс в среднюю школу, а поднять курс для дошкольников в начальную школу -- и навыки в объёме ОГЭ по информатике закрыть уже в начальной школе. И этот второй заход оказался успешным!.."
Добавлю, что в любой науке ровно столько науки, сколько в ней математики, а в любой математике ровно столько математики, сколько в ней вычислимости. Но чтобы правильно думать об этой вычислимости (не путая вычислительную сложность с дескриптивной сложностью), надо прежде всего учиться задавать вычислительную семантику.
https://ailev.livejournal.com/1568319.html
"Не опустить университетский курс в среднюю школу, а поднять курс для дошкольников в начальную школу -- и навыки в объёме ОГЭ по информатике закрыть уже в начальной школе. И этот второй заход оказался успешным!.."
Добавлю, что в любой науке ровно столько науки, сколько в ней математики, а в любой математике ровно столько математики, сколько в ней вычислимости. Но чтобы правильно думать об этой вычислимости (не путая вычислительную сложность с дескриптивной сложностью), надо прежде всего учиться задавать вычислительную семантику.
Многие люди, кодящие даже на "современном" C++20, оказывается, не знают, что там давным давно есть завтипчики:
https://en.cppreference.com/w/cpp/language/dependent_name
С С++11 или C++14 вроде началось, если не раньше.
Темплейты в плюсах тьюринг-полные, и генерики из других языков до их мощи не дотягивают. Отличие от классических dependent types в том, что некоторое значение (параметр типа) тут должно быть в конечном итоге реально вычислено (конкретная чиселка нужна), чтобы это всё заработало, а полноценные языки с завтипами (в Idris или Agda например) подразумевают возможность формальных алгебраических "вычислений" на уровне исходных текстов.
Для улучшения понимания зависимых типов порекомендую прежде всего почитать про параметрический полиморфизм, как именно он поддерживается в языке программирования, на котором вы в основном кодите, а главное, поразбирать конкретные примеры такого полиморфизма.
https://en.cppreference.com/w/cpp/language/dependent_name
С С++11 или C++14 вроде началось, если не раньше.
Темплейты в плюсах тьюринг-полные, и генерики из других языков до их мощи не дотягивают. Отличие от классических dependent types в том, что некоторое значение (параметр типа) тут должно быть в конечном итоге реально вычислено (конкретная чиселка нужна), чтобы это всё заработало, а полноценные языки с завтипами (в Idris или Agda например) подразумевают возможность формальных алгебраических "вычислений" на уровне исходных текстов.
Для улучшения понимания зависимых типов порекомендую прежде всего почитать про параметрический полиморфизм, как именно он поддерживается в языке программирования, на котором вы в основном кодите, а главное, поразбирать конкретные примеры такого полиморфизма.
Я довольно часто говорю занимающимся о двух вечных болях в программировании, готового решения "из коробки" для которых не существует в силу их природы. Это
1) кодировка -- прежде всего кодировка текстовых констант в файлах с кодом, которые (файлы) шибко умные текстовые редакторы любят тайно перекодировывать, например из юникода в 1251,
и тут же в тему -- локализация проекта, и
2) дата/время таймзоны -- например, на сервере в классе Enterprise задаётся локальная таймзона, но у клиента в браузере своя локальная таймзона, и он вдобавок хочет произвольно менять таймзоны и при этом смотреть все отчёты с точностью до минуты в "своей" таймзоне (не забывая при этом переходы на весеннее и зимнее время...).
Однако есть ещё как минимум три боли, к которым каждому программисту желательно хорошо подготовиться.
3) regexp -- регулярные выражения. Как говорится, джуниор посмотрел на проблему, задействовал регэкспы для её решения, и теперь у него стало две проблемы :)
Регулярки -- сильная, но очень опасная штука, в частности потому, что отлаживать её практически нереально. Нафигачил паттерн, потестил, ну вроде работает. А потом такое началось!
Чтобы писать хорошие регулярные выражения, надо мыслить как регэксп :) А для этого нужен хороший алгебраический ум. Рекомендация -- пройти хороший курс и почитать хороший учебник, прежде чем пытаться писать любые регулярки.
4) CORS, XSS и CSRF -- механизмы атак и защит в браузерах, с которыми необходимо как следует промучиться не только каждому фронтендеру, но и бэкендеру прежде всего.
5) состояния/stateful и мутабельность -- ну это даже не конкретная боль, а просто неотъемлемое от любой программистской работы в мэйнстриме свойство быстрого запутывания кода и быстрого роста ошибок, прямо пропорциональное количеству используемых в коде переменных, значения (состояние) которых меняются в процессе работы программы. Бороться с этим надо, соответственно, stateless-ом и иммутабельностью -- правильным применением практик декларативного (в частности, функционального) программирования.
1) кодировка -- прежде всего кодировка текстовых констант в файлах с кодом, которые (файлы) шибко умные текстовые редакторы любят тайно перекодировывать, например из юникода в 1251,
и тут же в тему -- локализация проекта, и
2) дата/время таймзоны -- например, на сервере в классе Enterprise задаётся локальная таймзона, но у клиента в браузере своя локальная таймзона, и он вдобавок хочет произвольно менять таймзоны и при этом смотреть все отчёты с точностью до минуты в "своей" таймзоне (не забывая при этом переходы на весеннее и зимнее время...).
Однако есть ещё как минимум три боли, к которым каждому программисту желательно хорошо подготовиться.
3) regexp -- регулярные выражения. Как говорится, джуниор посмотрел на проблему, задействовал регэкспы для её решения, и теперь у него стало две проблемы :)
Регулярки -- сильная, но очень опасная штука, в частности потому, что отлаживать её практически нереально. Нафигачил паттерн, потестил, ну вроде работает. А потом такое началось!
Чтобы писать хорошие регулярные выражения, надо мыслить как регэксп :) А для этого нужен хороший алгебраический ум. Рекомендация -- пройти хороший курс и почитать хороший учебник, прежде чем пытаться писать любые регулярки.
4) CORS, XSS и CSRF -- механизмы атак и защит в браузерах, с которыми необходимо как следует промучиться не только каждому фронтендеру, но и бэкендеру прежде всего.
5) состояния/stateful и мутабельность -- ну это даже не конкретная боль, а просто неотъемлемое от любой программистской работы в мэйнстриме свойство быстрого запутывания кода и быстрого роста ошибок, прямо пропорциональное количеству используемых в коде переменных, значения (состояние) которых меняются в процессе работы программы. Бороться с этим надо, соответственно, stateless-ом и иммутабельностью -- правильным применением практик декларативного (в частности, функционального) программирования.
Удивительный тренд: хаскелисты массово переходят на раст.
Впрочем, после хаскеля раст очень хорошо заходит! Вроде бы это шаг назад в императивщину, но нет, Rust настолько хороший "классический" язык программирования сам по себе, что на нём получается выделывать очень крутые штуки.
RustBelt is a formal model of Rust’s type system.
This thesis has received a 2021 Otto Hahn Medal and the 2021 ETAPS Doctoral Dissertation Award.
https://people.mpi-sws.org/~jung/thesis.html
Rust Verification Workshop 2021
https://www.youtube.com/playlist?list=PL-uEDsw-7yRLYMEdlvh4udnjK3JtGJgSh
Я даже подумываю добавить в цикл "как понять в программировании всё" примеры на Rust в дополнение к Julia.
Впрочем, после хаскеля раст очень хорошо заходит! Вроде бы это шаг назад в императивщину, но нет, Rust настолько хороший "классический" язык программирования сам по себе, что на нём получается выделывать очень крутые штуки.
RustBelt is a formal model of Rust’s type system.
This thesis has received a 2021 Otto Hahn Medal and the 2021 ETAPS Doctoral Dissertation Award.
https://people.mpi-sws.org/~jung/thesis.html
Rust Verification Workshop 2021
https://www.youtube.com/playlist?list=PL-uEDsw-7yRLYMEdlvh4udnjK3JtGJgSh
Я даже подумываю добавить в цикл "как понять в программировании всё" примеры на Rust в дополнение к Julia.
В России на днях выделили Р600,000,000 на обучение обучению технологиям AI -- ну то есть массово универских преподов готовить. Могу себе представить, каким же легаси технологиям за эти денежки будут студентов учить, потому что от США и Китая в научном плане мы отстали безнадёжно, если судить хотя бы по составу международных научных конференций AI/ML. Я бы даже поставил на то, что AGI который захватит мир будет скорее китайский, хотя в американских компаниях сейчас вроде все мировые AI-топы работают.
В наших университетах ситуация совсем печальная:
https://habr.com/ru/post/562476/
И как бы не надували щёки МГУ и СПбГУ, в мировом рейтинге университетов они замыкают top 100 (если в этом году вообще попадут в него). Надо понимать, что это отличие качественное: уровень обучения computer science в Массачусетсе или Стэнфорде такое, что наши лучшие универы в сравнении с ним это как третий школьный класс арифметики и третий вузовский курс по матану.
Тем временем вузы по всей стране, офигев от результатов ЕГЭ и уровня нынешних 11-классников, пробившего дно в этом году особенно сильно, срочно снижают проходные баллы. Ну и кого через 3-5 лет будем учить AI?
Как надо было? Как в футболе, когда банк покупает клуб и хочет его быстро сделать чемпионом -- тут не до развития молодняка и своих академиев. Вы же знаете, что подавляющее большинство успешных стартапов их создатели организовали, будучи в возрасте 24-39 лет (средний возраст 34 года)? и никаких студентов на самом деле.
Просто перекупаются топовые звёзды на пару сезонов. Потому что до сингулярности остались считанные десятилетия, и пока ещё не поздно совсем, надо срочно переманивать мировых спецов -- пару десятков схантить вполне достаточно (ну и у нас человек пять найдётся), и организовать для них единый центр, где и обучение бы велось, но не массовое, а по вполне конкретным прорывным темкам, в прямом направлении на AGI. И преподов готовить, только тоже не массово, а точечно.
В наших университетах ситуация совсем печальная:
https://habr.com/ru/post/562476/
И как бы не надували щёки МГУ и СПбГУ, в мировом рейтинге университетов они замыкают top 100 (если в этом году вообще попадут в него). Надо понимать, что это отличие качественное: уровень обучения computer science в Массачусетсе или Стэнфорде такое, что наши лучшие универы в сравнении с ним это как третий школьный класс арифметики и третий вузовский курс по матану.
Тем временем вузы по всей стране, офигев от результатов ЕГЭ и уровня нынешних 11-классников, пробившего дно в этом году особенно сильно, срочно снижают проходные баллы. Ну и кого через 3-5 лет будем учить AI?
Как надо было? Как в футболе, когда банк покупает клуб и хочет его быстро сделать чемпионом -- тут не до развития молодняка и своих академиев. Вы же знаете, что подавляющее большинство успешных стартапов их создатели организовали, будучи в возрасте 24-39 лет (средний возраст 34 года)? и никаких студентов на самом деле.
Просто перекупаются топовые звёзды на пару сезонов. Потому что до сингулярности остались считанные десятилетия, и пока ещё не поздно совсем, надо срочно переманивать мировых спецов -- пару десятков схантить вполне достаточно (ну и у нас человек пять найдётся), и организовать для них единый центр, где и обучение бы велось, но не массовое, а по вполне конкретным прорывным темкам, в прямом направлении на AGI. И преподов готовить, только тоже не массово, а точечно.
Хабр
Как я дважды пытался, но ни разу не смог получить высшее ИТ-образование в российской провинции
Пензенский Государственный Университет Здравствуйте, меня зовут Сергей, и у меня, как и у многих других программистов, нет диплома о высшем образовании. Не то, чтобы я не пытался его получить -...
Вы сами должны быть самым первым и объективным (и желательно, придирчивым и занудным) ревьюером вашего же кода. Если ваш собственный код труден вам же для code review, то он тем паче будет труден для понимания другими :)
Полезная микра: оставлять комменты, предназначенные для понимания его ревьюером (вам же самим, в частности, через пару месяцев, когда вы уже всё забудете). Например, если у вас в проекте 10 файлов, то прежде всего хорошо бы понять, а какой из них "первый" в семантическом плане, с чего вообще начинать разбирательство с проэктом.
Иначе вы будете регулярно получать вот такие предложения ))) =>
Полезная микра: оставлять комменты, предназначенные для понимания его ревьюером (вам же самим, в частности, через пару месяцев, когда вы уже всё забудете). Например, если у вас в проекте 10 файлов, то прежде всего хорошо бы понять, а какой из них "первый" в семантическом плане, с чего вообще начинать разбирательство с проэктом.
Иначе вы будете регулярно получать вот такие предложения ))) =>
Отовсюду лезет реклама AI pair programmer
https://copilot.github.com/
смешно, что в примере parse_expenses.py используется float для хранения денег хм.
Это абсолютная ошибка проектировщика и никогда так не надо делать, но -- но бывает ли это реальной проблемой?
Помнится, из 1990-х история, как некий умник в каком-то американском банке подправил логику округления (32-разрядный float наверное в 5-6 знаке ошибается), и по центу с лавины округлений денежных транзакций сбрасывал себе на счёт, и якобы стал миллионером. Но с тех пор каких-то эпикфейлов из-за использования стандартных типов с плавающей запятой для хранения денежек особо не было слышно.
Впрочем, совсем не исключено, потому, что мэйнстрим пробил дно уже так, что данный тип багов, несмотря на массовое явление более-менее норм типов из коробки вроде decimal, стал повсеместным :-)
https://copilot.github.com/
смешно, что в примере parse_expenses.py используется float для хранения денег хм.
Это абсолютная ошибка проектировщика и никогда так не надо делать, но -- но бывает ли это реальной проблемой?
Помнится, из 1990-х история, как некий умник в каком-то американском банке подправил логику округления (32-разрядный float наверное в 5-6 знаке ошибается), и по центу с лавины округлений денежных транзакций сбрасывал себе на счёт, и якобы стал миллионером. Но с тех пор каких-то эпикфейлов из-за использования стандартных типов с плавающей запятой для хранения денежек особо не было слышно.
Впрочем, совсем не исключено, потому, что мэйнстрим пробил дно уже так, что данный тип багов, несмотря на массовое явление более-менее норм типов из коробки вроде decimal, стал повсеместным :-)
GitHub
GitHub Copilot
AI that builds with you
Из ИТ-сфер, которые мощно поднялись в 2021-м, больше всех разбогател, хм кто бы мог подумать ))) геймдев. 2,7 миллиарда активных игроков!
Блин, представляете, уже треть человечества почти каждый день заходит в какую-нибудь игруху. Ковид этому сильно поспособствовал конечно, и дальше наверняка очередной миллиард геймеров на подходе.
Я в gamedev-е работал ещё с конца 1980-х, а в последнем игровом проекте поучаствовал лет семь назад, и все эти десятилетия наблюдаю, как отечественные порталы по разработке игр скатываются и скатываются в УГ, стабильно пробивая дно токсичности, которое, казалось бы, уж некуда дальше пробивать. В основном нытьё, как всё стало плохо, игр миллионы, никто не покупает бла бла бла... В жанре сменяются целые эпохи - shareware, онлайн, кикстартер, мобилки, соцсети, f2p, инди, гиперказуал... И всё так же одни пилят игры и (иногда) делают миллионы долларов, а другие только плачут.
Геймдев -- это наверное единственная массово доступная область, где программисту-одиночке, или совсем маленькой команде, реально заработать миллион (но реально и не заработать, конечно). Но, как минимум, шанс куда выше, чем выиграть в лотерею.
Не играйте в игры, пишите игры!
На втором месте в плане денежного роста -- AI/ML. Основной спрос только пока на все эти распознавалки со стороны строителей мирового концлагеря конечно :)
На третьем -- облачные сервисы, ну или пресловутый онлайн, примитивно говоря, который сегодня нужен абсолютно любому программному продукту.
Блин, представляете, уже треть человечества почти каждый день заходит в какую-нибудь игруху. Ковид этому сильно поспособствовал конечно, и дальше наверняка очередной миллиард геймеров на подходе.
Я в gamedev-е работал ещё с конца 1980-х, а в последнем игровом проекте поучаствовал лет семь назад, и все эти десятилетия наблюдаю, как отечественные порталы по разработке игр скатываются и скатываются в УГ, стабильно пробивая дно токсичности, которое, казалось бы, уж некуда дальше пробивать. В основном нытьё, как всё стало плохо, игр миллионы, никто не покупает бла бла бла... В жанре сменяются целые эпохи - shareware, онлайн, кикстартер, мобилки, соцсети, f2p, инди, гиперказуал... И всё так же одни пилят игры и (иногда) делают миллионы долларов, а другие только плачут.
Геймдев -- это наверное единственная массово доступная область, где программисту-одиночке, или совсем маленькой команде, реально заработать миллион (но реально и не заработать, конечно). Но, как минимум, шанс куда выше, чем выиграть в лотерею.
Не играйте в игры, пишите игры!
На втором месте в плане денежного роста -- AI/ML. Основной спрос только пока на все эти распознавалки со стороны строителей мирового концлагеря конечно :)
На третьем -- облачные сервисы, ну или пресловутый онлайн, примитивно говоря, который сегодня нужен абсолютно любому программному продукту.
Лет 10 назад была вконтактнике такая игра "Счастливый фермер", которая прославилась тем, что SQL-запросы нативно формировались на клиенте, и игровая логика соответственно элементарно хакалась, а все игровые данные хранились на сервере вперемешку в одной табличке БД, которая периодически ломалась )))
"Где моя свинья девятого уровня??" (с)
Принесла эта игра кстати десятки миллионов долларов, ну и клонов немало создавалось конечно, "Весёлая ферма" наверное самый известный.
Я наивно думал, что этот жанр уже давно загнулся, ну или стал нишевым, ан нет: этим летом минские пацаны из Melsoft на своём симуляторе фермы Family Island пробили планку суммарно в сто миллионов долларов дохода ))) Дико уважаю.
Сумма после всех вычетов сторов и налогов, конечно; накопилась всего за два года.
"моей наградой стали 2 миллиарда денег на ферме, 227 уровень, корова прокачанная до 100 000 уровня, следствием чего явилось повышение уважения среди друзей." (с)
А ихний кулинарный тайм-менеджер My Cafe, выпущенный пять лет назад, кстати, уже 127 миллионов долларов намайнил.
В первое время конечно такие игры совсем крохотные копейки приносят: например Family Island в первые месяцы после запуска выдавала ничтожные 50 тысяч долларов. :)
Белорусам в этом плане есть чему поучиться у японцев: месяц назад вышла мимимишная мобильная РПГ Ni no Kuni: Cross Worlds (очень красивая, мультяшка) про бета-тестера VR-игры, так вот она побила мировой рекорд для игр по скорости набора сотки миллионов долларов: за 11 дней (и это ещё мирового релиза не было!). Прежний рекорд 12 дней принадлежал Покемонам, ага. Они были раскручены Ингрессом конечно, но и Ni no Kuni -- это тоже большая серия. Третья Genshin Impact -- 13 дней, ну и линейка-2 вроде так же.
А по скорости зарабатывания в отдельные дни Ni no Kuni была вторая в мире после Honor of Kings.
Кстати, пилилась Ni no Kuni на Unreal Engine 4 той же командой, что и линейку делала :-)
"Где моя свинья девятого уровня??" (с)
Принесла эта игра кстати десятки миллионов долларов, ну и клонов немало создавалось конечно, "Весёлая ферма" наверное самый известный.
Я наивно думал, что этот жанр уже давно загнулся, ну или стал нишевым, ан нет: этим летом минские пацаны из Melsoft на своём симуляторе фермы Family Island пробили планку суммарно в сто миллионов долларов дохода ))) Дико уважаю.
Сумма после всех вычетов сторов и налогов, конечно; накопилась всего за два года.
"моей наградой стали 2 миллиарда денег на ферме, 227 уровень, корова прокачанная до 100 000 уровня, следствием чего явилось повышение уважения среди друзей." (с)
А ихний кулинарный тайм-менеджер My Cafe, выпущенный пять лет назад, кстати, уже 127 миллионов долларов намайнил.
В первое время конечно такие игры совсем крохотные копейки приносят: например Family Island в первые месяцы после запуска выдавала ничтожные 50 тысяч долларов. :)
Белорусам в этом плане есть чему поучиться у японцев: месяц назад вышла мимимишная мобильная РПГ Ni no Kuni: Cross Worlds (очень красивая, мультяшка) про бета-тестера VR-игры, так вот она побила мировой рекорд для игр по скорости набора сотки миллионов долларов: за 11 дней (и это ещё мирового релиза не было!). Прежний рекорд 12 дней принадлежал Покемонам, ага. Они были раскручены Ингрессом конечно, но и Ni no Kuni -- это тоже большая серия. Третья Genshin Impact -- 13 дней, ну и линейка-2 вроде так же.
А по скорости зарабатывания в отдельные дни Ni no Kuni была вторая в мире после Honor of Kings.
Кстати, пилилась Ni no Kuni на Unreal Engine 4 той же командой, что и линейку делала :-)
Поучительный пример, как полезно "войтивайти" через геймдев.
https://journal.tinkoff.ru/diary-vladelec-it-kompanii-moscow/
И совсем не важно, что создать свой панцер генерал не получилось: навыки, которые получаешы при разработке игр, очень круты и разносторонни, типовые мэйнстримовские проекты вроде интернет-магаза или просмотрщика котиков до игр обычно сильно не дотягивают (на 1-2 порядка проще). Я несколько раз переходил из разработким игр в бизнес-проекты, и каждый раз удивлялся, насколько в них всё просто и примитивно в сравнении с gamedev-ом.
https://journal.tinkoff.ru/diary-vladelec-it-kompanii-moscow/
И совсем не важно, что создать свой панцер генерал не получилось: навыки, которые получаешы при разработке игр, очень круты и разносторонни, типовые мэйнстримовские проекты вроде интернет-магаза или просмотрщика котиков до игр обычно сильно не дотягивают (на 1-2 порядка проще). Я несколько раз переходил из разработким игр в бизнес-проекты, и каждый раз удивлялся, насколько в них всё просто и примитивно в сравнении с gamedev-ом.
Т—Ж
Как живет владелец ИТ-компании в Москве с доходом 2 млн рублей в месяц
Сдает три квартиры, планирует купить дом и воспитывает двоих детей
Несколько фундаментальных архитектурных принципов, абсолютно обязательных сегодня для любого серьёзного ИТ-проекта, уважающего своих пользователей:
-- серверы должны масштабироваться горизонтально, а не вертикально (почему, я поясняю на курсе по highload-системам);
-- архитектура желательна федеративная (например, пиринговая), чтобы небольшая группа засланных казачков не могла выполнить рейдерский захват проэкта :)
-- в системе должна быть встроена блокировка любой внешней рекламы;
-- система должна хранить только самый минимальный объем персональных данных (которые надо бэкапировать отдельно, чтобы легко можно было удалить при необходимости), и периодически вычищать устаревших пользователей;
-- система должна через свои внешние API предоставлять самый минимум мета-данных, дополнительно "загрязняя" их, чтобы усложнить их использование шпионскими системами машинного обучения;
-- обязательно шифрование на стороне клиента, чтобы оператор на сервере не мог увидеть реальные данные в формате обычного текста.
-- серверы должны масштабироваться горизонтально, а не вертикально (почему, я поясняю на курсе по highload-системам);
-- архитектура желательна федеративная (например, пиринговая), чтобы небольшая группа засланных казачков не могла выполнить рейдерский захват проэкта :)
-- в системе должна быть встроена блокировка любой внешней рекламы;
-- система должна хранить только самый минимальный объем персональных данных (которые надо бэкапировать отдельно, чтобы легко можно было удалить при необходимости), и периодически вычищать устаревших пользователей;
-- система должна через свои внешние API предоставлять самый минимум мета-данных, дополнительно "загрязняя" их, чтобы усложнить их использование шпионскими системами машинного обучения;
-- обязательно шифрование на стороне клиента, чтобы оператор на сервере не мог увидеть реальные данные в формате обычного текста.
👍1
Есть хорошая, в принципе, книжка "97 things every programmer should know", и её переводы на русский:
https://97-things-every-x-should-know.gitbooks.io/97-things-every-programmer-should-know/content/ru/
https://www.transl-gunsmoker.ru/p/97.html
Конечно 97 темок это здорово, но они тут никак не систематизированы, набросаны линейно и вперемешку, а главное, что фактически почти все они -- просто следствия гораздо более глубоких инженерных принципов и научных парадигм в computer science, которые конечно в этих правилах никак не упоминаются.
Собственно, и сами авторы сборника говорят:
"Здесь нет никакой общей идеи повествования: цель сборника - просто собрать многочисленные и разнообразные взгляды на то, что следует знать программистам, по мнению участников проекта. Это может быть что угодно от совета по коду до культуры, от использования алгоритма до agile-мышления, от внедрения ноу-хау к профессионализму, от стиля к сути и т.д."
Резюме, что один разок просмотреть стоит, и если в голове останется хотя бы 2-3% - уже будет хорошо :) Но лучше изучать фундамент cs, который будет свободно и легко порождать нужное именно вам множество подобных оригинальных правил, оптимальных именно для вас, для вашего стиля разработки.
https://97-things-every-x-should-know.gitbooks.io/97-things-every-programmer-should-know/content/ru/
https://www.transl-gunsmoker.ru/p/97.html
Конечно 97 темок это здорово, но они тут никак не систематизированы, набросаны линейно и вперемешку, а главное, что фактически почти все они -- просто следствия гораздо более глубоких инженерных принципов и научных парадигм в computer science, которые конечно в этих правилах никак не упоминаются.
Собственно, и сами авторы сборника говорят:
"Здесь нет никакой общей идеи повествования: цель сборника - просто собрать многочисленные и разнообразные взгляды на то, что следует знать программистам, по мнению участников проекта. Это может быть что угодно от совета по коду до культуры, от использования алгоритма до agile-мышления, от внедрения ноу-хау к профессионализму, от стиля к сути и т.д."
Резюме, что один разок просмотреть стоит, и если в голове останется хотя бы 2-3% - уже будет хорошо :) Но лучше изучать фундамент cs, который будет свободно и легко порождать нужное именно вам множество подобных оригинальных правил, оптимальных именно для вас, для вашего стиля разработки.