Crash

В силу некоторых обстоятельств не могу идти работать full-time

Тогда никак. Серьëзная разработка = командная разработка. Да и рост без команды очень медленный и ограниченный.

Нет, не возможно по большому счёту.

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

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

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

В работе программиста нет чётких алгоритмов достижения поставленной цели. Всё надо изобретать на ходу, экспериментировать, импровизировать. Это в корне её отличает от всех остальных. Тот же повар например конечно тоже может позволить себе эксперименты, но типичная его работа состоит из чётко заданного и отлаженного алгоритма. В этом беда мнотысячной армии вкатывальщиков. Они думаю что достаточно освоить курсы «кройки и шитья» и всё, потом лопать себе от забора до обеда.

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

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

Откуда миф о нехватке кадров?

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

Начнём с последних - реклама курсов. Создаются курсы по IT с целью заработать деньги, а их реклама говорит, что ну НЕ ХВАТАЕТ айтишников, ну нет и всё! А зарплаты - сотка с порога.
Хотя почему их не хватает, кто это сказал, где статистика, графики, отчёты? Этих отчетов НИКТО и НИКОГДА не видел.
Касательно упомянутого автором веба: я начинал свой карьерный путь в начала 2003 года. Тогда уже были форумы по программированию, люди обсуждали, как заставить javascript работать в IE и NetscapeNavigator. Это было 20 лет назад почти. Как думаешь, за 20 лет сколько людей вкатилось в сферу программирования? Десятки тысяч стали полноценными специалистами.

Теперь относительно работодателей. У айтишников с незапамятных времен был такой фетиш - "да ты не знаешь бибилотеку Н? - Ну ты и лох" - образно говоря. Чем больше знал айтишник - тем он был круче, чем другие. Это был своего рода выпендрёж одних айтишников перед другими.
Но это было давно, опять же, лет 20 назад. За последние 20 лет индустрия рванула вперед настолько, что каждая технология, каждый ЯП оброс массой технологий-сателлитов. Для работы фронта нужно знание JS и каких-то там библиотек. Для работы с PHP требуют в вакансиях знания как минимум ТРЁХ фреймворков, не говоря о сопутствующих библиотеках, знания ОС unix/linux, DevOps, СУБД/высокие нагрузки, кэши-редисы, умение это все грамотно применять и т.д. Работодатели видят, что айтишник - это такой весьма покладистый тип личности, которого хлебом не корми, а дай что-нибудь поучить в свободное от работы время (ну а зачем зашуганному ботанику свободное время, пусть сидит дома фреймворки изучает). Вот работодатели и начали задирать планку и жаловаться, что "специалистов не хватает".
Да, сумасшедших гениев, кто знает целые вереницы технологий, намного меньше, чем обычных ребят, которые исполняют свою зону ответственности. А поскольку работодатели хотят сэкономить, то ищут этого фантомного чудо-программиста, который должен, по их мнению, работать за три отдела. Не находят и жалуются, что "специалистов не хватает".

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

Вклад в этот миф о нехватке спецов вносят сами разработчики. Сидел такой Петя, кодил 5 лет уткнувшись в монитор, потом его руководитель увольняется и, о чудо, Петя становится НАЧАЛЬНИКОМ отдела аж из пяти программистов. И вместо того, что бы делать свою работу хорошо, у Пети формируется синдром вахтера и Петя начинает задавать весьма заковыристые задачки на собеседовании, заставлять кандидата писать в режиме реального времени код, дает ему тестовое задание на 2 недели. А когда кандидаты сливаются, начальник-Петя, решает, он самый умный, а "спецов не хватает". Хотя проблема не в спецах, а в идиоте-Пете, который самоутверждается через свою должность главного формошлепа.

И что самое главное. Кому в РФ нужны айтишники? Бизнесу. В первую очередь.
Бизнесы развиваются в ногу со временем.
Взять в пример бизнесы 2010 года - что они делали? Свои веб-сайты, пилили какие-то свои наколенчатые решения.
Что делают бизнесы 2022 года? Идут на ВБ и Авито, покупают готовые продукты.
Время расставляет всё по местам, происходит оптимизация.
Что бы твою продукцию покупали больше не надо держать ИТ-штат для поддержки сайта, для этого есть ВБ.
А с учетом последних событий бизнесы будут неминуемо сокращать расходы.

Айтишники были в последние годы слишком дорогим удовольствием для бизнесов, айтишные аппетиты реально стали чем-то запредельно наглым, когда видишь, что Маша 25 лет с 2 годами опыта хочет 250 000 рублей.
Бизнесы в нынешних условиях неминуемо будут сокращать траты и условные Маши, которые вчера хотели 250 000 за JavaScript скоро будут работать за 50, тк таких Машек с каждым годом всё больше и больше.

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

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

Исходя из личного опыта могу заявить, что нет.

Если хочешь как справочник то бери, но как источник знаний не бери.
HTML / CSS Достаточно простой язык ( в сравнении с C++, PHP, Java) и по нему куча образовательных видосов на UT и много статей в инете. Так же достаточное кол-во сайтов которые нацелены упростить верстку.

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

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

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

