Saboteur

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

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

Зазубривать не нужно - работа это не ЕГЕ, никто у вас учебник и гугл отбирать не будет.

Но если вы читаете - вы развиваете навык чтения.
Больше пишите. Чувствовать нужно, что вы знаете как решать проблемы.

github это хостинг, под капотом git и возможно git-bash

Ни то ни другое особо не зависит

Качество кода зависит от исходников, а не от компилятора, а стандарт больше о том, что можно использовать в исходниках.

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

То есть, зная пароль, но лишившись номера телефона, должно быть можно восстановить номер. А имея номер телефона, должно быть можно восстановить пароль.

Но в чем тогда выгода?

В том, что вы привели пример НЕПРАВИЛЬНОЙ настройки двухфакторной авторизации.
Восстановление доступа должно идти через службу безопасности, возможно даже с личным присутствием.
А то, как двухфакторная авторизация сделана в общих мобильных сервисах - это так, для галочки и небольшого усложнения.

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

То, что вы пытаетесь исправить - это баги интеграционного тестирования. Оно исправляется банально тем, что тот кто свой мерж реквест отправил вторым и словил багу - будет разбираться.
Просто на практике, такая ситуация встречается крайне редко при нормальной архитектуре приложения, а поэтому менять весь CI процесс в угоду именно этой фичи и вопреки нормальному git-flow по фичам - это неправильно.

Как было у вас? Сколько потребовалось времени, чтобы делать все интуитивно, как с таблицей умножения?

А сколько у тебя ушло на таблицу умножения?

А вообще просто практика. Привыкаешь. Легче не становится, просто становится возможным.

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

зачем?
базовые команды - это ВЕСЬ функционал линукс.
задачи на grep - это задачи не на grep, а в основном задачи на регулярки, которые не только в grep
В общем нет смысла делать подобное, ибо базовые вещи учатся за пару вечеров, а сложные - тутор писать годами надо.

Изучаешь функции по работе со строками - www.cplusplus.com/reference/string/string
и преобразовываешь

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

Ну то есть вариантов полно, надо смотреть по общему SDLC

Если есть опыт работы, и к нему курсы - ну может быть микроплюс за попытку повысить квалификацию и теорию.
Если только курсы - то вообще никак.

Но на уровне мида, подобные курсы уже не нужны.

Так все кряки в личных целях и используются, в основном.
Естественно нет.