Давайте будем честны: быть программистом с быстрым, творческим умом, движимым сильными идеями -- это одновременно и благословение, и проклятие.

Бывают дни, когда тебя невозможно остановить.

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

Если что-то из этого покажется вам знакомым…

Посмотрите, сколько этих пунктов для вас верны:

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

Если вы ответили "да" хотя бы на несколько из них… нет, вы не сломлены.

Вы просто управляете невероятно мощным мозгом без подходящей операционной системы.

А чтобы её себе инсталлировать, вам нужно заняться математикой и computer science! В частности, научиться глубокой функциональной композиции на языках λ-куба Барендрегта.

Есть вечная двойственность в продвинутом обучении программированию...

С одной стороны, мы можем сперва мощно прокачивать свою базу (базу в смысле Старкрафта/Варкрафта :), а затем выполнять молниеносный успешный раш вообще на любую проблему. Например прокачавшись как следует в профильной математике, в том же функциональном комбинировании -- развив пресловутое сильное рациональное мышление -- мы будем видеть любые повседневные архитектурные схемы как задачки для третьего класса, которые решаются просто в режиме непрерывного набора идеально работающего кода (Make Illegal States Unrepresentable) даже без особого думания на медленном мышлении S2 по Канеману. Главный минус -- для этого требуется существенное время, и имеет ли ради этого жертвовать несколькими годами карьеры, вопрос открытый.

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

Противоположное Computer Science сегодня -- это когда надо хорошо знать System Design, но тоже больше на уровне "зазубрить шаблоны" и скомбинировать десяток "квадратиков" на диаграмме (и хорошо ещё, если это C4). Уметь красиво рассказать на собесе "как написать свой нетфликс", для чего достаточно изучить три гайда (но технические знания конечно должны быть на уровне). Главный минус -- в результате имеем совсем узенькое системное мышление, крайне хрупкое понимание, сразу ломается на новом проекте, где на 15% другой стек, даже CRUD фиг перенесёшь. Но зато быстро.

=

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

повысить производственное мастерство x10..x100, не прокачивая скиллы.

База в cs конечно нужна, но тут вполне достаточно 3-4 первых треков второй части Лаборатории. Более теоретические темки буду постепенно добавлять однозначно (языки вроде Lean4 всё же тяжеловато ребятам осваивать, если в хороших университетах не обучались... хотя вот в SMT-солверы с моего гайда въезжают только так практически все :), но пожалуй

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

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

...Потому что в 98% реальных проектов, даже на тысячу таблиц, программист мало когда использует 3-5 паттернов на одну фичу (да и то редко когда сознательно; как известно, в тысяче строк любого кода найдётся хотя бы одна монада, но кто об этом знает :).

7-9 -- уже сложный случай (порт/адаптер, оркестрация...), и как правило тут паттерны выражены аннотациями/конфигом, а не "ручным" кодом.

Ну например, этот ваш CRUD будет таким паттерном:

controller/endpoint -> mapper (dto, entity) -> use case (service) -> repo -> db

Сквозной путь запроса/кейса -- максимум 10–12 логических шагов (включая нутро фреймворка!). Переходов между bounded contexts при этом -- три максимум, хопов DI-зависимостей -- пять максимум. и т.д.
на эту тему в СильныхИдеях на днях выложу материал
"Проектирование "снизу вверх" через рефакторинг (и при чём тут зависимости)"

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

...Ладно, спалю базу: хорошая архитектура -- это не больше слоёв/глубже комбинаций паттернов, а меньше "случайной" сложности при сохранении явных инвариантов. Держим сквозной путь ≤10-12 и автоматизируем всё, что не домен.

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

Ставьте на чистую доменную модель с явными границами, конвейеры политик и Functional Core/Imperative Shell (максимум логики в чистом ядре, "эффекты" на границах, причём "эффектный" слой должен быть как можно тоньше).

+ Рекомендую capability-ориентированный дизайн: это когда глупенький пишет тупой CRUD...

user.setStatus("ACTIVE");
userRepository.save(user);
// да, но с какой целью??

...а умненький явно выражает бизнес-намерение:

