Почему умение дебажить — один из самых важных навыков для разработчика

Могу добавить, что если просмотр исходного кода не привел к результату, надо обязательно локализовывать баг: убирать все "лишние" сущности и смотреть, остаётся ли ошибка.

Часто помогает, например, с RecyclerView: если странно себя ведёт, сначала убираешь ItemAnimator, потом меняешь LayoutManager на дефолтный (если использовался кастомный), затем "отключаешь" часть элементов (не передаёшь их в адаптер). Когда доходит до этого, уже всё должно проясниться.

Без локализации бага можно долго тыкаться не в те места.

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

P.S:

Давай прибегнем к LayoutManager, посмотрим, что он нам скажет:

Опечатка, должен быть Layout Inspector

Разработка простого DNS сервера на Go, согласно RFC

Так как мы не можем запарсить ответ

А что имеется в виду? Почему не можем? Или тут скорее про "не нужно в рамках текущей задачи"?

Можно же делать рекурсивные DNS запросы, и парсить ответы "вышестоящих" серверов

Пишем Kotlin DSL для графов навигации в домашних условиях

В Compose вопрос навигации тоже актуален. От представления навигации в виде графа никуда не деться