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

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

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

Как таким "продавать" на своей работе ФА/ФП/ФМ - как в их же глупеньких интересах "поскорее подешевле", так и в интересах всей команды прежде всего - поясняю ментатам в ФА 🔥

.

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

С (вчерашним) Днём Программиста!
"Не спать всю ночь, писать код — звучит как вечеринка"
- Леонард (ТБВ)

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

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

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

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

...Многие начинающие считают, что диплом вуза, официальный сертификат крупной компании, условный сертификат/диплом о завершении онлайн-курса будут иметь достаточно большое значение при приёме на работу.
Но это никогда так не работало, а сегодня тем более.
Диплом/сертификат сам по себе не даст вам работу.
А если кто-то говорит вам, что так и будет, он, вероятно, пытается продать вам онлайн-курсы :)

(лонгрид) Многие профессиональные программисты заявляют, что начинающим не следует использовать искусственный интеллект при изучении алгоритмов и структур данных.
АСД -- это вечная тема которая например практически всегда возникает на собеседованиях, так как задачки сами по себе относительно небольшие и автономные.
Я с этим согласен, но не на 100%...

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

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

Продолжаю выкладывать для донов материалы СильныхИдей.
105. Гомоморфизмы и абстракции (важное дополнение к материалу об абстракциях)
Определений абстракции в программировании существует множество.
Первое определение: давать имена сущностям, созданным в соответствии со вторым определением. :)
А вот второе определение естественно вытекает из первой теоремы о гомоморфизмах и её обобщений в универсальной алгебре...

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

=

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

В курс карьеры добавлен 147-й материал "Специфика найма на удалёнку: 5 правил".
Работа на удалёнке во многом сильно отличается от работы в офисе, но далеко не все это учитывают...

В СильныеИдеи добавлен материал "157) База System Design".
Самый быстрый способ испортить проект -- это масштабировать всё что попадается под руку, прежде чем выяснять, что на самом деле актуально под масштаб.
Самый быстрый способ загнать проект в тупик -- это игнорировать те 20% сквозных путей (от клиента через api и бизнес-логику до базы и обратно), по которым 80% пользователи проходят весь день.
Хороший System Design располагается где-то между этими двумя ошибочными подходами...

=

"Функциональные архитектуры" 171(+3) топиков.
Продаём ФА/ФП/ФМ твоему тимлиду/CTO

Last Principles Framework: базовая версия закончена, доделываю косметические детали, на неделе будет добавлена в трек ФП.
Вы же понимаете например, что любые ваши сложные пайплайны и воркфлоу будут разваливаться, если сложность не ослабляется осознанно до когерентных высших морфизмов?

=

"ЛаМПовое":

UML жив, связь математики с безумием, почему OCaml топчик

=

Мы здесь, потому что это трудно. 💪🏻

=

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

"Да не сотворишь машины, наделённой людским умом."

"Дюна"

Вайбкодите на астре-шмастре, клон любого программного продукта за пару часов?

Ok, как прилетит от РКН штраф например за некорректное хранение персданных (или за любой другой из 100500 поводов) - миллиончиков так на 10, сразу службу поймёте, что такое взрослый software design :)

В трек по функциональному программированию добавлен Last Principles Framework (теория категорий для разработчиков). Разбираем все эти понятия с полного нуля очень компактно, поймёт любой миддл, тем более после трека ФП. Задачки/квизы (38 штучек) несложные, с разбором, все в теме system/software design, hand made :)

=>

Категория. Объекты + морфизмы/стрелки, тождество и ассоциативность композиции.

Композиция, домен/кодомен.

Мономорфизм, эпиморфизм, изоморфизм.

Функтор (отображение между категориями), контравариантный.

Натуральное преобразование (морфизм функторов), коммутативный квадрат.

Категория функторов (объекты - функторы, морфизмы - натуральные преобразования).

Универсальное свойство. Начальный и терминальный объекты.

Произведение (категориальное). Копроизведение (сумма). Обобщение произведения (диаграмма).

Экспоненциал (внутренний Hom).

Сопряжение (естественный изоморфизм).

Пределы и копределы. Конус и коконус. Ядро, уравнитель, обратный предел.

Монада (тройка), эндофунктор, аксиомы.

Алгебры над монадой. Категория алгебр.

Категория Клейсли (для монады), композиция через склейки.

Лемма Йонеды.

