I read an article recently about “writer’s block”; the problem writers have on occasion when they just can’t seem to figure out where to start on their current project or what to say next. In the article, the author commented in passing that the problem of “writer’s block” seemed to be unique to the writing profession; that people in other lines of work such as architects or programmers or musicians didn’t suffer from that malady.

That got me to thinking. Having been a programmer for many years now, I can guarantee that I’ve experienced the equivalent of “writer’s block” on numerous occasions. In my case, the “blockage” usually centers around how best to design a new piece of software or how to proceed when I run into problems with the way I’ve built some part of the application.

Getting started is almost always traumatic to some degree, unless you’re designing a software package that’s very similar to something you’ve done before. Even after gathering as much information as possible about the program(s) to be written, it’s still difficult to decide on the best way to design the system until you’ve created at least the beginnings of a working model of the software.

And even if you get started in good shape, then comes the inevitable list of items you overlooked or didn’t fully understand, combined with the changes and additions requested by the end user. If that list gets too large or too complicated, it’s easy to lose your way. When you reach a point where you can’t see clearly how to proceed, you can even begin to feel like your whole approach may be wrong and you might be better off to scrap everything you’ve done and start over. You’re just not sure what to do next — bingo, “programmer’s block”.

So, what can you do to avoid or at least reduce the chance of running afoul of “programmer’s block”? Let’s take a look at the tips given to writers to overcome this obstacle:

1. “Make at least a rough outline before you start; that way you’ll always have at least a guideline to fall back on”:

   Most software projects have an “outline”, whether it’s called “system specifications” or “the project plan” or something else. I have worked with specifications that were an almost exact blueprint for creating the software — however in my experience that’s the exception, not the rule. If a detailed specification even exists, it’s usually no more than an educated guess as to how to design the system. It doesn’t get into the nuts and bolts of building the software and that’s where “programmer’s block” normally occurs. The main value in a set of system specifications is simply to remind you of what has to go into the system and what needs to come out. How you accomplish that is always subject to change.

2. “Loosen up; forget the deadline and the assignment”:

   This one’s not usually an option. In fact, one of the biggest problems for most programmers is the pressure to meet pre-set deadlines regardless of changes, rewrites or other problems. If you’ve been working non-stop for hours though, it can help to take a quick break — get up, walk around, try to focus on something else for a few minutes.

3. “Switch to an easier project temporarily”:

   Working on some other program that doesn’t give you a headache is a good idea. It relieves some of the stress and gives your confidence a boost. The problem is the same as for tip #2 — you may not have the luxury of taking time off to go work on something else. Deadlines keep coming up regardless of how stressed you might be.

   One trick that can help is to take a look at other programs that perform functions similar to what has you stumped. Sometimes just rummaging through other software and glancing at the way it works can give you an idea of how to attack the problem you’re hung up on. Even if the programming language is different or the software is written for a different platform, the basic approach used in designing the system may spark an idea.

4. “Talk the assignment over with a buddy, your dog, or an imaginary friend”:

   For software developers I would add another option — ask for advice on your favorite forum. How much good this will do you is debatable. As a rule no one else is familiar enough with what you’re working on to be able to provide much help (even if they have the time and inclination). If it’s just a matter of your code not working correctly though, forums can be a great place to get some assistance.

   In the end, the person best suited to help you is you — and sometimes just pacing back and forth and talking it over with yourself has been known to bring forth a solution to the problem of the moment. A word of caution however — you should probably do this in the privacy of your own office or, if you don’t have an office, find a vacant stairwell or an empty breakroom. People who spend a good deal of time talking to themselves tend to make those around them a little bit nervous.

5. “Change your writing environment if necessary”:

   If your environment is a problem, if there’s too much noise and confusion and you’re having trouble concentrating, lock yourself in the restroom, hide under your desk, or do whatever you need to do to get some quiet time. When you’re really focused, things seem to flow out of you in an organized stream like an assembly line. Constant interruptions can cause you to lose focus and suddenly your assembly line goes haywire. You lose track of where you were and where you were planning to go, and it can be a major struggle to get re-started and back on track. It can even lead you to make hurried decisions that take you to a dead-end and leave you wondering what to do next.

6. “Quiet your inner critic — the voice that tells you that nothing you write is good enough”:

   I’m willing to bet that most software developers have an “inner critic”. I know that I do, and it can bring me to complete halt if I let it. There are times (especially if I’m working in an area that’s new to me) when no matter what I come up with, that voice is talking to me, telling me that what I’m doing is amateurish and poorly constructed and is never going to work worth a hoot.

   The only real answer to that inner critic is to slog ahead, check your work, and do the best you can. Software development, like writing, doesn’t just come naturally. It’s hard work and the harder you work at it and the more of it you do, the better the result. No one’s perfect and there are going to be mistakes and things that could have been done better — catch as many problems as you can as early as you can and make lots of notes as to how the system works so changes and additional corrections can be made later.

There are a lot of other answers to avoiding “programmer’s block”; peer reviews, rapid application development techniques, books on best practices. However, if you do get stuck, maybe the best tip is simply to remember that you’ve been there before and survived — and you’ll survive this time too.