On the XpMailingList, KentBeck wrote the following about SoloProgramming:
http://groups.yahoo.com/group/extremeprogramming/message/42127 http://groups.yahoo.com/group/extremeprogramming/message/42405When you are writing, it is a good idea to stop for the day in the middle of a sentence. This forces you to pick up your thought thread the next day, and gives you something obvious to do to make progress.
I experimented with the analogous technique in XP41 - I finished the day by writing a test case. The next day when I started programming, it was obvious what I had to do - get that test working.
It worked well, even when pausing for a week or two between sessions on a particular project.
At a higher level, this technique points out to me the stupidity of proclaiming any One True Way. Here is something I would never do in a team situation that makes good sense when programming solo. I would guess that all practices are sensitive to context.
I have the "compulsion to completion." I derive great pleasure from *finishing* what I have started.
I finish and leave, and am not distracted by thoughts of more stuff that needs to be done before I finish. When I come in the next day, I can do anything. (So I start right in on the new #1 task on my list, of course.)
Maybe I'll try this "leave a test broken" thing. But it sounds crazy to me -- by Monday they'll have changed all the priorities again! ;-> -- JeffGrigg
My TimeManagement training compels me to finish things. (...while the most important concept of time management is to *NOT* work on task #2 until task #1 is finished.) -- JeffGrigg
I have done this often. In addition I often leave a function that doesn't compile so I know where I am at a finer resolution. It's hard to come back to code after a few days when everything works, ...especially when you are coding alone. -- NissimHadar
"Stopping in the middle of a sentence" does more than just give a place to continue in the morning. A standard piece of advice for writers is to stop while you have both momentum and unresolved conflict. The need for resolution will keep your subconscious working on the problem until your next keyboard session. If you are working solo and stop when all tension is resolved - say, when you have both the unit test and the code working, but haven't picked up the next story - you'll start with less energy. -- DaveSmith
There is what I call the Poincare Algorithm. When Poincare, a 19c French mathematician, had a very difficult problem to solve, he first wrote down all the part questions of the problem and answered as many questions as he could at the time. And then among the remaining unsolved questions, he chose which looked the easiest, after which he went on a walk only with the easiest unsolved question in his mind. If any good solution comes up during the walk, he hurries back home, and pored over it on a sheet of paper. He repeats this process till all the part questions of the problem are answered.
When I used the Poincare Algorithm, the answer emerged to me while I was having a lunch or even on the bed at night. It is because your subconsciousness works very hard even when you are doing other things or nothing at all. One night, I was just about to fall asleep on the bed, and the whole solution - that time it was a piece of code for a very difficult algorithm - just "waterfell" unto me from the dark ceiling like shining stars and beautiful fireworks. I turned on the light and the computer and punched it in like crazy for half an hour or so. I was struggling with the problem for a month but I solved most of it just in that short time. It was almost a spiritual experience. :)
I find this algorithm works best when I do take a walk or a sleep with the problem, both of which are well grounded on the recent brain science findings.
I had great experiences from LeaveaTestBroken approach just as Poincare Algorithm worked for me. Especially, when the task seems very difficult, complicated, and stressing out. -- JuneKim