Hackers, Legible Code, Typing, and the Zone
I’m currently reading Paul Graham’s “Hackers & Painters” and I’m enjoying it a lot. What he has to say about hacking, and being a hacker, is like he’s “strumming my pain with his fingers; telling my life with his words.”
In the second chapter I already discovered a quote I agree wholeheartedly with, and which gave me a warm feeling reading it: “Programs should be written for people to read, and only incidentally for machines to execute.” (Harold and Sussmann, 1985). I can still vividly recall my horror when, in a conversation about a particularly hideous and convoluted piece of code he had thrown together, a colleague seriously told me “But of course performance is more important than comprehensibility!” — and he obviously really believed that. No, it is not! Never, ever, under any circumstances, is performance more important than comprehensibility (corollary: This applies to code that is to be used more than once or that is to be developed by more than one person — and this pretty much covers all of the coding we do every day.) If they ever make a Simpson’s episode about coding, Bart should be writing the above quote on the blackboard in the opening sequence.
What I don’t agree with, though, is what Paul has to say about untyped programming languages. Yes, coding is a lot like sketching. You have an idea and run with it, fleshing it out as you go along. You concentrate on those parts where inspiration hits you, leaving out some of the details for the clean-up work. I find that when I’m hacking, I have a picture of what it is I want to build already in my head. I have a “feeling” of how I want the cogs and wheels of the software to work together — even if some of the details are still a bit hazy. For me, using types and declarations in coding is a vital ingredient in doing this. After writing “public FooBatz adjustArklVort(Gorpl someGorpl)” I can just plough ahead. I don’t have to remember what I wanted this method to look like. I know — and, in case I forgot, I can easily check — that it’ll return a FooBatz whenever I give it a Gorpl. This allows me to come back to an implementation I’ve been working on and quickly get up to speed, because I know which parts of the implementation I can rely on. No matter at which point in time I decide to implement adjustArklVort, I know I can rely on all the other stuff I’ve based on it to work, because I’m not suddenly going to decide to return something completely different.
Oh, and when I *do* change my mind, of course an IDE with brilliant refactoring support really helps.
Paul mentions another habit, which I also have. When working on something, I use a bug-tracking system (even for myself) and at the end of the day I tend to always leave a couple of the more trivial bugs or problems to fix in the next session. Coming back to these the next day and then fixing them is a great way to get back into the “zone” of creative hacking. Even if it’s just a small layout or wording thing — starting off the day with a few successfullly closed bugs is a good way of tricking yourself into a positive, creative and productive “flow”. Try it.
Technorati Tags: Software Engineering, Hackers, Programming
Bookmark on del.icio.us
Add this post to digg.com
Bookmark on reddit.com
May 28th, 2006 at 4:15 pm
[…] Anyway, I finally managed to finish Paul Graham’s “Hackers and Painters“. After really enjoying the first two or three chapters (see my previous post), I found finishing this book quite a chore and on the whole found it quite a let-down. At the end, I’m not sure what I’ve learned. Except that Paul enjoys LISP. That’s what I found the most painful and booooooringgggg: Advanced LISP fanboy-hood (is that a word? If not, I’ve got copyright). […]
July 7th, 2007 at 4:56 pm
Hello Daniel,
I’m doing research for an article I am writing for CodeProject and possibly other software development websites. The article is titled “Writing Legible Code”.
I came across your blog while researching ideas and references and would like to quote you and, of course, reference your blog as said reference. What I would like to reference is your quote about your colleague because I think it embodies the type of mentality I am trying to rebut in my article. (very funny by the way). The other strong point is writing code for humans vs. machines.
I’ve been writing the article for about a week or so now. Not so much because it’s time consuming but to analyze my own code writing and add to the article ideas that come through my practice. I take it for granted (rarely anymore) that people write code for people not machines.
If you have the time or inclination I would be willing to submit the content of the article to you for review. All ideas are welcome.
The purpose of the article is to make developers aware that they can utilize the tools provided to create code that reads like a book. Even someone without software development skills should be able to be given a printout of a small method and be able to, through common sense, give you an idea of what the code is supposed to do.
Great blog and article.
Thanks,
Dave Jellison