Saboteur

Открой вакансии, посмотри сколько зарабатывают джуны на Андроиде.

Неужели за 18 лет активной ИТ деятельности не наработались навыки гугления дорожных карт? Или есть мысли что на тостере составят индивидуальный гороскоп с учетом личных привязанностей? 40 лет, а вопросы как у 15-летнего.

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

На 40летних смотрят нормально. И вообще эта тенденция о малолетних сеньорах существует только в СНГ, где коммерческая разработка более-менее началась после 2000-2005, а не в 1980-м и раньше, как зарубежом.
Поэтому разработчиков, которые до этого момента что-то активно разрабатывали за деньги очень немного, еще и большинство из них уехало. Вот и выходит что, скажем, 50-летних разработчиков, которые сразу начали именно как разработчики и уже 30 лет как разрабатывают - в xUSSR ну может пару тысяч. Но это потихоньку меняется - подрастают люди, стареют.

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

sed -i -r 's/^CONFIG="(.*) OUTPUT"/CONFIG="\1 OUTPUT CONSOLE"/g' file.txt

Пример:

$ echo 'CONFIG="USER OUTPUT"'|sed -r 's/^CONFIG="(.*) OUTPUT"/CONFIG="\1 OUTPUT CONSOLE"/g'
CONFIG="USER OUTPUT CONSOLE"

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

"как научиться проектировать ПО"

Смотреть на архитектуру разных программ и разных проектов, это приходит с опытом. Видеть как налаживаются процессы. Невозможно научиться проектировать ПО, учавствуя в одном маленьком проекте.

стать профессиональным программистом, а не зависеть от опыта, который получил на курсах/ВУЗе/Книгах.

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

Как именно думать как программист? Я говорю не об алгоритмах и структурах данных, а о том как проектировать ПО. Независимо от знаний архитектурных паттернов, которые изучил, а научиться создавать свои Архитектурные решения.

Было бы неплохо сперва узнать что такое паттерны - то есть годами выстраданные решения, полученные на чужом опыте. А то потратишь десяток-другой лет на изобретение велосипеда, а потом оказывается это уже изобретено, а у тебя пенсия через 5 лет и ты все еще просто делаешь базовые вещи.
Помогут ли тут такие книги, как "Проектирование ИС"?

command line interface уже давно выработал очень простой стандарт.

Есть команда (внутренняя команда оболочки или внешняя утилита, вроде nodejs)
Есть аргументы к команде
Аргументы логически делятся на опции и параметры.

Опции обычно начинаются с дефиса или двух (в POSIX стандарте один дефис для коротких опций, вроде -h, -e, два дефиса для длинных опций, вроде --help, --environment)
Некоторые опции могут требовать параметр (--environment prod), некоторые нет.

Параметры - это сами данные - названия файлов, устройств, другие данные в виде текста

По стандарту POSIX короткие опции, которые не требуют дополнительного параметра, могут объединяться под одним дефисом ( пример: rm -rf )

Список конкретных опций и параметров у каждой утилиты свой. Не все утилиты строго следуют POSIX, поэтому могут быть варианты. Для этого читай документацию конкретной утилиты.
Таким образом твой вопрос относится не к nodejs, а к общим стандартам работы в командной строке.

Ну и еще в CLI есть перенаправления, это отдельная лекция.

И второй попутный вопрос: правильно ли что dev и prod работают на одном и том же контейнере?

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

А так - если вас решение устраивает, если вам оно понятно и в случае чего вы его можете легко модифицировать как вам нужно - да, вполне нормально.