Категории с дополнительной структурой. Декартово замкнутая. Топос.

Стрелки Чу. Пучки.

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

🤓

...На самом деле, тут правильнее сказать, не теоркат изучаем, а встраиваем формальную думательную машинку как рассуждать и об system design, и об software design, ибо тут имеется ровно один математический способ делать это верно. Вы же понимаете например, что ваши fold/reduce никакая не функциональщина а карго-культ, если вы не гарантируете моноидально корректность этой свёртки. Ну или можете продолжать "покрывать код тестами", прости господи, т.к. это очевидное следствие того, что ты просто не понимаешь, как работает твой код, и никаким формализмом его корректность не гарантирована даже на 2%.

Я: - У вас имеются технические характеристики [вашей гигантской легаси-системы]?

Клиент: - Да, вот презентация в поверпоинте из двух слайдов.
и/или
- Да, вот ворд-документ с детальными описаниями на 7000 страниц, там правда текст прозаический не очень структурированный, и вдобавок док очень плохо грузится.

"...А еще поняла, что если что-то непонятно в PR, то лучше спросить, чем промолчать. Однажды, задав несколько вопросов, я выяснила , что соседняя команда планирует выводить в следующем релизе изменения, которые сломают наш API. Написала аналитику, выяснила, что произошло недопонимание – обе стороны были уверены, что все ок."

"...К сожалению, коммитить спецификации в прод пока нельзя, буду работать с ними локально."

(из свежих отчётов)

...Это я к тому, что так работает (попытка внедрить) BDD/SDD на практике. (AI)спеки - что они представляют-то? Аналитик что-то накидал, openspec перевёл это в "спецификации", но у кого-то из них есть целостная модель системы, из которой они исходят? Могут показать?

Интерпретация ТЗ (богатой семантики) превращается по сути в самое слабое звено. Нагенерила нейронка 100500 спек/требований, и что толку, что они человекочитаемые, когда нету никого, у кого в голове есть системный образ, который увязывает это всё и позволяет делать полноценные ревью.

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

Я: - Обнаружил тут, что ваша система делает [что-то], но в вашей документации подразумевается [что-то другое].

Клиент: - Ага, да это не имеет значения.
или
- А мы это изменили шесть месяцев назад.

...Я: - Вы хотите, чтобы спецификация допускала [такое-то поведение]?

Клиент - эээ… не знаю, я никогда не думал об этой ситуации.

Я: - И если вы это разрешите, вам также придётся разрешить [и какое-то другое поведение]. Это имеет значение?

Клиент: - Я тоже не знаю, как обстоят дела в таком случае… Мне надо посоветоваться, не знаю сколько времени это займёт...

=

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

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

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

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

Что с этим делать? На Функциональных архитектурах разбирал например тему Мета-DSL, когда мы осознанно уходим в языки с бедной семантикой.

...При том, что на самом деле никакие спецификации не существуют, ибо теоретически невозможно написать абсолютно точную и последовательную спецификацию.

...И тем не менее, я продолжаю и продолжаю обучать ребят этому всему, и в современной ситуации это уже напоминает, как мастер Йода учил подпольщиков-джедаев.

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

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

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

Жизнь сложна. Так сделайте её ещё сложнее :)

Эталонный пример дебилизма на всех уровнях - от топ-менеджеров до проектировщиков. Сентябрьский Гран-при Формулы 1 в Мадриде оказался абсолютно зашкварным ("нас не обгонят"):

"Ни на одном этапе (кроме Монако) меньше 47 обгонов зафиксировано не было. В Мадриде же их было всего четыре!..
Ферстаппен сразу после того, как опробовал трек на симуляторе, заявил, что обгонять на нем нереально...
Не представляю, чтобы кто-то, просто взглянув на конфигурацию трассы, сказал: Класс! -- Норрис..."

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

А ведь решалось это элементарно, достаточно было просто попросить экспертов исходно оценить проект -- "просто взглянув на конфигурацию трассы". Это же вообще бесплатно! Ну а если есть сомнения, то сделать сперва симулятор трассы, всё равно это будет на многие порядки дешевле, чем когда "директор трассы Луис Гарсия Абад пообещал все переделать" )))

Как раз в тему BDD/SDD, на Функциональных архитектурах я подробно разбирал в большом модуле - конкретно "Мета-спецификации", десятки материалов - именно то, что непосредственно и сами спеки по себе, и реализация, могут быть идеальными, да что толку, если ни у кого из десятков менеджеров и проектировщиков в голове не возникал самый базовый вопрос системной инженерии: в чём цель системы?

Детский сад штаны на лямках.

"Первая версия, похоже, стала образцом того, как не нужно проектировать гоночные трассы." (и это на фоне огромного опыта проектирования успешных трасс)

Переделывайте нафиг! :)

Мак не тянет и 10% того агентского AI-пайплайна, который прекрасно работает в линуксе на аналогичном железе.

- Сергей Игоревич, можно я сегодня уйду с работы пораньше? Жена просит съездить с ней за покупками.
- Нет! Сидите и пишите код.
- Огромное вам спасибо, Сергей Игоревич!

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

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

И я буду стараться изо всех сил, дабы передать последние формализованные кусочки и этого, и мирового (стремительно исчезающего) опыта, небольшой команде мотивированных энтузиастов! 🚀

Навайбкодили: гитхаб поломался, и на ркн свалить наверное не получится, пацаны пишут, что "проблема где-то около Франкфурта-на-Майне, в Германии (DE-CIX-FRA-IXP)".

Совершенно не удивлён, и дальше, по мере роста объёмов кода, безумно ускоряемого "с помощью" AI, будет только хуже.

Дорогим занимающимся напомню, что в таких случаях решения заданий отправляете на сервер через gitverse.

Можно ли считать функцию, выполняющую некоторые расчёты только в зависимости от значения, вводимого с клавиатуры, недетерминированной?

(пауза)

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

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

Совсем на пальцах: даже когда программа запрашивает с консоли ввод подтверждения yes/no, исход на самом деле имеет три варианта: да, нет или пользователь встаёт и уходит, так и не выбрав вариант, что надолго/навсегда останавливает выполнение.
 
Как об этом всём правильно рассуждать и поступать (5 типов недетерминизма), разбираем с ментатами в СильныхИдеях.

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

.

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

Кто любит играть в машинки, на неделе вышла классная iRacing NASCAR 26, рекомендую. Так-то по сути улучшенный NASCAR 25, но местами очень существенно, и графика, и AI, и физика повыразительнее, и настройки сложности куда гибче, хотя в целом кмк стало меньше симулятора и больше попсы аркады :)

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

null

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

В "Анонимных алкоголиках" говорят: "Полумеры ни к чему вас не привели". Имеется в виду, что невозможно стать трезвенником, если пить, пускай даже по чуть-чуть. Также и в мире ИТ полумеры не приводят вообще ни к чему с точки зрения результатов. Они лишь утомляют того, кто отдаётся этим полумерам.
Вы можете вложить 50%, 80%, 98% усилий, а получите в итоге лишь разочарование. Два типа ошибок...

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

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

Хорошая работа *не* конвертируется в деньги.
98% программистов придерживаются примитивной (и проигрышный по определению) стратегии "просто стараться а не вести переговоры".
Я буду стараться изо всех сил, и когда-нибудь они заметят и сами мне предложат шикарное повышение.
Ага, ну может быть в школе так и работало :) Но на безжалостном рынке труда это не работает вообще...

Продолжаю набор на занятия для неначинающих (миддлы сеньоры), 2 места закончились за 29 минут...

Продолжаю выкладывать для донов материалы СильныхИдей — доступны моим курсантам, но тут расширенные и дополненные версии.
106. Модули важнее всего
Самое мощное объяснение ключевой важности интерфейса -- это пожалуй книга Роберта Харпера (один из святых computer science, формализовавший языки ML и подготовивший кучу курсов для CMU) "Модули важнее всего"...

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

=

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

В "Бесстрашные переговоры о зарплате" добавлен материал
"58) Хорошая работа НЕ конвертируется в деньги"

В трек по функциональному программированию добавлен Last Principles Framework (теория категорий для программистов). На самом деле, тут правильнее сказать, не теоркат изучаем, а встраиваем формальную думательную машинку как рассуждать и об system design, и об software design, ибо тут имеется ровно один математический способ делать это верно. Вы же понимаете например, что ваши fold/reduce в коде никакая не функциональщина а карго-культ, если вы не гарантируете моноидально корректность этой свёртки. Ну или можете продолжать "покрывать код тестами", прости господи, т.к. это очевидное следствие того, что ты просто не понимаешь, как работает твой код, и никаким формализмом его корректность не гарантирована даже на 2%.

