Coder’s Block

Dear KV,

I am a manager of a small development group and one of my programmers seems to spend his whole day staring at his screen but not actually writing code. He then spends weekends and nights in the office and eventually checks in code that actually works, but whenever I ask him why he is just staring during the day, he replies, “Coder’s block,” and then continues to stare. It’s kind of creepy. Is there any such thing as coder’s block?

Not Blocked but Confused

Dear NBC,

Programming is a creative endeavor, and therefore the short answer is yes, there is such a thing as coder’s block. Not only is there such a thing, but there are also various types and sources of coder’s block, some of which I will cover here. If any of these apply to your programmer, you’ll be able to help clear the blockage, since that is what managers are supposed to do.

Perhaps the easiest source of coder’s block to see and understand is distraction. Any modern office environment is a hotbed of distractions, including ringing phones, talking coworkers, people who come by your desk to ask questions (many of which they could answer themselves by reading documentation), meetings, and, of course, well-meaning managers who drop by to ask, “How’s it going?” All but the most trivial coding tasks require quiet and concentration, and if programmers do not get those, then they are not going to be able to build up the intellectual head of steam they need to solve complex problems. Time free from distraction also has to be sufficient to the task. Ask your programmer how long he gets to sit and think between interruptions, and you will probably find it is less than one hour. While some programs can be designed and finished in an hour, they are few and far between. Giving someone who works for you a few distraction-free hours per day is one way to help prevent coder’s block.

One of the best ways to overcome coder’s block is to look at another unrelated piece of code.

One piece of advice for all you programmers out there is to touch code first thing when you come into work. Do not read email, open your instant messaging client, or do anything else that can suck you into distractions that are not coding. When you sit down to work, sit down to work. Email, instant messaging, and social networking are anathema to concentrating on hard problems.

Sometimes coder’s block is brought on by programmers taking on more work than they can handle. Either the problems are too complex, or they just do not know where to start, or both. I don’t know if you have noticed most coders, but they tend to have a large, personal store of hubris that often gets them into trouble, both at and outside of work. If a programmer is staring at a problem for hours on end and making no progress, you can ask if he or she has tried to break down the problem, and perhaps have the person show you how he or she is breaking it down. Do not do this in a nagging way that distracts the programmer (see above). One of the main ways to annoy a coder is to constantly ask, “How’s it going?” You are allowed to ask this once per day, and not when the person looks like he or she is actually concentrating. You might want to ask this question at lunch.

Another type of coder’s block comes from fear of failure. Most people want to do a good job and be recognized for the good work they do. This is especially true of people who do knowledge work, such as programmers, because the only measures of quality are how cleverly and cleanly they have built something. Since software is nearly infinitely malleable, many coders get stuck trying to come up with the absolute neatest, cleverest way to implement something.

The need for perfection leads to many false starts, writing a page of code and then doing what writers used to do when they had a typewriter writer’s block: they crumple up the one page they have finally written and throw it in the trash. When people used paper to write, it was easy to see that they had writer’s block, because their trash cans would be overflowing with crumpled pieces of paper. If you picked up a few of these, you would see that none contained a full page of text; the writers probably got only halfway down a page before they tore it out of the typewriter and threw it away. In our modern world you cannot actually see the false starts, because no one in his or her right mind would check them in.

If you find a programmer making a lot of false starts at a piece of code, give that person something else to work on. One of the best ways to overcome coder’s block is to look at another unrelated piece of code. You want the coder’s mind to remain in a coding mode but to relax its grip on the problem that is causing the angst.

Sometimes when people build systems they expect are going to be extended, they place extra space into a structure for future expansion.

Finally, sometimes coder’s block comes from some sort of emotional problem, usually outside the job, although job stress can also lead to emotional imbalances. I find that jobs, in general, lead to emotional imbalance, as does waking up in the morning, commuting, and talking to stupid people. Sometimes you have to just tell someone to take some time off, so that his or her mind will clear and the coder’s block will lift. Of course, if you find a programmer is just staring at the screen, you might want to take a surreptitious glance at what he or she has written. If it is anything like, “All work and no play make Jack a dull coder,” then it is time to hide the fire axes and call for an intervention.

Dear KV,

I am working on some very old C code that needs to be extended, but there is an annoying complication. This code manipulates an in-memory structure that other programs have to read, but there is a requirement that older binaries still be able to work with the new code. I don’t think this is possible, since once I change the structure the older binaries are definitely going to fail. Is there a way around this?

Backwardly Structured

Dear Backward,

There is a small, but nonzero, chance that you may yet be able to pull this off, but it depends on the structure you are working with. Sometimes when people build systems they expect are going to be extended, they place extra space into a structure for future expansion. Of course I say “sometimes” because although all computer science programs sing paeans to extensibility, they often leave out the practical part of just how one makes code extensible.

If you are lucky, then the structure you need to modify has some extra space, usually labeled as padding, which you can use for your new purposes. All you would need to do is subtract some of the padding and add new elements to the structure that are equal in size to the padding you have removed. Make sure to add the new parts of the structure after the preexisting parts, because if you do not, then your older binaries will be reading your new type of data where they expect their old data to be. That might lead to a crash, which is the good case because you will be able to find the bug; but it might simply lead to getting subtly incorrect results, and those types of bugs are incredibly annoying to search out. And make sure you comment your change and be very clear about the change in your commit message. Messing with in-memory structures in this way can lead to hard-to-find bugs, as I mentioned, and the first thing someone who comes across this type of bug will want to do is to try the code without your change, to see if it is the source of the problem.