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

-- "Доказательства и опровержения" Имре Лакатос. Элегантно и увлекательно рассказывается о математической логике;
-- "Как научиться решать задачи" Фридман, Турецкий. Была рекомендована в СССР даже учащимся ПТУ :)
-- "Как решать задачу, когда не знаешь как" Кашуба -- совсем простенькая в методологическом плане, но была рекомендована в кружке мехмата МГУ например;
-- "Как решают нестандартные задачи" Канель-Белов, Ковальджи. Разбор решений нестандартных олимпиадных задач;
-- конечно, Пойя "Как решать задачу", "Математика и правдоподобные рассуждения".

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

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

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

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
"Не опустить университетский курс в среднюю школу, а поднять курс для дошкольников в начальную школу -- и навыки в объёме ОГЭ по информатике закрыть уже в начальной школе. И этот второй заход оказался успешным!.."

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

Многие люди, кодящие даже на "современном" C++20, оказывается, не знают, что там давным давно есть завтипчики:
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-ом и иммутабельностью -- правильным применением практик декларативного (в частности, функционального) программирования.

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

Удивительный тренд: хаскелисты массово переходят на раст.
Впрочем, после хаскеля раст очень хорошо заходит! Вроде бы это шаг назад в императивщину, но нет, 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. И преподов готовить, только тоже не массово, а точечно.

Вы сами должны быть самым первым и объективным (и желательно, придирчивым и занудным) ревьюером вашего же кода. Если ваш собственный код труден вам же для code review, то он тем паче будет труден для понимания другими :)

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

Отовсюду лезет реклама AI pair programmer
https://copilot.github.com/
смешно, что в примере parse_expenses.py используется float для хранения денег хм.
Это абсолютная ошибка проектировщика и никогда так не надо делать, но -- но бывает ли это реальной проблемой?
Помнится, из 1990-х история, как некий умник в каком-то американском банке подправил логику округления (32-разрядный float наверное в 5-6 знаке ошибается), и по центу с лавины округлений денежных транзакций сбрасывал себе на счёт, и якобы стал миллионером. Но с тех пор каких-то эпикфейлов из-за использования стандартных типов с плавающей запятой для хранения денежек особо не было слышно.
Впрочем, совсем не исключено, потому, что мэйнстрим пробил дно уже так, что данный тип багов, несмотря на массовое явление более-менее норм типов из коробки вроде decimal, стал повсеместным :-)

Из ИТ-сфер, которые мощно поднялись в 2021-м, больше всех разбогател, хм кто бы мог подумать ))) геймдев. 2,7 миллиарда активных игроков!

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

Я в 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 той же командой, что и линейку делала :-)

Поучительный пример, как полезно "войтивайти" через геймдев.
https://journal.tinkoff.ru/diary-vladelec-it-kompanii-moscow/
И совсем не важно, что создать свой панцер генерал не получилось: навыки, которые получаешы при разработке игр, очень круты и разносторонни, типовые мэйнстримовские проекты вроде интернет-магаза или просмотрщика котиков до игр обычно сильно не дотягивают (на 1-2 порядка проще). Я несколько раз переходил из разработким игр в бизнес-проекты, и каждый раз удивлялся, насколько в них всё просто и примитивно в сравнении с gamedev-ом.

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

Есть хорошая, в принципе, книжка "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, который будет свободно и легко порождать нужное именно вам множество подобных оригинальных правил, оптимальных именно для вас, для вашего стиля разработки.

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

Дико уважаю:
https://habr.com/ru/post/569522/
Как правильно относиться к своему обучению и к поиску работы, эталон для подражания.

"Я была по обе стороны собеседований, суммарно их около 100+ наберется...
Если бы мне кто-то сказал курсе на 2-ом, что нужно прорешать 500+ задач и попробовать податься, как postgraduate, то я бы обязательно попробовала, хотя и была очень не уверена в себе...
Я старалась решать по 2-4 задачи в будний день из разных разделов, это примерно 4 часа в день до/после работы. Например, одна на строки, другая на графы. Разделам, где я проседала больше, выделяла отдельное время - в частности, на динамическое программирование. Полностью вся суббота и часть воскресенья уходили на подготовку. Будьте к этому готовы, подготовка съест очень много вашего личного времени. На текущий момент у меня 352 задачи..."

Впрочем, ещё философ Гераклит говорил, что таких людей -- 2-3 процента.
Лишь несколько человек из ста станут профессиональными бойцами, но не более. Остальные — серая масса, которая погибнет при столкновении с серьёзным противником.
Кто вы по жизни? Воин, боец или серая масса, у которой в голове интровертная манная каша из невротического мусора?
Этой девушке всего 25 лет! Ну, да, сегодня многие пацаны куда трусливее девчонок.

Джоб-сайты для айтишников совсем перестают работать в смысле реальной помощи в поиске работы.
Особенно это чувствуется в регионах, чем дальше от msk/spb, тем резко меньше от них толку.
В целом провал также отмечается по всем IT- и инженерным специальностям независимо от места жительства.
Говорил об этом ещё года два назад: шаблонные схемы поиска работы скоро погибнут. Ну и вот.
Новое поколение разработчиков и рекрутеров не желает более возиться с олдовыми сайтами, впустую тратить время на заполнение и просмотр многостраничных резюме и вакансий, где за расплывчатыми формулировками нифига обычно непонятно. Да и персональные данные на них сливать теперь совсем немодно.
Сейчас основной тренд по поиску работы -- соцсети, где можно мгновенно пообщаться с кандидатом или работодателем.
Соответственно, если ваша страничка в соцсети и гитхаб отстойные -- по ним не видно, как вы регулярно фигачили последние год-два в плане развития в профессии -- ну штош...
Кто не старается добиться настоящего успеха стратегически, кто хочет добиться быстренького "успеха" к следующему вторнику -- всегда будет проигрывать.

.