nozd up

4 дня работаешь на нормальной работе, 1 день преподаёшь.
Преподавание - это 90% педагогики и 10% собственно программирования.
Прогрессировать, очевидно, будешь только в умении доносить какие-то знания до людей сильно глупее тебя (ну или хотябы в умении не сходить с ума от того что на паре студенты ничего не делают)

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

Хочется ответить цитатой:

Нужно бежать со всех ног, чтобы только оставаться на месте, а чтобы куда-то попасть, надо бежать как минимум вдвое быстрее!

Учитывая текущий тенденции курсов и их репутацию, наличие ВО думаю дает преимущество перед теми, кто окончил курсы (Для первый работы)

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

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

Значит канбан напрашивается.

У нас в команде из 16 человек сейчас около 12-15 активных проектов и каждый член команды нагружен иногда сразу несколькими проектами (Понятно что это суть галеры, но как улучшить этот опыт?)

Под галерой обычно понимают аутсорс, а не потогонку)

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

Но ведь при классической многопоточности никакой поток так же не блокируется

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

Тем более при асинхронности практически всегда подразумевается многопоточность

С чего бы? Асинхронный код полезен при большом количестве операций ввода-вывода - диск, сеть и т.д. Не обязательно это должно быть что-то, вычисляющееся в отдельном потоке. Вот, почитайте хорошую статью: There is no thread.

Вам будет полезно ознакомиться с асинхронностью в какой-нибудь изначально однопоточной среде, например JS в браузере не считая вебворкеров. Тогда вы поймёте разницу.

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

1. Просто при найме на работу не болтай о своих диагнозах - это создаст лишнее предвзятое отношение, которое тебе точно не нужно.
Благо при найме на работу справку от врача предъявлять не нужно ;)

"ПРЛ" и "ОКР" для не-психиатра - это непонятные слова и это ожидаемо, что люди тут ориентируются на стереотипы.

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

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

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

вообще не понятно причем тут ревью, фиксированный оклад и микроменеджмент

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

Надеюсь никогда не попаду в компанию, где вы являетесь ПМом :) Без обид, ничего личного, но даже возникновение мысли об этом поспорить уже абсурд. Сначала заказчик/начальник хочет чтобы функционал был сделан еще вчера, а на архитектуру, практики кодирования мы положим ботл, а потом у них возникают вопросы откуда баги. Ну вот оттуда и баги. Производство ПО это такое же производство как и любое другое производство. Если бы мы говорили про автомобильную индустрию, то на сколько бы вам хотелось ездить на машине которую сделали за вечер потому что сроки горят, конкуренты нас обходят? Мне вот тоже не хотелось бы. По этому в любом другом производстве уже давно выстроены процессы, есть отделы тестирования качества и прочие вещи, которые позволяют уменьшить/исключить брак. И только в ИТ почему то до сих пор является нормальным забить болт на все практики производства и потом спрашивать за баги с разработчика. Когда у вас появится формальное описание ТЗ (именно формальное, т.е. формализованное) в котором просто не может иносказаний одного и того же пункта, когда у вас появится опытный архитектор который будет довольно долго планировать архитектуру проекта, когда у вас появится нормальная процедура тестирования специально обучеными людьми и у вас все равно будут баги, тогда можно и задуматься, а стоит ли платить разработчику за баги, ведь теперь у меня есть все условия для того, чтобы багов не было. А до тех пор советую на эту кривую дорожку не вставать. Вот простой пример, рассудите сами:
Есть некоторый код который использует некоторую библиотеку. В библиотеке есть баг который всплыл у вас на проде. Разработчик в этом виноват? Может он виноват в том, что выбрал не качественную библиотеку? А у вас выстроен формальный процесс верификации запчастей из который состоит ваш проект? А у разработчиков библиотеки хорошие процессы разработки были? Это ведь тоже программный код который так же кто-то разрабатывал.

У меня примерно так:
1. Если задание выполнено строго по ТЗ и принято - любой вновь найденый баг - это уже новая работа которая должна быть оплачена.
2. Если задание не выполнено по ТЗ и баги при приемке не принимать - то это ошибка разработчика, пусть исправит.
---
3. ТЗ должно быть составлено так чтобы не могло быть двойного трактования - если ТЗ позволяет трактовать задачу размыто и компания может предполагать одно, а исполнитель другое - ошибка того кто дал это задание разработчику - соответственно это не проблема разработчика, он не знает что у вас в голове и работа по переделке будет оплачена.
---

А вообще никаких общих правил не существует - как договоритесь так и будет.