1. отдыхать. Т.е. высыпаться, гулять на свежем воздухе, делать простую работу полностью и с увлечением. (на словах очень просто, на деле сложно)
2. планировать свою учебу и чтение. Т.е. определить сколько время читаем или учимся. когда будет отдых. и т.д.
3. вероятно главный принцип эффективной учебы/чтения это пересмотр. почитали некую часть, отвернулись, вспомнили основные моменты. обдумали. Представили что кому-то объясняем эту тему. Ум должен увлекаться, прилипать к теме.
4. Планировать свои дела. Ум не должен быть нагружен работой по определению, что делать через минуту, как делать, где. и тд. постоянные такие вопросы просто его выматывают. И на нормальную умственную работу уже нет ментальных сил. Лучше уделить пол часа и запланировать на весь день. Даже если что-то пойдет не по плану.
5. Знать цель. Т.е. сознавать мотивацию. Для чего читаем, что хотим и т.д. Концентрацию в Индии примерно описывали так " представь что ты несешь чашу полную воды. Через площадь на которой толпа людей участвует в празднике. Крики шум и т.п. За тобой идет человек с топором. Если ты прольешь хотя бы каплю, то человек сразу отрубит тебе голову." Если приблизить к нашей жизни, то Зачем читать? Что будет если вникнуть в тему? Что будет если не изучить тему? Что будет если постоянно отвлекаться на соцсети и проч. Через неделю, год, десять лет.
еще советы: посмотреть Максима Дорофеева. Проблема современного человека не в том, что ему не хватает внимания, концентрации, энергии и проч. Проблема в том что он тратит внимание впустую. поверхностно. не вникая. Можно сказать он переконцентрирован, измотан концентрацией на совсем не нужных вещах.
Из медитации, посоветую випассану.

Открою секрет )
Пишите тесты. Тесты невозможно написать на плохую архитектуру. Делая новый класс, думайте как будете его тестировать. У вас сразу появится стремление выполнять половину принципов SOLID. (даже если вы их не знаете). Стремление сделать классы лаконичными. С хорошим интерфейсом. Стремление разбивать приложение на компоненты.
Про это много есть статей. тестируемость и архитектура.
Затем можно почитать какие-нибудь книжки. Для начала Роберта Мартина PPP - дословно не помню) но три пи легко можно найти и перевод. (он для C# вроде, но книга классная)
Попробуйте TDD. В работе возможно она не будет нужна, но ухватить идею как создается хороший интерфейс можно.
Затем постоянно себе напоминать, что код пишется для программиста (не для компилятора). Т.е. код это объяснение другому (более тупому))) программисту как это работает. Из этого: хорошие названия - 80% успеха. Остальное архитектура и проч.
Читать код. Свой, чужой, бест практики.
То что свой код бесит - это нормально. Плохо если старый код нравится - значит рост прекратился. Это тревожный звоночек.
Итого.
1)Начинайте свой рост с умения писать тестируемый код.
2) когда почувствуете жжение нехватки опыта в конкретных механизмах (паттернах, принципах) начинайте читать книги.
3) пишите код для тупых программистов (это скромность)
4) быть вне зоны комфорта это нормально.
5+) Почитывайте книги Чистый код Мартина и Совершенный Код Макконнелла (те главы которые вам "заходят")
Удачи в умении сделать сложное простым.)

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

RxJava - это библиотека для реализации реактивного стиля в java
реактивный стиль вещь похожая на более известный функциональный стиль программирования.
выражается он в следующем
есть поток данных, мы применяем к нему некие преобразования и получаем новый поток.
например
(поток запросов в сеть в виде адресов страниц)-> операторЗапросаВСеть -> ОператорПарсинга-> ОператорФормированияДатаОбъектов ->(отображение на экране)
Популярность в андроиде, думаю, приобрел за счет простоты работы с многопоточностью. По крайней мере первые примеры применения в андроиде rx обычно про это.)
вообще, это немного другой способ мышления. отличный от процедурного и ооп.
есть источник, есть получатель и много преобразований.
источник это observable, получатель это subscriber/observer . преобразования это разного рода операторы или их цепочки.
В этом случае мы понимаем приложение как нити потоков данных. такая схема бывает проще чем схема из объектов. иногда.
конечно, мы можем применять и гибриды из этих парадигм.
вообще, это стоит попробовать. возможно она очень вам близка по стилю вашего мышления.