Не знаю, я таких не набираю )

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

а мидлов?

Ну вообще-то совсем нет. Код может быть очень огромным или иметь те или иные неочевидные хаки по разным причинам, например борьба за производительность. Коменты ускоряют навигацию по коду и его понимание, на крупном проекте придётся слишком много прочитать и деражать в голове, чтобы понять, что же тут происходит в итоге.
Скорее наоборот - код без комментариев обычно плох и куда хуже кода у которого они есть.
Например
https://github.com/Kotlin/kotlinx.coroutines/blob/master/kotlinx-coroutines-core/jvm/src/Dispatchers.kt

Ну красота же, а теперь представь без этих коментов

Ну, предположим, мы зафиксируем «знание» в документе на 500 страниц. Чем оно будет отличаться от ТЗ на 500 страниц на входе, которое не читают?

Нужны документы с логическое схемой для «введения», со всеми связями. Нужны описания моделей данных, нужны описания спецификаций API и процессов. Последние три группы должны либо быть кодом, либо из него генерироваться, чтобы не дублировать источники знаний.

Через год-два-три, у меня будет возмодность этот документ найти, найти в нем объяснение почему приняты такие-то решения.

Через 2 года это уже не нужно, если мы активно развиваемся

боевой опыт говорит что нет: регулярно ищем концы в водах трех-пяти летней давности

А все «почему» они не в документации обычно, и не в спеках, а в презентациях-сравнениях решений. Иногда — в meeting notes встреч.

Моя коллега по ремеслу с 15 годами в разработке ещё 3 года говорила следующее: "Сейчас рынок разработчиков делится на два категории: на тех, кто будет говорить как (инженеров) и тех, кто будет делать (кодеры)".

Именно по-этому она работала в СА, а не в разработке, а сейчас стремится к Solution Architect

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

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

Кодеры - естественная часть всей кучки программистов. Они были, есть и будут. Нельзя всем конторам брать только "сливки". Даже если рынок будет наводнен хорошими прогерами - поменяются критерии качества и из них тоже выделятся слабые. И появятся более сильные СА/Солюшены/проч которые будут говорить им, что деллать

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

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

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

Рабочего варианта на 100+ пока не видел, к сожалению.

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

а зачем синхронизировать команды на разных продуктах?

Мы сейчас пробуем предварителюную фазу up-front design (кусочек ватерфолла), а затем реализацию по agile с возможностью обратной связи и корректировки up-front design. Как-то так.

А синхронизация между командами как?