userActivationService.activateUser(userId);

=

Далее выявляем порты -- интерфейсы на границе домена, которая таким образом задаётся явно. Затем определяем соответствующую алгебру -- формальную сигнатуру операций на этой границе (что домен требует от внешнего мира? БД, REST, брокер?).

Алгебра в данном контексте -- это абстрактный набор операций предметной области (подписание платежа, чтение корзины, генерация UUID), заданных как чистая спецификация (а уж под каким эффектом это исполняется -- не важно). Мой гайд по абстрактным типам данных в ООП в помощь, а в ФП это что-то типа Tagless Final/Free Algebras (что тоже разбираю в соответствующем гайде :).

Ну и далее "интерпретатор" реализует алгебру поверх конкретных эффектов/технологий (DB/HTTP/...)...

=

Учимся по BDD распознавать (неявные) вариации и ограничения в ТЗ и маппить их на паттерны. По моим оценкам, таких паттернов около 50, ну может под сотню. Готовой теории, которая бы их охватывала и систематизировала, у меня нету, поэтому сперва их надо сформулировать и классифицировать, затем добавить функциональное описание, затем формальное, а потом и сама теория родится, полагаю, естественно и легко.

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

Ценность младшего разработчика составляет, наверное, около 20% в виде написанного им кода, а 80% -- это аванс на ближайшие год-два, когда он уже не будет младшим. Всё, что тут может AI -- это лишь немножко заменить первые 20%...

Все сегодня стремятся внедрить модные фишки AI -- агенты, RAG, серверы MCP, инструментальные решения...

За шумихой скрывается мрачная правда: большинство команд идут на невидимый (и невероятный по потенциальной катастрофичности) риск.

Баги просачиваются через тесты и логи. Выдача LLM-ок не поддаётся проверке. Зависимости и контейнеры формируют цепочки мутных последствий, которые никогда не придут человеку в голову. Архитектура превращается в набор костылей вокруг "магии" чёрного ящика. Внешние сервисы получают неконтролируемый доступ к ядру данных, а стаи агентов самостоятельно принимают решения, о которых вы узнаёте постфактум, когда уже всё рухнуло безвозвратно. Идемпотентность и ACID-транзакции размываются в угоду "гибкости". Цепочки вызовов не имеют единой точки отказа -- но и не имеют единого состояния истины, и существуют словно в сферическом вакууме.

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

"Хотя… скоро, на мой взгляд, вообще никаких тем не будет. Грядут крайне тяжелые времена и коснутся они всех, так или иначе. Впереди ждут долгие и многие годы, наполненные ужасом и унынием. Не думайте, что я какой-то паникер или специально смуту развожу. Вовсе нет. Просто делюсь внутренними ощущениями. И кажется мне, что ничего хорошего будущее не предвещает.
Да и когда в последний раз был хорошо и спокойно?"
-- Мэд

😁

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

При том, что их система -- это когда фронтенд зависит от бизнес-логики (через тот же REST), а бизнес-логика в свою очередь зависит от базы данных "под ней" (то есть слой UI максимально удалён от слоя работы с данными, между ними есть промежуточный доменный слой).

Ну, а разве у вас по-другому? :)

Да, но это есть прямое нарушение DIP:

Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.

А у вас логика домена (концентрат всех ваших абстракций, вся ваша система типов) зависит от логики доступа к данным.

Ну и какой тут солид-шмолид...

Думайте.

Смешное: Nearly All Binary Searches and Mergesorts are Broken

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

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

Никакое архитекторство тебя не спасёт, когда в твоём проде низкоуровневый говнокод :)

Никуда в конечном итоге будет не деться от формальной верификации...

.

Облако драгоценностей за неделю.

Приватный клуб:

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

Для донов-начинающих:

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

75%+ взрослых людей от 25 лет могли бы выбрать любой интеллектуальный/инженерный навык и пробиться в топ-10% в мире, просто работая исключительно над этим каждый день в течение двух-трёх лет. И это с нуля...

Ни Оксфорд ни Гарвард ни МГУ никаким "реальным проектам" и скорейшему применению информатики "на практике" принципиально не учат, наоборот: на протяжении всех 4-6 лет даётся всё больше теории computer science и математики...

