Roman

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

Поймите, что, во-первых, программист учится всегда, потому что постоянно что-то меняется в его работе. Во-вторых, он постоянно ищет решения новых проблем самостоятельно, а не применяет решения, которые ему показали во время учёбы. И, в-третьих, программирование на 90% состоит из рутины, которая никак не тянет на развлечение.

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

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

другими словами: нужно и стоит расти не только в глубь, но и в ширь.

В общем случае сортируете, проходите по списку и удаляете рядом стоящие одинаковые элементы.

Но может надо решать проблему более кардинальным образом - вместо list использовать более подходящий контейнер - set? В set элементы уже отсортированы и уникальны.

Нет разницы.
Операторы частный случай функции, только со строго заданными и описанными в стандарте сигнатурами и со специфическим ключевым словом operator. Ну и разница в использовании - вызовы операторов, как правило, компилятор подставляет в код сам, а функции явно вызывает программист. С точки зрения именно перегрузки разницы нет.

UPD: дополнительно смотри комментарий Евгений Шатунов

bool& operator [] (int index) {
    return selfVector[index];
  }

должен стать

std::vector<bool>::reference operator [] (int index) {
    return selfVector[index];
  }

Рекомендую не ходить на курсы. 7-10 дней это мало. Чтобы превратить теоретические знания в практические, лучше самостоятельно разработать какой-нибудь проект.
Лучше это время отходите, сходите в какие-нибудь места, посмотрите город.

Писать что знаете
Ничего не писать
На любые вакансии откликаться

Практиковаться, читать умные книжки по алгоритмам и структурам данных. Вот берите например https://leetcode.com/ отсортируйте по сложности (с самых легких), и делайте-делайте. Но без теории алгоритмов будут костыли, поэтому лучше почитать что-то.

Выход за границу массива тут:

for(int i=0;i<s->m;i++){
...
   s->secondSortedArray[i]=num;
}

У вас количество элементов в обоих массивах 4, а m вы инициализируете 5. При последнем присваивании secondSortedArray происходит выход за границу массива, а т.к. после secondSortedArray в структуре идет m, то m у вас заменяется последним рандомным значением.
В firstSortedArray то же есть выход за границу массива, но это не носит деструктивных последствий.
Подобные вещи часто приводят к краху программы. Вы могли бы это отловить в отладчике. Пользуйтесь им. Отладчик - друг программиста! :-)

Потому, что
1. нет контроля типов
2. нет ограничения по области видимости, типа неймспейсов.
3. макрос разворачивается подстановкой в месте использования, т.е. там будет вставлен код
((a) > (b) ? (a) : (b)) который превратится в ((++a) > (b+10) ? (++a) : (b+10))
4. макросы сложно отлаживать
5. неправильно написанный макрос будет компилироваться в непонятно что. Например если убрать те же скобки

как без них раскроется выражение x = max(a, b) + 10; ?
x = a > b ? a : b+10;

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

#include <iostream>

#define mymax(a,b) a>b?a:b
#define mul(a,b) a*b

int main() 
{

	std::cout << mymax(5, 10) << std::endl; // Ошибка компиляции
	std::cout << mul(5+5, 10) << std::endl; // Неожиданно на выходе 55, а не 100

	return 0;
}

robotjs

const robot = require('robotjs');
robot.keyTap('enter');

Задача о кратчайшем пути