Артем Воронов

Во-первых, не map, а БД. В момент ввода пользователем города, ходить в БД, по имени города получать код и с ним делать запрос к расписанию. Табличку в БД лучше заполнить заранее нужными кодами, чтобы у свежеустановленного приложения сразу были данные, пусть даже не самые актуальные. Во-вторых, сделать фоновую задачу, которая будет периодически делать запрос к API Яндекса для обновления данных по кодам городов в БД. В-третьих, чтобы не жрать память мобильника, для парсинга 40-метрового файла использовать что-нибудь вроде Jackson Streaming API.

C++ является одним из сложных ЯП... блабла...Я осознаю, что для меня это слишком серьёзное и тяжелое начало

Я разобрался как работает стек и как адресуется память в пятом классе без интернета и практически без документации. Была какая-то книжка по С++, которую просто перечитал раза 3-4, пока не понял смысл.

На протяжении обучения в школе я размышлял о начале изучения языка программирования.

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

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

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

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

А про трудоустройство начинай думать, когда при прочтении описания вакансии ты считаешь, что 50-60% ты знаешь.

Что за каша? Что такого ценного в "других программах" и от чего их надо защищать? Сама программа обычно является обьектом защиты только если это игра - то есть работа программы самой по себе (среди не-игр это редко). Обычно не-игра защищается тогда, когда она производит что-то ценное.

Вопрос - что ценного в ваших программах? Кому они нужны, кто будет их ломать?

Даже на закрытых плеерах с DRM эта защита не спасает. Ничто не помешает переткнуть кабель из монитора в карту видеозахвата. Или тупо поставить перед монитором камеру.

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

DTO объекты часто пересекают границы Языков (Java/JavaScript/GWT) и сетевых протоколов (Rest/Graphql/SOAP/Avro).

И эти объекты могут нести на себе семантику только чистых данных. Вы не сможете через сеть
из Java в C# например передать интерфейс или объект с методами.

И многие фреймворки искусственно ограничивают DTO как раз для того чтобы эти объекты однозначно
декодировались всеми сторонами-участниками протокола взаимодействия. А фреймворки - обычно
предоставляют средства кросс-компилляции этих DTO.

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