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

Знать реализованную систему конечно будет лучше тот, кто её создавал. А при плохом внутреннем качестве системы он станет еще и незаменимым. На эту тему была занимательная статья, перевод:
https://ain.ua/2017/10/17/we-fired-our-rick
Но знать систему - это немного не то, чтобы знать решение. Бывает такое, когда разработчик знает реализованную систему, но не знает решения, которое нужно реализовать. А именно это зачастую важнее.

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

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

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

Это зависит от того, в каком месте кривой стоимости изменения кода находится проект, и какой у неё характер. В РФ я встречал достаточно неплохие проекты, но нераскрытый резерв по стоимости изменения кода у них все равно присутствовал. Не настолько большой, как в большинстве legacy проектов зарубежья, с которыми приходилось иметь дело, но все-равно был.

нежное общество не выдержало токсичного чела?) даже не открывал статью, но вот чувствую именно так и было

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

Тут ключевое слово похожих. Их все делают по проторенной дорожке. Интерес возникает, когда что-то новое приходит.

А как оценить трудоемкость новых фич? Они же новые, их сложность не с чем сравнить.

Придумывается решение, раскладывается на задачи и дается оценка.

Не вижу проблемы дать оценку. Оценка может непорадовать заказчика - но это другой разговор

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

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

В смысле я с вами согласен.

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

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

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

Условно, у хороших разработчиков в Ярославле есть возможность работать за почти Московскую зп. И при этом, в сухом остатке, с учётом стоимости жизни, доход в пересчёте на евро получается не меньше, чем в Мюнхене или Гамбурге, например. То есть, люди могут позволить себе не только хорошее жильё, дачи и прочие привычные вещи, но и путешествовать, и инвестировать.

При этом, в отличие от штатов, есть отпуска. Так что не всё однозначно.

Формулировка московская зп смущает. Европейская может? Зачем им на москву работать?)