Max Payne

если формат строго определён, имхо проще разобрать регуляркой лот №(\d+).*дубина магических канделябров.*- (\d+)

import string

punctuation_map = {ord(char): None for char in string.punctuation}
i = input("You: ").lower().strip().translate(punctuation_map)

тут всем решения раздают в карму, вот и я впрягусь за тебя. Часто боюсь откликаться на вакансии, да у меня уже фобия выработалась.
Имел моменты с трудустройством в говноконторы где приходилось делать из говна конфетку с говном, при этом советуя начальству советы не из своей области к которым не прислушивались и оказывались в жопе.
Приходил на собеседования не обсудив зп, а потом там начинали торговаться при том, что изначально предложили ниже низкой: "-мне нужно на 150$ больше[прошла неделя] -мы готовы увеличить предложение на 50$. -Что???"

И финалом тот самый момент, где постучались ко мне с вакансией из 14 требований я проходил только по 8, пояснил им это, но сказали приходи, мы подучим. Собеседование и момент истины, на допросе дрочат мое незнание, говорю что знаю, а что не знаю поясняю как гуглю, мужик хмурясь выдает "пока ты гуглишь компания на тебя тратит деньги", на что я мол, постойте, я же говорил о моем уровне, все скилы в моем резюме(в которое вы и постучались), какие могут быть вопросы, на что получаю ответ "я резюме не читаю". Полтора часа я унижался, а компания платила чукче(не читателю, а писателю) деньги.
Почему он так делал? Заставляла ли его хрюша принимать всех пришедших на похороны? Нашли ли они своего джуна со знаниями сеньёра и амбициями пария? Ответы хранит

Лично моя мысль на сей счет такова, все пытаются сэкономить, хрюши пытаются не натупить(и нещадно тупят), а эти ребята пытаются завалить БОЛЬШООЙ МИЛЛИОННО-МИЛИАРДНО-ТЫСЯЧНЫЙ-МНОГОСЕРВЕРНЫЙ-ТАЙНОЙ ПОКРЫТЫЙ ПРОЕКТ

Самое сложное в 1С программировании - это не язык и платформа, а понимание прикладной области.

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

И так, проблема следующая: я реализовываю некоторый функционал, программы и понимаю что делаю и зачем, как это работает, но у меня абсолютно отсутствуют теоретические знания о том, что я сделал.

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

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

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

На этом у вас должны появиться навыки пояснения того, что вы делаете.

Итак,

какие конкретно стоит почитать

1. Макконнелл, "Совершенный код". Объемная но не особо сложная книжка, можно прочитать не особо то за большее время чем такую-же книжку из художественной лит-ры.
2. Роберт Мартин, Идеальный программист. Есть ещё "Программист прагматик", вроде тоже о чем то подобном. Книжка небольшая, в принципе можно за пару тройку недель прочитать рассуждения Дяди Боба о работе программиста.
3 Роберт Мартин, Чистый Код. Весьма хорошая книжка, очень широко затрагивает тему написания поддерживаемого кода. Важно - особенно в этой книге, но так же и в любой другой - не зацикливайтесь на догмах аля "3 строчки на функцию", не обожествляйте SOLID, а рассматривайте, какие проблемы решают предложенные решения. Советую в каждом случае рассуждать о том, как описываемые вещи влияют на качество кода и архитектуры программы.
4. Роберт Мартин, Чистая Архитектура - относительно новая книжка о том, что всё новое это хорошо забытое старое. Возможно вещи описываются немножко поверхностно, впрочем, углубляться в любом случае нужно самому. Книжка годная, получше объясняет SOLID, затрагивает другие принципы, затрагивает парадигмы, принципы дизайна, архитектуру, объясняет почему то, что многие горе-разработчики нынче зовут ООП им не является. Думаю эту книжку можно даже перенести на первое место.
Дальше уж по ситуации - паттерны GoF, PoEAA, Рефакторинг Фаулера, Кента Бека про тестирование etc.

подсознательно я продолжаю выбирать именно "правильные" подходы,

Боюсь, что вы просто используете те подходы что знаете, а не выбираете исходя из требований и ситуации.
Хотя бы потому что "правильных" подходов не бывает, есть подходящие в данной ситуации, и плохо подходящие, компромиссные и откровенно вредные.

наследование — это реализовывается само собой.

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

Упомяну один момент: статейки в интернете и даже(о боги) на всеми нами любимом хабре или тостере, как и любые другие источники информации, книги и доклады любимых нами авторов представляют исключительно субъективное мнение автора, и лишь его понимание описываемой темы, сформировавшееся в силу, обычно, неизвестных нам обстоятельств. Они могут нести за собой скрытую сложность, абсолютно не подходить в ситуациях отличных от ситуации автора, и никогда не стоит принимать из за единственно-верную истину. Скорее, за пищу для размышлений и альтернативные подходы к какому-либо делу.

Потому что import config - это абсолютный импорт, а нужен относительный from app import config

модуль config в пакете app
import app.config
from app import config

Серьезно, неужели это правда?

Мой любимый пример: я на Ютубе увидел человека, который на полном серьёзе утверждал, что Земля плоская и приводил убедительные аргументы.

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

1. Работа над личным брендом: Высокая репутация в профессиональных сообществах повышает привлекательность для нанимателей.
   
2. Улучшение существующих знаний: Хочешь что-то понять, объясни другому.
   
3. Приобретение новых знаний: Специализация замыкает в узком спектре задач и проблем, а Q&A-сервисы - это источник задач и проблем из самых разных областей и иногда под самыми неожиданными углами.
   
4. Альтруизм: Большинству из нас кто-то помогал в начале пути, пришло время возвращать долг и делать свой скромный вклад в рост кадров.
   

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

Для чего просиживаете на тостере по 5-6 часов в день?

Я в среднем раз в полчаса-час заглядываю. Если находится интересный вопрос, могу потратить на него минут 10. Некоторые на перекуры больше времени тратят.

let users = await vk.api.messages.getConversationMembers({peer_id: context.peerId}); 
let user = users.items.find((item) => item.member_id === context.senderId);
if (user.is_admin) {
  // админ
} else {
  // не админ
}

Что-то типа того

def if_no_data(f):
    async def wrapper(self, *args, **kwargs):
        if self.data:
            return None

        if asyncio.iscoroutinefunction(f):
            return await f(self, *args, **kwargs)
        else:
            return f(self, *args, **kwargs)

    return wrapper

Если status = ok возвращаем один ответ, если status = error возвращаем другой ответ

Это вопрос по JavaScript? Тогда вам подойдёт условный оператор:
if ( ... ) ... else .... ;

P.S. По вашим вопросам складывается ощущение, что вы пилите этот ваш vk.updates.hear, вообще не зная JS. Не проще ли нанять спеца или хотя бы изучить основы?