⚡ Kotobotov ⚡

1. Да
2. Да
и все остальное да
нет никакого или или, все нужно делать

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

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

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

хехехе, рано тебе на фриланс)

чувак очнись, ты на улицу выйди, какая еще робототехника как профессия?
пока человеческий труд можно за 300 долларов купить (в регионе), никому нахрен не надо будет с роботами заморачиваться.
дай бог через 100 лет для этого хотя бы рынок появится.

просохнет, пройдет

Scala -> для питониста будет много общего. Плюс типы выводятся из операций, не нужно будет постоянно их описывать, как в джаве.

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

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

домен здесь означает предметную область знаний, эти знания (понимание процессов), являются основными при разработке.
Тоесть никаких придуманных разработчиком абстракций, всяких там абстрактных модулей, факториКонструкторМенеджеров и тд, все максимально предметно и максимально приближенно к тому как реально процессы в компании работают.
Если например разрабатывать систему учета в ресторане по ДДД, то в ней будет полностью скопированна структура самого ресторана, с названиями должностей, позиций, и процессов, без всяких там абстратных слоев и "удобных" нововведений. В итоге продукт получается сразу же понятный и привычный пользователям.

ранер занят на другой джобе (там должно быть подписано)

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

обычно используют облачную БД + виртуальные машины в разных регионах, ну и балансировщик запросов для сервиса.

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

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

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