Slashdot Mirror
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"
There's Slashdot. Even when I do everything else, Slashdot is the final work-preventer.
Fascism trolls keeping me up every night. When I starts a preachin', he HITS ME WITH HIS REICH!
1. Make a cup of coffee: Community New Orleans blend, one sugar, hazelnut creamer.
2. Read reddit.
3. Check social status sites: facebook, twitter, etc.
4. Read CNN.
5. Read email.
6. Catch up with coworkers.
7. Juggle a bit.
8. Put on headphones. Go to last.fm and hunt for a station that fits my current mood.
9. Check reddit again.
10. Go to lunch.
11. Read email.
12. Check reddit again.
13. Update to-do list.
14. Check icanhazcheezburger, etc.
15. Pick different last.fm station.
...when I make sure to release it when most of the testing group is on vacation. Vastly cuts down on the initial bug list, let me tell you.
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)
Crikey! That's just sensible work organisation. I guess if you find something that works and always do it that way you might call it a ritual. My ritual is to get in the car and go to work every morning... that way I can do, well you know... WORK!
Here's a couple of long out-of-fashion words; contemplation and reflection.
There is no "process" -- not change requests, not planning documents, not maintenance windows, not design documents, and for damn sure no flavor-of-the-month buzzword -- that can replace someone with a brain thinking the problem through.
The problem with this is that it exposes the MBAs for the empty suits they are. Our "business team" -- salesmen with glorified titles -- sit through every meeting bloviating while the engineers get it done. The PMP certs are the worst about it. Me and a customer engineer will put our heads together about something, and decide on a course of action. The PMPs will jump all over it and send out emails about "deliverable actions items."
One of the other engineers will mention something, and we'll realize we should take a different approach. While we're getting real work done, the PMPs will barge in demanding to know if that action items has been deliverabled yet, and if not we need to reprioritize our skill sets.
I used to try to explain it to them. We were going to do that, but then we found out this, so were doing something different. I kept getting haughty responses about how they didn't need to know the little tech stuff, they were just managing the project.
One of them went on at huge length about how you didn't have to be a doctor to be a chief of staff at a hospital.
At that point I just began to feel sorry for him. Can you imagine living your life hoping and praying that no one will ever realize that you don't have the first clue about what you're talking about?
He put his boots up on the table and made a face. "The sig," he smirked. "You can waste your life in search of the sig."
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
he gets a big glass of water, takes everything off
I stopped reading right there.
My ritual consists of watching this and then killing a goat
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
My only ritual is that if I find a bug or a problem that I can't resolve in less than 5 minutes I take a few hours off. After a while I get back to it and am usually able to resolve it without much trouble.
I would like to know how complex of a system you are designing with this methodology. No flow planning? No predefined input/output? No figuring out how your design will efficiently fulfill software requirements? Planning isn't all about rituals, though it's well known that doing something to focus your thoughts helps get the juices flowing. Planning is about figuring out how to not waste your time or money, and being able to effectively divide out work if deadlines are pressing in.
I see the glass as full with a FoS of 2.
Hell is other peoples code.
This explains why Australians cannot write decent Java code, they can't find a virgin.
It's magic.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
I'm developing a course for aspiring computer programmers. I've been at it on and off for the past year. The reading list is done, the course outline and coverage isn't entirely done but is shaping up. This sounds like material that should be covered. Does anyone have a good writeup or recommended book for inclusion in the course? The Programmers Stone guys sort of cover this material.
You can see the course here:
From Beginner to Master A Computer Programmer's Reading Course So, you want to be a computer programmer?
It isn't true unless it makes you laugh, but you don't understand it until it makes you weep.
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'm serious. I find that I solve many of my hardest problems in the shower. Now that I telecommute 100% of the time I'll often just take one, say in the middle of the afternoon, to jump start the solution!
Obviously the shower has nothing to do with the situation, it is the "stepping back" that is important, so find something that works for you, and do it.
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 prefer to work with intuitive models. My "ritual" is as follows:
1. Ponder the problem. Not too hard. Just get a feel for how to solve it.
2. Prototype a solution in some readable language (python?).
3a. If the prototype is horribly broken, scrap it and go back to step 2.
3b. Otherwise, create final solution from lessons learned from prototyping.
A lot of people draw diagrams and flow charts and stuff. But that is stupid and too abstracted from the computer to be all that useful. By making a prototype, you're effectively making an interactive diagram/flowchart. It takes about the same time, and any problems will be immediately obvious.
GAAH! MY PRINTER IS ON FIRE!!! PUT IT OUT! PUT IT OUT!
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