Why Programming Rituals Work
narramissic writes "Programmers may not think that their rituals are unusual, but if you swear that your code is less buggy if you recite it aloud or you prepare for coding by listening to certain music, don't be surprised if you get a couple sideways glances. In a recent ITworld article, Issac Kelly, Lead Developer at Servee.com, explains his routine and why it works: 'To me, programming is really the 'last mile' to getting something done. When I do the planning and specifications, I go on lots of walks, take lots of time with my wife, and really do as little work in front of the computer as possible. The more I plan (in my head, on paper, on a whiteboard) the less I program; and all of my rituals are to that end.' His ritual goes like this: 'Before sitting down to a coding session, he gets a big glass of water, takes everything off of his desk, and closes out all programs and e-mail, keeping open only his code editor. The office door is shut, and some sort of music is playing ('typically an instrumental only, like my 'Explosions in the Sky' pandora station,' says Kelly).'"
Before I undertake any task I do absolutely nothing. For about a day I will just idle around thinking about the problem. Kicking around one solution and another.... And I keep doing this until I am happy...
"You can't make a race horse of a pig"
"No," said Samuel, "but you can make very fast pig"
The key to good software is contemplation. You can feel the social pressure at the workplace to be typing all the time, but it's wrong to give in. If they want someone who's banging on his keyboard all the time, let them hire a typist.
"It's too bad that stupidity isn't painful." - Anton LaVey
Sure, some of what the article talks about is a ritual, but the planning process isn't a ritual at all. Its a process. One that usually works pretty well, I must add. The less time you spend coding, the better your product is usually going to be. That said, knowing when to put down the whiteboard is sometimes important too.
I can fully understand using such rituals. It helps you get in the right head space for writing code. It gets you focused on the task and flush out all the other crap trying to get your attention.
I have found that if I am not in the right frame of mind before starting, the code takes much longer or is just plain wrong. If I am in the right head space, the task is quick and done before you know it.
"Trademarks are the heraldry of the new feudalism."
I think the problem with planning everything too much is that you can't hold all the details in your mind at once, and sometimes your planned approach is not as good as one you come up with later given some time to stew on it (doing nothing).
I think programming is a very iterative process because it is symbolic and non-visual (i.e. not like building something with structures that are easily and intuitively able to grasp their structural and interconnected relationsihps)
I write firmware for a living, and I WISH I had a door to close. Nothing is more annoying or infuriating on my job than when coworkers are loudly shooting the bull while I'm trying to read a datasheet and figure out register settings.
"S.. TF.. U!"
I can code with some noise in the room, but I need QUIET when I'm reading a tech spec. I wish I had the ability to mask external stimuli.
sig: sauer
I think the biggest problem with programming is the number of programmers involved and the size of the project. It's really the testing group/QA departments job to catch the bugs. I listen to music while i work, granted I install network hardware, but it makes the day go by faster and seems to be more productive than listening to the phone ring or staring at the wall for hours on end. I think that programmers are given too much crap. They may make coding errors, but they are human. Another set of eyes on any project makes things a bit easier. As much as I hate OpenBSD, they have a descent system. They take code, review it, and then post it to their distro. It may take them forever to get to that point, but at least its reviewed. Programs would be so much better if there was a better source. I'm sure this is offtopic so yeah....I forgot where i was going with this, its quiet in the office.
You can run just as hard and fast as you like. Doesn't do you much good if it's in the wrong direction.
Deleted
Hell is other peoples code.
Funny, isn't it, how the more one earns, the less "work" that person must do? However, it is often the case in the software world, that while one must perform less labor, the output of that labor is expected to be of greater practical value. Quality vs quantity I suppose.
When you can prevent useless distractions, then you're really ready to go. Of course, I'm posting this on /., which shows me to be something of a hypocrite, but I think the point still a useful one.
I agree, my first though when I read this was "what a ponce". We would all like more time, more flexibility and more peace and quiet, but transfer this guy's approach to say a Paramedic. There you are lying at the side of the road bleeding to death and the paramedic can't decide whay to do with out a whole heap of rituals. Planning, to a point, is obviously a good thing, but if you are a professional coder, cutting code is something you have done so often that you know the patterns, like the paramedic, you should be able to quickly assess the situation and apply the right techniques in the right way.
Art is the mathematics of emotion
I've worked in software development for going on 15 years. I've never found an employer who realized giving developers rooms to themselves and a door would improve productivity. :P