В СильныеИдеи добавлен материал "158) System Design за 7 шагов".
Большой гайд про порядок, который на самом деле формирует инженерную интуицию в теме System Design...

=

"Функциональные архитектуры" 174(+3) топиков.
Продолжаем фишки ФМ/ФП/ФА на быстрое внедрение и "продажу" менеджерам.

LPF закончен, думаю, куда и как дальше :)

=

"ЛаМПовое":

Матан или дамское общество, узкое место в AI-пайпе это ты :)

=

it's a privilege to do things that are hard. 💪🏻

=

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

"Песчаные черви Дюны"

Продолжаю работу с ментатами 🤓

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

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

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

Проверка типа всё же выразительнее сравнения по указателю, и в Go её можно получить через интерфейс, раз наследования нет...

Очень понравилось задание. В своей профессиональной деятельности я сталкивался с курсорами (в АТД), но раньше не осознавал, как самому его можно применить на практике, а здесь в этом плане очень хороший пример...

Корректность работы с массивом значений не проверяется.
Подобное недостаточное тестирование ранее уже приводило меня к отправке некорректного решения (задание 6 - задача 7.4.*). На этот раз тупо повезло -- ошибки в алгоритме не было...

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

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

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

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

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

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

Прекрасное: Metalama is an open-source patterns & architecture toolkit for C#.
C# has no pattern keyword. Metalama fixes that.

Define your team's patterns once: the compiler writes the repetitive parts at build time and enforces your rules as you type.

Write the pattern once, apply it everywhere. Aspects generate logging, caching, INotifyPropertyChanged, or your own patterns at compile time. The boilerplate never lands in your repo, so it never needs review or maintenance.

Enforce architecture as you type. Express dependency rules, naming conventions, and pattern guidelines in plain C# and get real-time feedback in the IDE, long before the pull request.

Your rules, enforced by the compiler. No agent, no human, no merge gets past them. Hand-written or AI-generated, every line is checked deterministically. When a pattern changes, you edit one file and the whole codebase follows at the next build.

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

В России тех, кто применяет продвинутые практики computer science (например ФП), оптимистично, наверное сотни (в Европе и США на порядки больше, там целые институты этим занимаются), и таковых всё меньше. Всё, что они делают, это существенно улучшают программные системы на фоне всех остальных. Можно без них обойтись? Безусловно.

Может ли здесь теоретически возникнуть некая критическая масса, которая окажет качественное влияние на всё ИТ? Вряд ли, потому что если не возникла на Западе ранее, то теперь уже тем более. Но зато, теперь 10% "лучших" разработчиков (оценка Jellyfish) потребляют примерно 380 млн токенов в месяц. Теперь это новая айтишная илита :)

И тем не менее, я продолжаю тратить много времени на размышления о формальных методах (потому что именно они источник почти всего моего дохода:). Но при этом я не делюсь большинством деталей, потому что 98% ребят, изучающих эти темы, не используют ФМ активно и напрямую, да и никогда не будут использовать. Поэтому я стараюсь упаковывать эти темы в формате СильныхИдей, ФункциональныхАрхитектур, треке HoTT и LPF (по возможности в формате ELI5 / explain like I'm 5 years old), дабы не терялась связь с повседневной практикой.

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

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

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

Или почему программисты практически никогда не рассуждают о коде с т.зр. минимального доказательства его корректности, что избавило бы от 98% логических багов.

И т.д.

Наш учебный сервер ru лежит по таймауту, техподдержка молчит.
А через впн работает, это как?
Впрочем, совершенно не удивлён, и дальше (особенно начиная с этой недели) будет только хуже.

upd. Когда твой сервис совсем крохотный, приходится часто вот так страдать, т.к. он постоянно оказывается на одной виртуалке с кем-то серьёзным :)

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

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

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

А компании будут создавать всё больше собственных инструментов и систем по мере того, как это будет становиться всё более целесообразным, и покупка/слияние компаний и всякие инвест-фонды быстро прекратятся.

Для инди-хакерства это хорошо очень многим: чем больше компаний делают внутренние системы [на коленке], тем больше им нужны будут сторонние интеграции, API, автоматизация, безопасность, аналитика, плагины, миграции, и куча другой поддержки для своего Big Ball of Mud powered by AI. Крупным вендорам этим заниматься всегда было невыгодно, а соло-разработчикам самое оно.

(продолжение следует)