Как избежать ловушки Допосинения (обход кода по кратчайшему пути)

Как работать долго, уставая при этом минимально? Написанное ниже касается программирования, но применимо также и другим видам головной боли интеллектуальной деятельности.

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

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

Затем он пишет код, который не работает так, как надо, и он начинает его отлаживать. Здесь и находится вход в ловушку "ни шага дальше". В зависимости от отношения сложности проблемы к способностям программиста время решения проблемы лежит в интервале от нескольких секунд до нескольких дней, а вторым, но даже более важным параметром, является количество усилий, затрачиваемых на решение проблемы: оно также лежит в некоем ранге от "легко" до "посинения". Хорошо, когда на решение проблемы тратится адекватное ее реальным размерам количество сил. Желательно делать это "легко", можно -- "с трудом", опасно -- "до посинения".

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

Это антоним к "расширению сознания" -- а именно сужение его в одну мысль-точку: "это должно заработать именно так и не иначе".

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

Структура объектно-ориентированного приложения фрактальна, и заблудиться во фрактале так же легко, как в горах. А чтобы все же не заблудиться, нужно представлать себе, в какой части фрактала ты находишься, и если это его относительно малая часть и ты в ней уже давно (уже четыре часа переписываешь 10 строк кода, а они все не работают, как ты хотел) -- то пора выбираться на уровень выше и решать другие проблемы. Главное, сделать это до того, как решение данной задачи отняло почти все силы.

А какие способы есть у вас?