Я обращал внимание на то, что каждая задача в скорости своего решения натыкается на боттлнек:

• Невозможно понять, что нужно, из описания задачи. Начинается долгий интерактивный процесс выяснения о чём речь. Бывает, что задача содержит в себе описание решения, которое не работает и нужно отдельно доказывать, что надо делать "не так". Это communication bottleneck.

• Задача реализуется в продукте с большим неудобным feedback loop'ом (у этого может быть миллион уважительных причин, речь не про это). В этой ситуации задача с одной стороны env bottleneck, с другой стороны всё равно занимает мозг, потому что нельзя выкинуть контекст из головы. Даже если затык не на CI, а на компиляции в 20 минут, это всё равно та же проблема "компилируется". Сюда же включаются все внешние сущности, которых нужно "ждать" (пока выкачается, пока загрузится, пока запустится, пока whatever).

• Задача требует объективно большого числа нажатий кнопок. Например, перевести все workflow на новую технологию. 400 файлов по 20 строк в каждом, не поддающиеся механическому изменению (требующие чуть-чуть внимания и локальных адаптаций). Это typing bottleneck. Это же относится к задачам уровня CRUD и большого числа boilerplate. Надо печатать. Но думать. Но печатать.

• Задача алгоритмически сложная. Не обязательно это 'state of art'. Может быть, это что-то уровня "как мы обеспечим инвариант этой функции". Над такой задачей надо думать, и она чаще всего приводит к самому сложному и плотному коду, иногда к 3-10 строкам, выражающим решение задачи. Это local hard-thinking bottleneck.

• Задача не решаемая в существующем коде и нужно сделать тонкий сложный рефакторинг в множестве мест для того, чтобы решение оказалось консистентным с остальным кодом. Сам новый код может быть тривиальным, но его последствия распространяются на множество малосвязных сущностей и из-за этого изменения затрагивают несчётное (не удерживаемое в голове) количество "мест" (компонент и т.д.). Это global hard-thinking bottleneck.

• И есть задачи, решения которых не существует в настоящий момент, потому что не понятно что делать, как делать, делать ли, или изменять условия задачи. Часто это связано с новыми технологиями, новыми обстоятельствами или передумыванием подхода на уровне архитектуры. Это research bottleneck.

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

env bottleneck зависит только от часов на стене. Можно три дня по 8 часов отлаживать ci, который падает "в самом конце" в рамках одной задачи. Нагрузка на мозг есть, но она напоминает нагрузку на водителя на трассе. Смотришь, смотришь, иногда чуть-чуть делаешь, дальше смотришь.

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

Оставшиеся три - это чистый стресс на мозг, причём каждый имеет свой профиль по нагрузке. Именно для этих трёх типов человек продолжает работать даже когда не печатает (более того, самая важная работа происходит в перерывах между нажатиями кнопок, потому что сами кнопки - это typing bottleneck, а реальные решения происходят в голове между сеансами typing).

Это моё имхо. Почти пост?

Кроме side effects есть ещё и side causes, и я даже не знаю, что сложнее для управления.

Сама модель side effects очень ограничена и не полностью описывает "ожидаемое" от программы.

Вот представьте себе такую программу

fn add_user(email_str: &str) -> User{
  let parsed_email = Email::new(email_str);
  match parsed_email{
    Ok(email) => User::new(email)
    Err(_) => loop{}
  }
}

Что тут написано в сигнатуре. Что функция всегда возвращает User по его email. Что эта функция делает? Строго соответствует своей сигнатуре. Когда она завершается, она возвращает пользователя с валидным email'ом. Что происходит, если email на входе не валидный? Функция ...решает проблему, посредством bottom type.

Что полностью соответствует ожиданиям системы типов, но полностью не соответствует ожиданиям пользователей.

Почему такая наглость прокатывает? Потому что time не является side effect для программы в рамках модели. Почему? Потому что так удобнее считать программы.

А ведь в side effects с бытовой точки зрения входит "сожрать батарейку", "зависнуть" и "начать тупить". А с точки зрения теории - не входит.