I absolutely hate it when the boss comes to me and says that one project or the other is priority and that I shouldn't work on anything else. I just don't work well that way. I like to have two projects going especially if one is hardware and one is software. Gives a nice break for the old brain. I have to get up from the chair and move around so I like to find things outside the realm of coding in which to contribute.

The feast or famine cycle is the same with any act requiring creativity. It's the same whether I designing circuits, coding perl or making little metal widgets. It takes some time to get your head around the problem. Then there is a burst of creativity followed by a period where you just feel 'dumb'.

I started on the hardware end of things where we had a daily journal and had to turn in a copy of our notes at the end of the week. So note taking is ingrained into my work habits. I even keep journals at home. The notes assist in coming back to a task after some interruption. I find as I get older that notes are indispensable in those situations. Some days I'm very glad I took copious notes. Other days I'm very disappointed that I didn't take enough notes.

There is always discussion about bottom-up verses top-down methods, but I switch back and forth between the two depending on my state of mind. On days when my brain feels 'thick' its nice to have a structure to work within. One other days, especially after looking at a problem for a while, the code starts coming out and you can't stop it.

I had a boss once, we worked together at two different companies and got along famously, that insisted that no projects ever be 'rewritten'. He claimed that rewrites took to long and the product was always inferior. Yet you look at a crappy piece of code long enough and you just have to dig in and fix it. I rewrote several of his projects. He never knew until it was too late.

I try to stick to the principles that allowed Charles M. Schulz to create more than 18,000 "Peanuts" comic-strips entirely by himself over the course of 50 years. He did it by consistently producing at least 7 strips a week during every one of those 2,600 weeks. And while it may be said that he did this at the cost of having gotten to do much of anything else, such as “retire,” he got to where he was -- to where he chose to be and wanted to be -- entirely through self-discipline.

Computer programming is engrossing, consuming work. It is also very high-pressure, and the pressure is all the more high because “every one of those weeks, or days,” is not the same. There are days when thoughts flow like water, and days when they flow like frozen tar.

So what I try to do is to write something every day. And for the most part I like to stick to a fairly consistent schedule. That schedule definitely involves keeping “about 9-to-5 hours,” offset by enough of an interval to avoid wasting time in the rush-hour crowds. (I also don't work from my home.) I've been known to stop in the middle of a subroutine. I try to end the day's work with "a note to myself" about what to do tomorrow, and often the next day I completely disagree with that little note. I am careful not to take work home with me, and some of my worst work has been done too-late at night.

The music varies. Sweet-flowing idea days get rewarded with classical or good bluegrass. Tar gets pummeled with Bon Jovi. High-quality comfortable noise-canceling headphones are worth the investment. Your desktop is not a drum.

I use a source-code control system (of course) and commit my work to it several times a day; usually two or three. I've been known to come in on a Tuesday and throw-away just about everything that I did on a Monday. Some days' thoughts are definitely clearer than those of other days.

I take long walks at lunchtime. (I don't know of any programmer worth his or her salt who doesn't like to take long walks at lunchtime...) Some of my best ideas come during those walks. I keep a notepad and a number-two pencil.

As far as overall work-scheduling is concerned, I use a very old beaten-up copy of Microsoft Project, back when they called it that. You've always got to have many things going on at once, and if you can keep them all in your head then you are better than me. That's also where the number-two pencil comes in. When an idea pops in, capture it immediately. Be sure to write clearly and completely. Once you've done that, you can't lose it. Your subconscious mind is thinking about things all the time. When ideas come to the surface they seem crystal-clear at the time but they don't stay around long.

Then I solve the problem.

When the juice is all over the place, I write unit tests against interfaces to a degree, write some skeletal code and then fill it up. It helps me understand how things are laid out.

I try not to be to split across projects. Once I pass two, I start to get confused, or worse, neglectful.

I tend to design on paper/whiteboard (lists of database fields, class diagrams, etc.) and keep a high-level TODO file in each project's root ("complete module X", "add method Y to class Z"), but have never really made notes on what I've already done beyond moving the TODO items into a Changelog. This sometimes led to forgetting the details of how to use bits when I came back to it, but, once I started doing decent automated testing, I was pleasantly surprised to discover that I could easily refresh my memory of how to use a chunk of code by looking at that chunk's tests. Yet another win for testing!

As I work freelance and generally work from home, the only differences between personal and professional coding are that work on client projects gets logged in my billing system and requires me to consult the client for design clarifications/changes.

I currently have five projects at least semi-active, four for clients and one of my own. ("Semi" in that two of them are for the same client and he keeps switching off between having one active and the other on hold.) In general, I don't find multiple projects to be that much of a problem, but, in this particular case, two of the client projects are both relatively large and that's making it hard for me to get much done on any of them, because knowing there's a big project that I need to get done and am not making satisfactory (to me) progress on makes it hard to get motivated to work on anything else - and two such big projects means that, even if I'm working on one, I'm not making progress on the other. Live and learn, I guess.

My programming process is forced and chaotic. I have little time to concentrate on any particular project but yet have several to work on simultaneously. I often start with a half-baked idea, manage to get part way through and then get pulled back into my "normal" work so far that I nearly forget where I was going with the program. The worst I've done is to get a "brilliant" idea, write the code, think of a good name and find that it clashes with another program ... which does about the same thing ... written by me several years earlier. OK, I've only done that a few times but even once is too much.

Just for the record, despite the bad habits, I'm a reasonably skilled programmer (for a non-professional) but certainly not great. I can complete my projects without serious bugs and some of my DB-backed web applications have been in use for several years (albeit only on an intranet). Of course, this isn't to brag (I'm not that foolish) but just to express that even bad habits can produce usable good (but with much more effort).

As the crazies or alcoholics can tell you, admitting the problem is half the battle ... or so I hope since I don't really know if I'll ever manage to find the time and will-power to make up the second half. ;-)

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.

I'm the type that tends to what-if things to death. What if this oddball condition happens and I don't handle it in a clever enough way. What if someone wants to use this function in a curious way. What if someone else might know a better way to do this... what if what if what if... And of course the worst one... What if someone looks at my code...

For me at least, this becomes a death spiral of utter lack of productivity. It's a conscious effort for me to strangle that voice in my head and just write some code to get the job done, even if I know it's crap. But I'll litter my code here and there with some TODO comments so I remember where my weakspots are and maybe an idea of how I wanted to fix it at some point.

The other thing that I do fairly religiously is keep my code tidy at all times. It's just easier for me while I'm coding and I find myself having to rethink an approach to a problem or something, I don't have to mentally parse my own code. Consequently, in vim I type vip= a LOT. (I have equalprg set to run perltidy for me.) And at the same time, I find that I also code faster this way. I'll code a block without worrying a lick about style, then just vip= and it's immediately pretty.

As far as handling and maintaining multiple projects, I just try to divide my time up appropriately, giving myself a fixed amount of time to work on one, then move to the next. When getting close to my time limits, I'll start doing things like writing empty subs with just pseudo code comments and writing as much as I can while my mind is on that particular project. When I'm thinking several steps ahead and I have time to code two of those steps, I'll try to leave myself so that I'll know what the rest of my thought process was. This makes it easier for me to get my mind back on the track of that particular project when it's time for more coding on it without having to recreate the whole thing in my head every time.

Wow! I know what you mean with your words:

"I'm the type that tends to what-if things to death. What if this oddball condition happens and I don't handle it in a clever enough way. What if someone wants to use this function in a curious way. What if someone else might know a better way to do this... what if what if what if... And of course the worst one... What if someone looks at my code..."

"For me at least, this becomes a death spiral of utter lack of productivity. It's a conscious effort for me to strangle that voice in my head and just write some code to get the job done, even if I know it's crap."

I recently finished a project to analyze and determine a variety of statistics on the formation and growth of "warm pixels" on a focal plane to a sensor that we have had on-orbit for a while.

The analysis results were, of course, the important point...but the analysis code took me a couple of months of hard work to complete and was the victim of an almost endless string of "oh that's great! Is the growth occuring in clusters or individual pixels", "are the pixels getting warmer, colder or stable?", "...yada,yada, yada."

The total code ended up being about 700 lines of Perl code (voluminous...but unfortantely more the result of endless adding, adding, and adding new "features" rather than a meaningful design). Towards the end I had some time to sort of look back over the work and the code and realized just how much of a toll the total process of trying to code for maintainability, and for worrying about "what if some of our other folks wanted to use this and chose to this or that." Such endless worries, and worries about trying to guess and account for all the possible wierd use scenarios tend to make my code overly complex and often far more serpantine that I'd like.

DarkLord1 Looking for Redemption in the Monastery

I sometimes visualize meters over my head like a character from The Sims. The most important being level of concentration. I try to identify the things that negatively affect that meter and manage them. For me, distractions as simple as a five minute random conversation with a passerby can scramble the stack in my brain and cost me a good 30 mins of productivity. Too many consecutive interruptions and I'll get too tense to easily regain focus.

I dedicate the early part of my day to eliminating distractions. Handle the e-mail, phone calls, voice mails and co-workers that just want to chat, and review assignments to my employees. Then I shut the door and let my office manager redirect anybody that comes knocking. I wouldn't hear them anyway with the headphones.

All distractions aside, I lay out goals for the day's work and get to it. Having set goals gets me focused before I even get started. The rest of the day usually flies by.

On the bad days, when the focus or creativity just isn't there, I find something productive but relaxing to do. I'll try out a CPAN module I saw and wanted to mess with, or spend a few hours with an O'Reilly book.

If I'm pathetically awfully unproductive, I'll compose long winded forum posts and go home to play Team Fortress 2.

sundialsvc4 touched on this, but I try to never mix home life and work life. I don't entertain myself at work, or work much at home, because then when I'm at work I'm subconsciously trying to talk myself into playing games, and when I'm at home I feel guilty if I relax too much because maybe I should be working instead. It's a guaranteed recipe for a period of burnout.

I started off with BASIC which lends itself to a "top-down" approach, but these days I tend towards the XP style.

Because of my job, I can't hang around and wait for the juices to flow, I have a job to do and it needs to be done now! As a result, I tend to try and tackle the task in small sections, get the first bit working and then add the next. Sometimes it can be hard work, other times it comes easy.

While I know that this isn't exactly the XP formula, it's as close as I'm going to get.