При повторной потере мотивации алгоритм следующий:
1) Идем высыпаемся. По-нормальному так, без будильников. Чтоб глаза вообще больше не закрывались.
2) Если мотивация не вернулась (возвращается в 70% случаев) - берем велик (хотя можно и пешком) - и на улицу. Если есть приличный парк в городе - находим пару нестандартных физ. упражнений (можно боевых), пытаемся выполнить. Работа с телом и физические нагрузки - это совершенно другая часть вашего сознания, про нее нужно не забывать.
3) Если мотивация не вернулась (уже где-то 85% случаев) - берем случайную книгу (не техническую), в идеале - из жанра который вам нравится. Читаем. Спокойно, страницы не считаем.
4) Если не вернулась, повторить с п. 1 до пяти раз, не думая о времени и выполняя только самые важные дела (срочные задачи по учебе, работа, если есть), можно даже попросить родных/знакомых помочь по дому и бытовым делам, чтобы себя разгрузить.
5) Если не помогло после 5 раз, задаем новый вопрос на тостере, подробно описываем что делали).

Хотя бы один из п. 1-3 выполняем для профилактики каждый выходной.
P.S. в принципе плохо сравнивать себя с кем-то - для "сравнения" на свете есть всякие соревнования и состязания, где есть правила и контекст. В жизни правил нет, один учится в MIT, другой учится в колледже в России - какие могут быть сравнения? Вы думаете тут большинство людей за один год все узнало и всего добилось? Вы глубоко заблуждаетесь) PHP-шники-выскочки не в счет, у них искаженное представление о реальности.

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

Важно понимать, что различные БД плохо подходят для логического группирования, т.к. разбиение по базам данных нужно скорее для администраторов, а не для приложений. Плюс, в большинстве СУБД, где существует понятие схемы, возможно ставить внешние ключи на таблицы в другой схеме, но нельзя на таблицы в другой БД. Иными словами, отдельные БД удобно создавать тогда, когда вы разделяете данные абсолютно не связанных приложений или сервисов. Например, складского учета и форума поддержки пользователей. С другой стороны, если вы хотите логически разделить таблицы в соответствии с компонентами одного приложения (например, корпоративный портал: 4 таблицы для поддержки авторизации, 10 таблиц для поддержки форума, еще 5 для чата со службой поддержки или отделом продаж) - то именно схемы будут удобным механизмом для этого.

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

А что будет если несколько юзеров будут на одну public-схему коннектиться?

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

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

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

Как вы уже поняли - для независимых приложений, которые могут и должны существовать отдельно друг от друга - лучше делать разные базы. Тогда администраторы смогут спокойно переносить базы с сервера на сервер, независимо их бэкапить и т.д. Для компонентов одного приложения нужно использовать схемы.

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

Основной посыл использования RESTful API - применение основной идеи Паутины для взаимодействия автоматических агентов (приложений), а не только людей.
Основная идея Паутины - построение распределенной информационной системы путем публикации неких абстрактных ресурсов, выдачи им идентификаторов (в сегодняшнем вебе - иерархических), определения ряда простых и широко известных операций над ними, не зависящих от содержимого ресурса (те самые GET, POST, PUT и т.д.), и связывания этих ресурсов ссылками (это называется гипермедиа, и в частности, гипертекст, если речь идет о текстовой информации).
Как люди с появления Веба публикуют информацию в нем для потребления другими людьми, так и RESTful веб-сервисы публикуют иерархически структурированные ресурсы для потребления клиентами. Разница только в представлении - для людей это plaintext/HTML, для автоматических агентов - это JSON/XML/прочие форматы, которые удобно обрабатывать.
Таким образом, если вы хотите какую-то информацию опубликовать как RESTful API, вам необходимо представить ее как набор ресурсов, а все операции над этой информацией выразить через набор предопределенных операций. Фишка в том, что во многих задачах этих предпопределенных операций вполне достаточно, главное правильно определить ресурсы.
Важно понимать, что "ресурс" это обычно некоторая сущность, "существительное". Как правильно заметил Антон Жуков , ресурс /getItems хоть и может существовать в принципе, говорит о неудачно спроектированном API (действие представлено как ресурс).

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

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

Сама архитектура REST не привязана к конкретным технологиям и протоколам, но в реалиях современного Веб, построение RESTful API почти всегда подразумевает использование HTTP и каких-либо распространенных форматов представления ресурсов, например JSON, или, менее популярного сегодня, XML.

Смысл использования REST в том, что принципы, хорошо показавшие себя в "человеческом" веб и позволившие построить самую большую распределенную ИС, применяют и для "веба машин".

Ответ длинноват, но как короче объяснить, чтобы не исказить понимание, не представляю. Если что непонятно - спрашивайте.

И самое главное: кто придумал слабую типизацию?

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

Динамическую типизацию придумали для того, чтобы было легче писать обобщённые алгоритмы и мета-алгоритмы, в дин. языке для обобщения кода не нужны ухищрения типа дженериков (TypeScript, C# и много чего ещё) или шаблонов/макросов (C++). В ОО-языках часто доступны и другие удобства, например смена интерфейса объекта в зависимости от его состояния (т.к. решение о возможности вызова метода/свойства объект может принимать сам).

Слабую типизацию придумали чтобы заставить людей страдать (да, я не знаю кому такое нужно вообще).

Как вы пишете код на жс?

Мы не пишем код на JS, мы пишем код на TypeScript. Да, такие сейчас странные времена, когда язык со статической типизацией компилится в язык с динамической, т.к. исполнять на клиенте (в браузере) больше нечего пока.

Он же не должен быть напичкан parseInt() и !== undefined.

Не должен. Если писать на голом JS, можно а) использовать JSDoc для аннотаций о типах, и работать с типами на уровне документации и договорённостей; б) писать алгоритмы в максимально обобщенной манере, и требовать по возможности не конкретных типов данных, а значений, над которыми допустимы нужные вам операции; в) покрывать код тестами, что и спасает в динамических языках.

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