То, чему я учу на курсах -- на 90% академические университетские темки. Но это не взятые с потолка условные курсы по матану например (маркетинговая "математика для программистов"), нет.

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

1. Как понять в программировании всё. Семантика Software Design, 5 базовых вычислительных моделей (декларативная/функциональная, императивная, объектная, реляционная, и UI-модель).
2. Объектно-ориентированный анализ и проектирование.
3. Функциональное программирование.
4. Теория highload-систем.
5. Параллельные вычислительные модели.
+ формат hard work (software design на практике).

Это вечные классические темы, к которым и прибавить особо нечего.

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

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

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

Когда отправил пулл-риквест в свою любимую игру, а тебе ответили:
"Thanks for the report. This will be fixed in 2.0. In the meantime you can work around this issue by simply not doing that"
😁

А вы уже начали собирать GTA 5 из утекших исходников (40 гиг)?

Исходники GTA кстати ужасающи, сплошной говнокод.

У меня ребята, кто прошли самые первые начальные курсы с полного нуля, такое не пишут. Высокая цикломатическая сложность, циклы, вложенные в условия, вложенные в циклы, while вместо for, куча unsafe указателей...
Смесь плюсов, питона и, вроде, max noscript... Нескончаемые сотни багов, некоторые из которых стали культовыми...

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

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

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

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

Ну, в целом, конечно, неполнота по Гёделю это факт, но в каждом конкретном проекте достичь идеала вполне возможно, и это как раз давно доказано и математически, и инженерно.

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

Эта девушка занимается на моих курсах, и в Новый Год её волнует только один вопрос: как гарантировать холодный старт системы, в которой кэша нету принципиально, за 100 мс?

С Наступающим! 🎄🎄🎄🎄

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

Например, мы определили деление как операцию только для ненулевых знаменателей. Тогда терм 'x / 0' нельзя далее редуцировать, но он при этом и не значение.

=
А логическая консистентность подразумевает, что не существует способа сконструировать терм из любого типа.

Ну например в F# возможно такое:

let rec foo() = foo()

Задайте foo любой тип, и получите терм этого типа.

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

=

И что из этого? Ну, не понимая такие вещи, вы не сможете продуктивно программировать на языках с зависимыми типами, да и вообще работать с HoTT-типами, следовать type-level программированию и метапрограммированию с dsl-ями, да и просто правильно применять генерики. И никогда не станете x1000 программистом.

Хватит уже лежать физиономией в салатах, поднимайтесь! :)

А как достичь x1000 ? Легко и просто.
Например,

1. Переходите с C# на F# и получаете в 10 раз меньше кода и в 10 раз выше надёжность (за счёт более сильной системы типов).
= x10

2. Переходите с F# на F* (всё никак не выложу моё введение во введение в F*) и получаете следующие x10 за счёт мышления в парадигме зависимых (от значений) типов.
Вы учитесь "сворачивать" разрабатываемую систему во всё более мощные абстракции.
= x100

3. Переходите с F*, ну куда-нибудь "окончательно" в "высшие" типы, HKT, HoTT...
Получаете за счёт "просветления" ещё x10. Начинаете думать непосредственно на языке предметной области, который формализован в вашем уме через соответствующие абстракции.
= x1000

...

Да, но, Сергей Игоревич, мы ведь вынуждены писать на C#...

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

Никто вам не мешает начать использовать уже сегодня на C++Rust/C#/Java любые фишки сперва функционального программирования, затем завтипы, и так далее. Есть соответствующие библиотеки, а некоторые языки можно нативно расширять (для F#, помнится, было расширение по зависимым типам).

Вы можете начать в любом языке, например, с использования императивных монад, монад I/O, монад побочных эффектов, выразите через монады мутабельность, потом переходите к свободным монадам, in-bounds/out-of-bounds...

Новый пост: Как сделать ИТ-Россию великой, и зачем нам стремиться к зарплате/доходу в миллион рублей в месяц.

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

Пять лет не заглядывал в линкедин, вчера посмотрел, и вот что я написал там в 2019-м =>

"Обучаю MLTT, HoTT, индуктивным типам, процесс-алгебрам/pi-калкулусу, кодированию топосов, hopf fibrations и прочей попсе, которая сделает вас полностью unemployable." )))

Но сам сервис стал совсем зашкварным. Вот кстати фишечка, как скрыть все "рекомендуемые" посты:
https://www.linkedin.com/#%23span:has-text(/Suggested/):upward(4)

Для курсантов в раздел "Элитный программист" добавил 37-й материал "Как справляться с некомпетентными новичками".
К программистам придираются далеко не только нетехнические менеджеры и офисные начальники. Я уже сбился со счёта, сколько раз наблюдал, как опытные программисты возмущаются глупыми ошибками, которые допускали младшие разработчики. Но это тоже ситуация, с которой можно справиться, взяв ответственность на себя.
Например, сеньоров раздражает, когда джуниоры не используют git, или фигачат комиты сразу в мастер, не пишут юнит-тесты, задают глупые вопросы, ответы на которые можно нагуглить за пять минут...
Действительно, возня со всем этим отнимает у старших немало времени и сил. И вот что с этим делать ...

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

На курс карьеры добавлен 83-й материал "Как проходить стажёрство/испытательный срок". Главное, что вам надо делать, когда вас взяли стажёром или на испытательный срок -- это понять 5 важных принципов...

...и по СильнымИдеям:

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

И 81-й -- про миграции (ORM-ы с роллбэком). Это сложно, но на практике оказывается ещё сложнее )))

Почему down-миграции, которыми так хвастают многие фреймворки -- дескать это чуть ли не ключевая их фича -- на практике не работают. Разбираем 4 неочевидных подводных камня (в дополнение к highload-курсу по транзакциям).

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

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

Скоро в СильныхИдеях выложу мощный контринтуитивный материал про правильный подход к организации тестирования крупных систем.

Понемногу активирую Волшебный МультиПендаль 2024.

Существенно обновил "дипломный" проект, который в основном делают ребята, кто готовится к работе на бэкенде (для курсантов проект обязателен и бесплатен, но наверное сделаю и платную версию "для всех"). Фреймворк (разные для Java, Python, C#, Go, PHP...), CRUD, REST, отношения между модельками ORM (1-1, 1-многие, многие-многие), авторизация/видимость, пагинация, таймзоны, ui с бутстрапом, геоданные, и ещё немало другого по мелочам. Забираемся внутрь ORM, делаем бота, упаковываем в докер, деплоим.
Это то что было, и вот добавил ещё несколько темок: кэширование, логирование, документирование API, интеграционные тесты, ci/cd, транзакционная работа, микросервисы :)
Всего 34 задания (пока) получилось.

Кто проходил со мной этот проект, рекомендую доделать новые фишки.

При всех разговорах о сложных инженерных профессиях программисты в среднем намного умнее своих коллег из этих профессий. Потому что computer science = абстрактное мышление + решение "головоломок". Абстрактное мышление в целом скорее противоречит инженерным подходам, которые по определению ориентированы на практику и физическую реальность, но оно очень важно для того, чтобы быть умным.

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

Меритократия наше всё.

P.S. Особенно AI-меритократия :) Слава роботам!

За какую сторону я -- не скажу , но для меня субъективно разница в основном, что в deb много чего под ключ, но работает часто фигово, а в rpm наоборот -- готовых пакетов поменьше, но работают гораздо устойчивее. И в результате нередко приходится мучиться вот так: "install vim-deb on RHEL".

Между прочим, скрипт-язык свежего vim 9.1 стал поддерживать ООП (даже с абстрактными классами) 😁