![[userpic]](http://localhost:4000/images/none.gif)
... ↑
ex_sbobrovsk689 в посте Openmeta (оригинал в ЖЖ)
Небольшой специалист по OpenMeta (пока :), поэтому не судите строго. Только наброски...
Да, очень сильно зависит от рода деятельности. Программирование - одно состояние, а подготовка статьи - совсем другое.
Обычно хорошая Активность отмечается после хорошей физической нагрузки. Если деятельность связана с логическим мышлением (программирование), то именно на фоне отдыха после нагрузки работается успешно. Если что-то ближе к "потоку сознания" :) , как при подготовке большой статьи в достаточно свободном стиле, то лучше выходит вечером, причем не с основным ПК, а с ноутбуком и в более интимной обстановке, в уголке где-нибудь.
19 комментариев
сначала старые сначала новые
согласен!
от себя добавлю, что у меня ещё хорошо получается программировать утром, как только проснусь, первые часа 4, может чуть побольше.
от себя добавлю, что у меня ещё хорошо получается программировать утром, как только проснусь, первые часа 4, может чуть побольше.
Небольшой специалист по OpenMeta (пока :), поэтому не судите строго. Только наброски...
-------------
Если вы работаете за компьютером и готовы поделиться своими рабочими "секретами" - это уже приветствуется и ценится.
Да, очень сильно зависит от рода деятельности. Программирование - одно состояние, а подготовка статьи - совсем другое.
----------------
Род деятельности, в моем понимании, - первейший критерий группировки серии разноплановых работ. Выполнение другого, но все же немного сходного рода деятельности за компом, переключает Субстрат на эту деятельность плавно, экологично. Хотя и в переключении на совсем иной род деятельности (задействует иные процессы восприятия и внимания) тоже есть свои преимущества.
Обычно хорошая Активность отмечается после хорошей физической нагрузки.
-----------------
Подталкивает Субстрат к более продуктивным решениям, ага?
А какого рода нагрузка? Может быть статическая, а может двигательная и динамическая.
Если деятельность связана с логическим мышлением (программирование), то именно на фоне отдыха после нагрузки работается успешно.
---------------
Вы отдыхаете, а Субстрат продолжает выдавать решения)
Если что-то ближе к "потоку сознания" :) , как при подготовке большой статьи в достаточно свободном стиле, то лучше выходит вечером, причем не с основным ПК, а с ноутбуком и в более интимной обстановке, в уголке где-нибудь.
---------------------
Совершенно блестящий вариант создать нужный РабочийНастрой! Отдельный компьютер для особого рода работ. Что еще может быть более сильным якорем? Какие бы якоря для доступа к РабочимНастроям человек ни использовал, - а компьютер обычно одиин и тот же. А тут - разные. Класс!
Тольок надо следить за выполнением на ноутбуке одной и той же задачи в типичной домашней обстановке, и устойчивость Настроя вам обеспечена. Плюс иметь как минимум особенное место для такой работы (как и есть в вашем случае).
-------------
Если вы работаете за компьютером и готовы поделиться своими рабочими "секретами" - это уже приветствуется и ценится.
Да, очень сильно зависит от рода деятельности. Программирование - одно состояние, а подготовка статьи - совсем другое.
----------------
Род деятельности, в моем понимании, - первейший критерий группировки серии разноплановых работ. Выполнение другого, но все же немного сходного рода деятельности за компом, переключает Субстрат на эту деятельность плавно, экологично. Хотя и в переключении на совсем иной род деятельности (задействует иные процессы восприятия и внимания) тоже есть свои преимущества.
Обычно хорошая Активность отмечается после хорошей физической нагрузки.
-----------------
Подталкивает Субстрат к более продуктивным решениям, ага?
А какого рода нагрузка? Может быть статическая, а может двигательная и динамическая.
Если деятельность связана с логическим мышлением (программирование), то именно на фоне отдыха после нагрузки работается успешно.
---------------
Вы отдыхаете, а Субстрат продолжает выдавать решения)
Если что-то ближе к "потоку сознания" :) , как при подготовке большой статьи в достаточно свободном стиле, то лучше выходит вечером, причем не с основным ПК, а с ноутбуком и в более интимной обстановке, в уголке где-нибудь.
---------------------
Совершенно блестящий вариант создать нужный РабочийНастрой! Отдельный компьютер для особого рода работ. Что еще может быть более сильным якорем? Какие бы якоря для доступа к РабочимНастроям человек ни использовал, - а компьютер обычно одиин и тот же. А тут - разные. Класс!
Тольок надо следить за выполнением на ноутбуке одной и той же задачи в типичной домашней обстановке, и устойчивость Настроя вам обеспечена. Плюс иметь как минимум особенное место для такой работы (как и есть в вашем случае).
...у меня ещё хорошо получается программировать утром, как только проснусь, первые часа 4, может чуть побольше.
----------------
Это получается РабочийНастрой на программирование, который запускается
1. Временным якорем - утро,
2. Якорем СостоянияПослеПробуждения.
----------------
Это получается РабочийНастрой на программирование, который запускается
1. Временным якорем - утро,
2. Якорем СостоянияПослеПробуждения.
НЕТ! (извини за резкость)
якори тут не причём.
фишка в том, что после просыпа просто у меня самое пиково-работоспособное сосотояние во _всех_ облостях (но только если не включается якорь принудиловки, типа ожидания лекции в колледже)
кстати, а как убивать якори, которые мне мешают?
якори тут не причём.
фишка в том, что после просыпа просто у меня самое пиково-работоспособное сосотояние во _всех_ облостях (но только если не включается якорь принудиловки, типа ожидания лекции в колледже)
кстати, а как убивать якори, которые мне мешают?
>> логическим мышлением (программирование)
данное утверерждение сугубо имхо НЕВЕРНО.
современное программирование - не совсем логика.. тоесть на одной логике далеко не уедешь, в таком смысле смысле... очень много гоммунитарного и чисто творческого элемента, ну у меня по крайней мере. а вообще что такое логика?
кстати, не плохо было бы составить мета-модель процесса программирования. я так понял это комъюнити именно такими вещами занимается да?
данное утверерждение сугубо имхо НЕВЕРНО.
современное программирование - не совсем логика.. тоесть на одной логике далеко не уедешь, в таком смысле смысле... очень много гоммунитарного и чисто творческого элемента, ну у меня по крайней мере. а вообще что такое логика?
кстати, не плохо было бы составить мета-модель процесса программирования. я так понял это комъюнити именно такими вещами занимается да?
Возможно, просто ресурсы мозга рассчитаны на такое время интенсивной интеллектуальной работы?
Я тоже более 4 часов не могу...
Если вы работаете за компьютером и готовы поделиться своими рабочими "секретами" - это уже приветствуется и ценится.
---
Постараюсь, но не сразу. Их сначала надо осознать:)
А какого рода нагрузка? Может быть статическая, а может двигательная и динамическая.
---
Велосипед, долго и интенсивно, часа полтора.
Вы отдыхаете, а Субстрат продолжает выдавать решения)
---
Угу! Возможно, хорошая нагрузка просто снимает разный "мысленный" мусор, логика как-то чище, чтоли, работает...
Отдельный компьютер для особого рода работ. Что еще может быть более сильным якорем?
---
Действительно, я об этом и не подумал. И с местом тоже, так и есть. Есть места в квартире, излюбленные и неизлюбленные. Места силы и слабости:)
Спасибо!
---
Постараюсь, но не сразу. Их сначала надо осознать:)
А какого рода нагрузка? Может быть статическая, а может двигательная и динамическая.
---
Велосипед, долго и интенсивно, часа полтора.
Вы отдыхаете, а Субстрат продолжает выдавать решения)
---
Угу! Возможно, хорошая нагрузка просто снимает разный "мысленный" мусор, логика как-то чище, чтоли, работает...
Отдельный компьютер для особого рода работ. Что еще может быть более сильным якорем?
---
Действительно, я об этом и не подумал. И с местом тоже, так и есть. Есть места в квартире, излюбленные и неизлюбленные. Места силы и слабости:)
Спасибо!
современное программирование - не совсем логика.. тоесть на одной логике далеко не уедешь, в таком смысле смысле... очень много гоммунитарного и чисто творческого элемента, ну у меня по крайней мере.
---
Ну не знаю :) По моим оценкам, 90% в разработке софта - логико-алгоритмической или вообще тупо-кодировочной рутины.
Я кстати творческие и нетворческие виды деятельности делю так: если могу делать что-то, хорошо напившись пива :) , то есть работает встроенный навык, значит, нетворческая работа. Если не могу, значит творческая.
Программировать могу в состоянии тяжелого опьянения :) А вот писать текст - увы...
Хотя есть и прямо противоположные примеры.
что такое логика?
---
Подозрение, что это то, что активизирует деятельность левого полушария. Хорошо разница выявляется на цифровом энцефалографе например. Программирование, решение интеллектуальных задач левополушарно. В отличие от сочинения стихов (не халтурных :). Или медитации...
Со значительными оговорками, конечно, но корреляция сильная...
http://www.voppsy.ru/issues/1988/884/884149.htm
Хотя, все взаимосвязано, конечно...
Или ритмы надо вспомнить, программирование - наверное бета-ритм, творчество - альфа?
не плохо было бы составить мета-модель процесса программирования
---
О, поддерживаю!!!
---
Ну не знаю :) По моим оценкам, 90% в разработке софта - логико-алгоритмической или вообще тупо-кодировочной рутины.
Я кстати творческие и нетворческие виды деятельности делю так: если могу делать что-то, хорошо напившись пива :) , то есть работает встроенный навык, значит, нетворческая работа. Если не могу, значит творческая.
Программировать могу в состоянии тяжелого опьянения :) А вот писать текст - увы...
Хотя есть и прямо противоположные примеры.
что такое логика?
---
Подозрение, что это то, что активизирует деятельность левого полушария. Хорошо разница выявляется на цифровом энцефалографе например. Программирование, решение интеллектуальных задач левополушарно. В отличие от сочинения стихов (не халтурных :). Или медитации...
Со значительными оговорками, конечно, но корреляция сильная...
http://www.voppsy.ru/issues/1988/884/884149.htm
Хотя, все взаимосвязано, конечно...
Или ритмы надо вспомнить, программирование - наверное бета-ритм, творчество - альфа?
не плохо было бы составить мета-модель процесса программирования
---
О, поддерживаю!!!
НЕТ! (извини за резкость)
якори тут не причём.
фишка в том, что после просыпа просто у меня самое пиково-работоспособное сосотояние во _всех_ облостях (но только если не включается якорь принудиловки, типа ожидания лекции в колледже)
---------------
Понятно)
кстати, а как убивать якори, которые мне мешают?
--------------
Если посмотреть "Из лягушек в принцы" Р.Бэндлера и Д.Гриндера - там можно найти описания работы с якорями.
Из последних упоминаний в OpenMeta есть кратко в верхней половине поста здесь http://www.livejournal.com/community/openmeta/159790.html
якори тут не причём.
фишка в том, что после просыпа просто у меня самое пиково-работоспособное сосотояние во _всех_ облостях (но только если не включается якорь принудиловки, типа ожидания лекции в колледже)
---------------
Понятно)
кстати, а как убивать якори, которые мне мешают?
--------------
Если посмотреть "Из лягушек в принцы" Р.Бэндлера и Д.Гриндера - там можно найти описания работы с якорями.
Из последних упоминаний в OpenMeta есть кратко в верхней половине поста здесь http://www.livejournal.com/community/openmeta/159790.html
Возможно, просто ресурсы мозга рассчитаны на такое время интенсивной интеллектуальной работы?
Я тоже более 4 часов не могу...
-------------------
Время у каждого свое может быть. Еще более значимый показатель - способность мозга включиться в работу точно в тот момент, когда это важно и нужно вам.
Я тоже более 4 часов не могу...
-------------------
Время у каждого свое может быть. Еще более значимый показатель - способность мозга включиться в работу точно в тот момент, когда это важно и нужно вам.
Если вы работаете за компьютером и готовы поделиться своими рабочими "секретами" - это уже приветствуется и ценится.
---
Постараюсь, но не сразу. Их сначала надо осознать:)
-------------------
Да простыми наблюдениями вроде где и когда лучше работается, в какое время, на каком месте, какие-то простые (или не очень) ритуалы для создания рабочего настроя за компьютером, наконец, своим самочувствием за компьютером. Это я и назвал на скорую руку "секретами")
А какого рода нагрузка? Может быть статическая, а может двигательная и динамическая.
---
Велосипед, долго и интенсивно, часа полтора.
---------------
Ага, нагрузка динамическая, с четким режимом дыхания, сердцебиения, и мышечной работы.
Угу! Возможно, хорошая нагрузка просто снимает разный "мысленный" мусор, логика как-то чище, чтоли, работает...
------------------
Получается, что-то вроде этого..
Отдельный компьютер для особого рода работ. Что еще может быть более сильным якорем?
---
Действительно, я об этом и не подумал. И с местом тоже, так и есть. Есть места в квартире, излюбленные и неизлюбленные. Места силы и слабости:)
Спасибо!
---------------
Даже не самые излюбленные места для компьютерной работы наверняка могут быть очень излюбленнымии и "сильными" для чего-то другого:)
---
Постараюсь, но не сразу. Их сначала надо осознать:)
-------------------
Да простыми наблюдениями вроде где и когда лучше работается, в какое время, на каком месте, какие-то простые (или не очень) ритуалы для создания рабочего настроя за компьютером, наконец, своим самочувствием за компьютером. Это я и назвал на скорую руку "секретами")
А какого рода нагрузка? Может быть статическая, а может двигательная и динамическая.
---
Велосипед, долго и интенсивно, часа полтора.
---------------
Ага, нагрузка динамическая, с четким режимом дыхания, сердцебиения, и мышечной работы.
Угу! Возможно, хорошая нагрузка просто снимает разный "мысленный" мусор, логика как-то чище, чтоли, работает...
------------------
Получается, что-то вроде этого..
Отдельный компьютер для особого рода работ. Что еще может быть более сильным якорем?
---
Действительно, я об этом и не подумал. И с местом тоже, так и есть. Есть места в квартире, излюбленные и неизлюбленные. Места силы и слабости:)
Спасибо!
---------------
Даже не самые излюбленные места для компьютерной работы наверняка могут быть очень излюбленнымии и "сильными" для чего-то другого:)
пасиб
а что из себя представляет процесс создания мета-модели? я совсем новичок в этом, но идея ужасно нравится
а что из себя представляет процесс создания мета-модели? я совсем новичок в этом, но идея ужасно нравится
--------------
Если вы уже чего-то ожидаете от мета-модели в области программирования -получается, что какие-то представления о мета-модели у вас есть...
--------------
Если вы уже чего-то ожидаете от мета-модели в области программирования -получается, что какие-то представления о мета-модели у вас есть...
А если он не захочет, то "мы его веником" !
Для начала, наверное, замечать наиболее типичные моменты внешней деятельности и внутренние состояния в какие-то ключевые точки работы.
А если он не захочет, то "мы его веником" !
----------------
Не каждый захочет свои мозги веником "парить")
Описали бы как это вам удается.
----------------
Не каждый захочет свои мозги веником "парить")
Описали бы как это вам удается.
Наброски модели...
Ничего особо нового по этой теме наверное не скажу. Уже писано-переписано...
И еще тут нужна консультация эксперта по опенмете :) , с программированием, желательно, незнакомого, чтобы понять, чего для модели не хватает, а что лишнее.
Рабочий цикл.
а) Сначала восстанавливаем контекст вокруг кода, который надо продолжить, или вокруг объекта/модуля, функциональность которого надо развивать.
То есть понять, На чем остановился вчера и Что делать дальше?
Обычно делается это с помощью различных подпорок-напоминалок - обязательно! множества комментариев в коде (через неделю, другую, смысл кода забывается напрочь), документации к проекту (реже :), а также красивого и наглядного оформления самого кода.
б) Проект разделен/делится-в-реальном-времени-разработки (чем сложнее задача, тем больше процесс деления выносится в начало, в отдельный этап) на мелкие кусочки, максимально независимые, чтобы за "рабочий день" (это может быть и полчаса, и 14 часов) сделать целое число таких кусочков, подзадач. Например, мелкие по объему методы объекта/подпрограммы (несколько десятков операторов в каждом). Иначе, разобранный кусочек продолжать очень сложно, если выпал вдруг из процесса (не "закончил кодировать и сразу в постель, а утром встал и сразу за комп" а "закончил кодировать, сходил в кино, выпил пивка, утром покатался на велосипеде, и потом за комп" - тут уже выпадание в наличии).
"Проект разделен на кусочки" - вещь довольно условная. Собственно, понятие "программиста" тоже довольно расплывчато, потому что на первых этапах, когда программа только начинается, основное внимание уделяется ее проектированию, продумыванию архитектуры. Как она будет работать, какие будут внутри нее процессы, как ими управлять, как контролировать. Сверху-вниз классический принцип, без низкоуровневой детализации.
О проектироании здесь говорить не к месту, я имею пока в виду нечто более близкое к модели кодировщика, когда архитектура системы готова, и надо только закодировать техзадание.
То есть на шаге б) формируется некая небольшая цель (очередное расширение функциональности программы, перевод необходимых для реализации функций в состояние "запрограммировано" :). Причем эта цель обычно связана с какими-то внешними, визуальными вещами, которые пользователь может "потрогать" (нажал на кнопку - получил ответ). Сам по себе код, который особо ничего не делает с точки зрения потребителя, стараюсь делать только в конце, в оптимизационных целях в основном.
Текущая цель выбирается произвольно, в основном в зависимости от настроения :) Потому что обычно направлений развития много, и можно достаточно гибко их реализовывать.
с) Программируем :)
Точно так же, собственно, мелкими микрошажками, уже с помощью элементарных операторов.
д) Постоянно тестируем/отлаживаем то, что получается. Сделанный в б) кусочек проверяю часто по шагам, особенно в условных развилках, или где важные результаты формируются, контролируем правильность.
Проблемы обычно возникают/выявляются на шаге д) , если исходно (на более высоком, наверное, метауровне, проектирования программы) архитектура была продумана неточно. Обычно это плохо продуманные (несогласованные) форматы возвращаемых на промежуточных этапах данных, или попытки впихнуть в одну подпрограмму слишком много функциональности, которая бывает востребована и по частям, но потом "выковыривать" ее кусочки после написания кода процедуры уже сложно. Завязки на любые внешние по отношению к подпрограмме переменные, вспомогательные элементы, очень вредят.
Поэтому на шаге б) особо внимательным надо быть к описанию и соблюдению входных/выходных данных, а также к минимизации реализуемой функциональности в одной подпрограмме - она должна быть минимально необходимой по смыслу и максимально автономной и независимой от других элементов программы (что также повышает вероятность ее использования в разных контекстах).
Ничего особо нового по этой теме наверное не скажу. Уже писано-переписано...
И еще тут нужна консультация эксперта по опенмете :) , с программированием, желательно, незнакомого, чтобы понять, чего для модели не хватает, а что лишнее.
Рабочий цикл.
а) Сначала восстанавливаем контекст вокруг кода, который надо продолжить, или вокруг объекта/модуля, функциональность которого надо развивать.
То есть понять, На чем остановился вчера и Что делать дальше?
Обычно делается это с помощью различных подпорок-напоминалок - обязательно! множества комментариев в коде (через неделю, другую, смысл кода забывается напрочь), документации к проекту (реже :), а также красивого и наглядного оформления самого кода.
б) Проект разделен/делится-в-реальном-времени-разработки (чем сложнее задача, тем больше процесс деления выносится в начало, в отдельный этап) на мелкие кусочки, максимально независимые, чтобы за "рабочий день" (это может быть и полчаса, и 14 часов) сделать целое число таких кусочков, подзадач. Например, мелкие по объему методы объекта/подпрограммы (несколько десятков операторов в каждом). Иначе, разобранный кусочек продолжать очень сложно, если выпал вдруг из процесса (не "закончил кодировать и сразу в постель, а утром встал и сразу за комп" а "закончил кодировать, сходил в кино, выпил пивка, утром покатался на велосипеде, и потом за комп" - тут уже выпадание в наличии).
"Проект разделен на кусочки" - вещь довольно условная. Собственно, понятие "программиста" тоже довольно расплывчато, потому что на первых этапах, когда программа только начинается, основное внимание уделяется ее проектированию, продумыванию архитектуры. Как она будет работать, какие будут внутри нее процессы, как ими управлять, как контролировать. Сверху-вниз классический принцип, без низкоуровневой детализации.
О проектироании здесь говорить не к месту, я имею пока в виду нечто более близкое к модели кодировщика, когда архитектура системы готова, и надо только закодировать техзадание.
То есть на шаге б) формируется некая небольшая цель (очередное расширение функциональности программы, перевод необходимых для реализации функций в состояние "запрограммировано" :). Причем эта цель обычно связана с какими-то внешними, визуальными вещами, которые пользователь может "потрогать" (нажал на кнопку - получил ответ). Сам по себе код, который особо ничего не делает с точки зрения потребителя, стараюсь делать только в конце, в оптимизационных целях в основном.
Текущая цель выбирается произвольно, в основном в зависимости от настроения :) Потому что обычно направлений развития много, и можно достаточно гибко их реализовывать.
с) Программируем :)
Точно так же, собственно, мелкими микрошажками, уже с помощью элементарных операторов.
д) Постоянно тестируем/отлаживаем то, что получается. Сделанный в б) кусочек проверяю часто по шагам, особенно в условных развилках, или где важные результаты формируются, контролируем правильность.
Проблемы обычно возникают/выявляются на шаге д) , если исходно (на более высоком, наверное, метауровне, проектирования программы) архитектура была продумана неточно. Обычно это плохо продуманные (несогласованные) форматы возвращаемых на промежуточных этапах данных, или попытки впихнуть в одну подпрограмму слишком много функциональности, которая бывает востребована и по частям, но потом "выковыривать" ее кусочки после написания кода процедуры уже сложно. Завязки на любые внешние по отношению к подпрограмме переменные, вспомогательные элементы, очень вредят.
Поэтому на шаге б) особо внимательным надо быть к описанию и соблюдению входных/выходных данных, а также к минимизации реализуемой функциональности в одной подпрограмме - она должна быть минимально необходимой по смыслу и максимально автономной и независимой от других элементов программы (что также повышает вероятность ее использования в разных контекстах).
Окончание (постинг большой)
Потеря внимания, бдительности :) - основной источник проблем... Хотя, все же, если исходно спроектировано правильно, то потом ошибок почти не бывает. Обычно проблемы начинаются, когда заказчик просит доработать уже готовое ("вот тут чуть-чуть переделать"), а на самом деле это означает "есть дом в десять этажей, надо седьмой этаж чуть-чуть перестроить, на миллиметр стены расширить". Объяснить, что "размер" - миллиметр или метр, значения не играет, так как все равно придется сносить три вышестоящих этажа, а потом достраивать их заново, обычно очень сложно... Это же всего миллиметр! :) Заказчик мыслит совсем другими категориями.
И когда начинаешь делать "и нашим, и вашим", программа запутывается, и все...
Есть способы обхода этой потенциальной опасности, через изначальную ориентацию на максимальную гибкость архитектуры продукта и легкую возможность его любого расширения, но такая архитектура сама по себе стоит дорого в плане трудоемкости.
Тут у меня, конечно, переплетены в куче элементы модели программиста и методологические элементы проектирования, из программной инженерии. Описания методик типа экстремального программирования или CMM уже сами по себе, наверное, достаточно хорошо описывают модель программиста... Немного с другой точки зрения, конечно, не от состояний, а от организации процесса разработки. Но состояние ведь не уникально для программиста, любая интеллектуальная деятельность тут подойдет.
Кстати, для начинающих разработчиков актуально в основном нечто описанное выше, когда еще хорошего навыка кодирования нету. А для достаточно опытных (меня например :), состояние - главное, потому как производительность может различаться в сотни раз.
Интересно, что в литературной деятельности такого различия не бывает. Стивен Кинг пишет в день 5 кб текста, но даже 50 кб качественного (это важно) текста написать в день крайне сложно. Подготовка текстов - процесс более линейный, а в программировании все больше упирается в "угадать вначале правильную архитектуру системы".
Кстати, вполне возможно, что подойдет эта схема и при подготовке документации, технической, справочной (или даже художественной :). Только, чтобы этот процесс формализовать, надо пользоваться европейским стандартом на ведение документации S1000D - http://s1000d.org/
Он схож с программистскими концепциями, подразумевает составление документа из модулей, которые можно потом повторно использовать, и т. д.
Потеря внимания, бдительности :) - основной источник проблем... Хотя, все же, если исходно спроектировано правильно, то потом ошибок почти не бывает. Обычно проблемы начинаются, когда заказчик просит доработать уже готовое ("вот тут чуть-чуть переделать"), а на самом деле это означает "есть дом в десять этажей, надо седьмой этаж чуть-чуть перестроить, на миллиметр стены расширить". Объяснить, что "размер" - миллиметр или метр, значения не играет, так как все равно придется сносить три вышестоящих этажа, а потом достраивать их заново, обычно очень сложно... Это же всего миллиметр! :) Заказчик мыслит совсем другими категориями.
И когда начинаешь делать "и нашим, и вашим", программа запутывается, и все...
Есть способы обхода этой потенциальной опасности, через изначальную ориентацию на максимальную гибкость архитектуры продукта и легкую возможность его любого расширения, но такая архитектура сама по себе стоит дорого в плане трудоемкости.
Тут у меня, конечно, переплетены в куче элементы модели программиста и методологические элементы проектирования, из программной инженерии. Описания методик типа экстремального программирования или CMM уже сами по себе, наверное, достаточно хорошо описывают модель программиста... Немного с другой точки зрения, конечно, не от состояний, а от организации процесса разработки. Но состояние ведь не уникально для программиста, любая интеллектуальная деятельность тут подойдет.
Кстати, для начинающих разработчиков актуально в основном нечто описанное выше, когда еще хорошего навыка кодирования нету. А для достаточно опытных (меня например :), состояние - главное, потому как производительность может различаться в сотни раз.
Интересно, что в литературной деятельности такого различия не бывает. Стивен Кинг пишет в день 5 кб текста, но даже 50 кб качественного (это важно) текста написать в день крайне сложно. Подготовка текстов - процесс более линейный, а в программировании все больше упирается в "угадать вначале правильную архитектуру системы".
Кстати, вполне возможно, что подойдет эта схема и при подготовке документации, технической, справочной (или даже художественной :). Только, чтобы этот процесс формализовать, надо пользоваться европейским стандартом на ведение документации S1000D - http://s1000d.org/
Он схож с программистскими концепциями, подразумевает составление документа из модулей, которые можно потом повторно использовать, и т. д.