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).'"
I get a cup of coffee, if that, and I sit my ass down and write some code. I don't go for walks, I don't spend quality time with the wife, I don't sit in the lotus position, I bang out thousands and thousands of lines of solid code. If there's a particularly nasty problem, I go to sleep and the solution shows up in the shower the next morning and then I code. Criminies. I blame "keyboarding" classes, "web design", and "object oriented methodologolologogies" on this sort of hippie chakra-based programming hooey.
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 have to disagree with you there, and I'll submit that you're doing it wrong if you're not visualizing what you're coding.
I'm a highly visual person, and as a result I'm really good at simplifying complex spaghetti written by people like you who can't see the obvious simple(r) solution.
If you can't visualize it, draw it on a white board. Remove any cyclic dependencies and minimize the number of connections. Visualize. Visualize. Visualize. Then code.
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."
Me too. Sometimes it takes weeks, and I might have to go Cabo or Belize or party with some hookers and blow, but that's how dedicated I am to making sure I get the job done right.
More seriously: It sounds like he and I have very different working methods, and I wonder how much of it is due to the subject matter. I use something more akin to a sketch, examine, and revise methodology. The sketches can be drawings, UML, Venn diagrams, mock-ups, or illustrations*, but eventually some of the sketches are functioning rough implementations. This is perhaps because much of my work is user-oriented rather than simply data-oriented, but I sometimes find it useful for the more complex data-oriented code. The code sketches are usually revised into the next version of a sketch, and eventually become the actual code you want to ship. Obviously that methodology could be very problematic in a group environment with a lot of overlap, but there are different ways to adapt it.
One thing I absolutely dread are those design meetings where people spend hours trying to decide amongst two technologies or models that are both clearly imperfect in the same magnitude. You go over it and over it and over it until everyone is worn through, and the eventual choice isn't based on merits but simply the chance events of the meeting.
* I've found two minutes at a sketch book can sometimes clarify the necessary algorithm for me in a way that could take an hour of pain at the computer. I definitely recommend trying approaching problems from multiple disparate modes of thought.
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'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.
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 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!