Хорошие программисты стоят больших денег, которые они хотят с гарантией получать. То есть для РФ сейчас это оклад 200+т.р. в месяц на руки. Скорее причем 300 т.р. Вы предлагаете такие деньги? Можете обеспечить человека с такой зарплатой работой? Место поиска - headhunter.

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

Очевидно, что проблема в том единственном твоём любимом программисте. Наверное, он не терпит конкуренции более сильных разработчиков и тогда надо гнать его в шею.
Варианта два: уволить его, либо воспользоваться услугами профессиональных нанимателей, HR

нанимайте просто по одному

Продай мне вот эту ручку!

Это ненормально, но так бывает. Я бы не стал увольняться и переходить к ним.

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

Нормальные компании не только не просят увольняться, но и, сделав официальный оффер (то есть пообещав заключить договор, а иногда даже уже заключив договор) согласны ждать 2 недели (а иногда и больше) пока сотрудник завершит дела на текущем месте работы и выйдет к ним. А не так: "вы увольняйтесь, а мы вас собеседуем. Может быть возьмем, может быть не возьмем, ничего не обещаем".

Да, это давно всем известный развод лохов (лично я знаю про него уже лет 20).
Вас таких жертв называют "дрОпами" в этой схеме.
Ты даёшь в пользование свой комп и с него совершаются преступные действия.
За которые будешь нести ответственность лично ты.
Там возможно всё - наёмничество, детское порно, продажа наркотиков, заказные убийства, торговля девушками, детскими внутренними органами и прочее.
Первое, что ты должен сделать - не спускать всё на тормозах, а написать заявление в полицию об этом

Ответ тут

1. Хорошо помогает начать изучение с простых паттернов проектирования. Прежде всего это простые и понятные паттерны типа "стратегия", "команда", "итератор", "шаблонный метод", "посредник", "цепочка обязанностей". Изучив и поняв эти паттерны вы посмотрите на ООП по новому: не как просто структурированный код плюс данные в одном объекте, а именно как задумывалось его создателем - объект самостоятельная единица взаимодействующая с другими такими же посредством сообщений. Причём она является first class также как в функциональном программировании функция. К тому же на указанных паттернах строятся и остальные. Например, фабричный метод - это частный случай шаблонного метода. Так постепенно придет понимание куда и зачем применять различные паттерны.
2. Когда решаете какую-либо задачу, думайте о нескольких вариантах архитектуры для её решения. Далее старайтесь выбирать
вариант не на основе личных предпочтений или предыдущего опыта (не важно, положительного или отрицательного), а на основе анализа, какой из вариантов здесь реально потребуется с точки зрения дальнейшего развития проекта. Предыдущий опыт также надо учитывать, но все проекты разные, требования разные, и каждая ситуация может отличаться. Надо смотреть как могут изменяться или расшириться системные и функциональные требования (разумеется, для этого надо быть в контексте этих требований - т е знать их самих, манеру работы с проектом заказчика и т д) Во многих случаях, когда вы не сможете выбрать из-за недостатка информации, это логически подведёт вас задавать заказчику дополнительные вопросы. И через этот итеративный процесс приходит понимание, где и как применять паттерны.
3. Обратите внимание на паттерны ERP систем (для примера книга "Шаблоны корпоративных приложений" Мартин Фаулер) Особенное внимание надо уделить такому шаблону как инверсия зависимостей. Данный шаблон лично мне помог совершенно по другому взглянуть на ООП (во второй раз, уже после того как я стал применять другие паттерны ООП) Вот здесь https://blog.byndyu.ru/2009/12/blog-post.html очень понятно на мой взгляд описано (язык C# но всё тоже самое будет для любого ОО языка) Кроме того в этом блоге много всего по проектированию и рефакторингу.
4. Обратите внимание на книгу "Growing Object-Oriented Software, Guided by Tests" Стив Фриман Перевод на русский не гуглится, возможно его и нету. Но книга полезна тем, что в отличие от многих других книг по TDD в ней разбирается не только методика тестирования и написания тестов, но и принцип тест -> код -> рефакторинг. И разбирается на достаточно длинном примере. Из неё вы можете подчерпнуть привычку рефакторить, а не переписывать заново. Причём даже если у вас на проекте цикл другой - например тесты пишутся после функционала, всё равно образ мысли изменится и масштабный рефакторинг не будет вызывать непреодолимого желания выбросить и переписать с нуля.
5. По рефакторингу могу порекомендовать книгу "Работа с унаследованным кодом" Майкл Физерс. Кроме того об этом много статей в уже упомянутом блоге Александра Бындю. Грубо говоря я бы назвал ту подборку статей "как не переписывать и начать жить"
6. Ещё один блог где собрано большое количество полезных материалов по ООП, рефакторингу, проектированию, это блог Сергея Теплякова Вот ссылка на его подборку книг по теме: sergeyteplyakov.blogspot.com/2013/08/blog-post.html
7. Изучайте материалы постепенно. Не стоит сразу пытаться воткнуть только что полученные знания в первый попавшийся проект. Обсуждайте возможные решения с коллегами. Со временем они также станут поддерживать эту практику. Если есть возможность, попрактикуйте парное программирование. Причём не обязательно с более опытным коллегой. Иногда вопросы задаваемые наивным человеком заставляют задуматься гораздо крепче, чем ответы получаемые от мудрецов.