Programming is Like a Dream
Have you ever noticed that computer programmers are very easy to startle? Walk up behind an accountant or a web designer sketching out banner ads, and nine times out of ten they’ll know you’re coming from a mile away. But computer programmers aren’t like that. You can stand right behind a programmer for ten minutes and quite often they will not even know you are there–especially when they are working on a difficult section. The larger the system, the deeper the trance.
I just read two fantastic essays describing programming as a dream-like state. I’d never thought of it this way before, but I’d have to say that’s the most dead-on accurate description I’ve ever heard.
Now, imagine you were in deep sleep, dreaming away about apples at 3am, and I came bashing into your room and said “Sorry, but we need you to dream about bananas now.” Do you think you could go straight back to sleep in a few seconds, dream about bananas for a bit, and then jump back to your original dream about apples? No, of course not, but this is what managers expect when they throw new tasks at us while we’re busy coding the first one. When this happens we’ve lost the hours we’ve spent on the first dream, we’re completely lost for half an hour, and then we eventually manage to get into the new dream.
This is very true. It takes a little while to “shift gears”. For small programs, it’s not so bad, because you can conceptualize the whole thing in a few minutes or seconds. For large systems it takes longer to get yourself back into the right frame of mind. You have to think about all the things you were thinking about when you put it down last, and this is often a lot harder than it sounds. There’s a small time penalty that’s paid every time a programmer sits down to work, but it’s only paid once per session. This is why a lot of programmers prefer to work in one long stretch instead of several short ones. In six 30 minute stretches, zero code will get written–zero good code, anyway–because you spend the entire time just getting started. In one three hour stretch, however, you might just compose a masterpiece.
I can sit down and start coding right away, but I don’t really “hit my groove” for an hour or two. Sometimes I try to accelerate that by leaving myself a thread the day before. I’ll intentionally not finish a block of code I was working on, but I’ll leave myself copious notes on how to write it so that when I sit down in the morning I can start right away on that block. In the morning I don’t really have to think about the block too much because the answer is right there, but by-and-by as I code it up the thoughts start rushing back to me. By the time I’ve finished writing the block, my head is where it needs to be and I can pick it up from there. Sometimes if the code is very complex I just keep thinking about the code until morning. Most programmers can and will do this, too. Some perhaps can’t hold onto the code for days or weeks, but virtually all can for a few minutes or even a couple of hours.
I know it sounds strange, but think of it this way: Have you ever had a dream that lingered? You know, when you have a nightmare or other intense dream, and it keeps coming back to you while your doing other things throughout the day? Your mind is still dreaming the dream even though you are awake, and you can feel it back there drifting around. Keeping code in your head feels very much the same way.
There’s a right and a wrong way to interrupt a programmer. The best answer is “don’t”. But if you must… If you think about programming like dreaming, you’ll realize that programmers remember more if you interrupt them gently than if you barrage them. If someone wakes you out of bed and starts shouting a long list of things at you to remember, you’ll almost certainly forget what you were dreaming. However, if someone shakes you gently and gives you a few seconds to open your eyes and look around before they start talking, it’s a lot easier to remember the dream for later. The same works for programmers. If you just walk into their office and start talking, one of two things will happen: they’ll completely forget what they were coding, or they won’t really be paying attention to you. However, if you quietly walk up to them and let them know you are there but say nothing until they are ready, the programmer can come to the end of the thought they are on. Once they’ve finished their thought, it will be easier for them to pick up next time and still pay attention to what you have to say.
Let’s take a maze for example. There is a task for the programmer to come up with an algorithm of finding the way out of the maze. When a programmer is working on this task he isn’t just a God’s Finger showing the directions to a little girl lost in a great maze. He isn’t that girl or the walls of a labyrinth either. He is actually all of that in a same time. In order to solve the task he must BECOME the labyrinth, the walls, the lost little girl and whatever else may just came along with it. It is not a figure of the speech – the programmer is literally SLEEPING and DREAMING that all in his mind.
My brother contends that it is this same phenomena that makes programmers so bad at estimates. The problem is, as he says, that the programmer already knows everything that needs to be written. When you have it all in your mind, it seems like it should be easy to write it all down. But it’s not. The physical act of writing the code takes a long time. But more importantly, your mind never thinks about all the “meaningless” details. It knows how to code them so well it doesn’t even need consider their existence anymore. Unfortunately, the computer still needs them. It can’t infer. All those loose ends, niggling details and corner cases end up eating a great deal of time… sometimes more than the rest of the program.
How does programming feel to you? What is your experience like?