Для донов-неначинающих:

Почему вам не получается расти?..

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

(все старые материалы для донов постепенно сгорают)

=

Первые сериалы из существенно переработанных и улучшенных материалов СильныхИдей (по сути три книги) доступны на бусти:
1. БАЗА программной инженерии
2. Software Design с акцентом на Programming in Small
3. SOLID-25
4. Гайд Вайб-проектирование

🚀

=

Новые материалы для ментатов Лаборатории.

Важно: уточнены правила занятий п.10.1.2.8: каждые календарные полгода вы должны (бесплатно) перепроходить три первых курса АСД, а затем дополнительные курсы АСД...

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

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

💪🏻

Мы здесь, потому что это трудно.
it's a privilege to do things that are hard.

=

"ЛаМПовое": стратегема Agile-Манифеста, vim, "Диспетчер", внешние API, 60% неудачных сборок CI, "Алиса в Стране чудес невыученных уроков". ...

"...В [...] сходил на техническое собеседование. В целом прошло неплохо, но не хватило уверенности в решении задач на кодирование. В целом все как обычно. Видимо, надо целенаправленно усиливать это направление. Первая вакансия за долгое время, где жалею, что не прошел. По крайней мере по описанию вакансии там должно было быть интересно.
Была еще третья компания. Сами написали, давно такого не было. Хотели опыт в процессинге/эквайринге, которого у меня нет, поэтому дальше разговора с HR'ом не пошло.
Спросили бы отказоустойчивый кластер Kafka настроить, тут я с закрытыми глазами...

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

Мы же это ещё на первом курсе АСД проходили!!1 )))

+ с тех пор я добавил в каждый курс АСД десятки новых задачек посложнее, и теперь периодически всем ментатам надо будет перепроходить эти курсы (а также дополнительные, которые я делал по лекциям ШАД), дабы быть готовым к лайв-кодингу 💪🏻

АСД -- вечная база для собесов!

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

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

Смысл мема => R⁴ -- группа вращений квадрата (циклическая группа порядка 4). Поразительно, но Филдсовская медаль была вручена за Exotic Smooth Structures, бесконечным числом коих обладает только R4. Для любого другого пространства Rn при n != 4 существует ровно одна гладкая структура (только один "естественный" способ определить на нём понятие гладкости и производной).

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

Кто изучал матан, знает, что анализ в R4 особенно сложный.

В 3D-графике точки часто представляют в однородных координатах (вектор в R4 [x,y,z,w]).

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

p.s. Математики подправили: "R^4 - это не группа вращений квадрата и не циклическая группа порядка 4. Группа вращений квадрата - это частный случай группы диэддра, она конечна, у нее порядок 8."
Конечная группа вращений квадрата — это C4. А R⁴ — это четырёхмерное топологическое многообразие, гомеоморфное стандартному четырёхмерному евклидову пространству.
Exotic differentiable structures on R^4

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

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

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

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

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

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

Тут хорошо бы сперва купить у меня побольше курсов пройти "как понять в programming in small всё", где разбираем исторические корни ООП и его место в десятках других подходов, затем мой гайд по объектной вычислительной модели, после чего, надеюсь, будет хорошее понимание и концептуальной структуры ООП, и более сильных подходов.
(Какой ещё полиморфизм в ООП? Смешно. Так, детский лепет...)

Потом трек по ООАП, где получаем наивную формализацию ООП через абстрактные типы данных, включая понимание концепции модулей. Но делаем задания по реальному "объектному" кодингу только на чистом С++ (потому что множественное наследование и дружественные функции), а потом на его темплейтах.

Ну и наконец изучаем взрослую формализацию ООП в теорем-прувере Lean (или на моей реализации HoTT).

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

Но никто не говорит, что вы идиот, если вы ищете в гугле, кто выиграл Тур де Франс в 2002-м году. Теперь вы можете использовать ресурсы своей памяти для чего-то более полезного.

Таким образом, вопрос не в том, разрушит ли AI наш мозг.

Сермяжный вопрос заключается в следующем:

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