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.

–How Software Developers Work

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.

–Don’t Wake Up the Programmer

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?

My good friend James works for Planet Moon, and they just finished a cool new iPhone game. It’s called Booty Blocks and it’s very cute. It’s a block stacking puzzle, but with a twist… you can continue to move the blocks after you’ve placed them, including using the iPhone’s tilt sensor to shake the whole stack. Great stuff. Congrats to the team!

This image shows the Google “auto completion” results when typing the phrase “how to”. The idea of auto completion is that the computer will complete the phrase you are most likely searching for based on what other people are searching for. In a round-about way, it tells you a little bit about what other people are thinking… or at least what Google thinks they are thinking! 🙂

Some results, like writing a resume or cooking a turkey, I’d expect given the economy and the season. But others, such as knitting, surprised me. I always find it fascinating to see what the world is pondering.

Brenda Brathwaite recently posted an excellent article on creating a game design doc. Her best advice:

Before you start writing, consider is your audience. Many new designers write documents as if they’re being written for gamers instead of a programmer who’s tired, annoyed and up at 3 a.m. coding your combat system…

So true! Even if you’re just writing implementation notes for yourself, this is an important thing to keep in mind. When there are a lot of complicated rules going on, it’s easy to get bogged down with loose ends when programming the implementation. Unfortunately, this sometimes means important details get overlooked. A careful and detailed list of requirements without a lot of extra hype cluttering it up is invaluable as a checklist when the going gets rough. It will help prevent anything from being missed.

Writing the right amount of detail is a fine art. You need enough detail to make sure everything important is explicitly defined, but not so much that the document becomes so overwhelming that you–or your team–will be tempted to just skim over it when you refer back to it later. Personally, I’m a big fan of writing design docs in html help file format, mainly because most of the editors force you to create drill-down type topics instead of writing the document linearly. Incidentally, many of the editors will also let you save to PDF or other file formats… it’s not the file format that’s important, as much as the concept of writing hierarchically instead of linearly.

Hierarchical format is very helpful when implementing because it allows you to keep track of the big picture with fewer minutiae details in the way while blocking out the architecture, yet you can focus in on the important-yet-tiny things when you implement the specifics. If you have the discipline to do it, keywording individual topics is also immensely valuable as the document grows in size. When programming large systems so many components end up more interrelated than people realize, and good keywords are another tool that help find everything important when you’re coding it up.

The Women in Games International (WIGI) “Celebrity eBay Auction” has started. The auction includes lots of games and game-related books and merchandise, many of the items signed by the developers. Proceeds go to support Women in Games International.

Like many math and science-related fields, only 3% of engineers \ programmers in the game industry are female. Women in Games International’s goal is to help encourage more women to enter the industry.

A couple of interesting items from the list: