...  ↑

Возможно, просто ресурсы мозга рассчитаны на такое время интенсивной интеллектуальной работы?
Я тоже более 4 часов не могу...
-------------------
Время у каждого свое может быть. Еще более значимый показатель - способность мозга включиться в работу точно в тот момент, когда это важно и нужно вам.

Наброски модели...

Ничего особо нового по этой теме наверное не скажу. Уже писано-переписано...

И еще тут нужна консультация эксперта по опенмете :) , с программированием, желательно, незнакомого, чтобы понять, чего для модели не хватает, а что лишнее.

Рабочий цикл.

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

То есть понять, На чем остановился вчера и Что делать дальше?

Обычно делается это с помощью различных подпорок-напоминалок - обязательно! множества комментариев в коде (через неделю, другую, смысл кода забывается напрочь), документации к проекту (реже :), а также красивого и наглядного оформления самого кода.

б) Проект разделен/делится-в-реальном-времени-разработки (чем сложнее задача, тем больше процесс деления выносится в начало, в отдельный этап) на мелкие кусочки, максимально независимые, чтобы за "рабочий день" (это может быть и полчаса, и 14 часов) сделать целое число таких кусочков, подзадач. Например, мелкие по объему методы объекта/подпрограммы (несколько десятков операторов в каждом). Иначе, разобранный кусочек продолжать очень сложно, если выпал вдруг из процесса (не "закончил кодировать и сразу в постель, а утром встал и сразу за комп" а "закончил кодировать, сходил в кино, выпил пивка, утром покатался на велосипеде, и потом за комп" - тут уже выпадание в наличии).

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

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

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

Текущая цель выбирается произвольно, в основном в зависимости от настроения :) Потому что обычно направлений развития много, и можно достаточно гибко их реализовывать.

с) Программируем :)
Точно так же, собственно, мелкими микрошажками, уже с помощью элементарных операторов.

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

Проблемы обычно возникают/выявляются на шаге д) , если исходно (на более высоком, наверное, метауровне, проектирования программы) архитектура была продумана неточно. Обычно это плохо продуманные (несогласованные) форматы возвращаемых на промежуточных этапах данных, или попытки впихнуть в одну подпрограмму слишком много функциональности, которая бывает востребована и по частям, но потом "выковыривать" ее кусочки после написания кода процедуры уже сложно. Завязки на любые внешние по отношению к подпрограмме переменные, вспомогательные элементы, очень вредят.

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

Окончание (постинг большой)

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

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

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

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

Кстати, вполне возможно, что подойдет эта схема и при подготовке документации, технической, справочной (или даже художественной :). Только, чтобы этот процесс формализовать, надо пользоваться европейским стандартом на ведение документации S1000D - http://s1000d.org/

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