This is an interesting meditation. I, too, often wonder about and "stew" over my development "process."

Most often, for me, I have as many as 3 different coding tasks in my queue. Sometimes with a couple of more "shelved." But, for me, I am sufficiently compulsive to solve a problem that I rarely can handle more than a couple (may be 3 at most) on my mind. So I'm not nearly as "multi-tasked" as your meditation suggests you find yourself in.

The nature of my work (and the 2 or 3 other folks that I work with) is mostly putting out "fires"...i.e., we find ourselves or our colleagues facing some daunting task and we decide to tackle it. Time is normally "of the essence" and sophistication, ellegance, etc. are largely irrelevant. So we tend to try to solve the problems in the most direct, easy, and easily tested and proved ways possible. That, at least for me, creates the format of my approach.

My approach is simply one of (A) think about the problem for a few days, (B) prototype, quickly, the tough parts, (C) code the solution, and then (D) do final tests of the solution...usually with a lot of debugging and fixing of mistakes.

The hard part for me is normally step (C): coding. The size of our solutions are usually in the realm of a few hundred lines of code and, for me, that normally means about 2-3 days of almost non-stop coding. It is exhausting; and it seems that it consumes my "day job" (which is not normally about coding or implementing solutions...I am a systems engineer who spends most of his time guiding others and handling the politics of our projects).

So these interludes of intense programming are always a bit of a shock to my system and I think the efficiency of my coding suffers because of it...especially during the latter stages of the coding when I'm at my tiredest and my thinking is more dominated by lack of sleep and deprived body.

Recognizing this tendency, I tend to do a lot of module building in the beginning while I'm fresh and then spend more of the latter stages tie'ing them together to form the overall architecture in the latter stages. This works pretty well for me...but the mistakes and challenges that crop up in the latter stages tend to be real "bears!" They generally involve mistakes in the solution's fundamental logic and program flow: even though the pieces are all working correctly. In a tired state, finding the fundamental logic or control errors is daunting. Thank goodness for some good debuggers (especially the native Perl debugger) that allow some pretty methodical flow tracing.