How I took off the cowboy hat and stepped away from the keyboard.
Before I ever studied programming, I was making a living as a programmer for hire.
I thought I was pretty good. I was a Clint Eastwood coder. I’d ride in, solve the client’s problem, collect my fistful of dollars, and ride out, never looking back. Maintenance was for settlers. I worked alone and I rarely commented. Clint Eastwood starred in spaghetti westerns; I wrote spaghetti code.
Then I started taking classes and learned that I didn’t know anything about writing code.
From Dan Friedman in Indiana University’s Comp Sci Master’s program, I learned Lisp and two principles.
First principle: Any function can—and should—be defined in five lines or less. Three lines if possible, often four, five only in special cases.
Second principle: Solve the problem with 3-5 lines of code that would execute if certain help functions existed. Write those help functions using other help functions whose existence then becomes desirable. Recurse.
I doubt that either of these is exactly what Dan was trying to teach us. The second principle looks like my misinterpretation of Wirth: “The creative activity of programming... is here considered as a sequence of design decisions concerning the decomposition of tasks into subtasks and of data into data structures.... In each step, one or several instructions of the given program are decomposed into more detailed instructions. This successive decomposition or refinement of specifications terminates when all instructions are expressed in terms of an underlying computer or programming language....” [“Program Development by Stepwise Refinement,” Niklaus Wirth, Communications of the ACM, April, 1971.]
Anyway, I had principles. I had structure. I would never again write spaghetti code, because now I really knew how to write code.
Taking Off the Cowboy Hat
Back then, when I was a computer science student, none of us had computers. I realize that this is hard for some of you reading this to wrap your minds around, but just tell yourself, this was the Old West. It was actually Bloomington, Indiana, but back then we were all in virtual Dodge City.
Now don’t paint me as even older than I am. We weren’t handing in decks of punched cards to a white-coated operator. Heck no, that was the year before. And what we’d have been doing if we were mere students rather than privileged Comp Sci grad students. No, we had accounts on the university mainframe and access to terminals in public computer rooms. I was living off campus and didn’t have a car, so I batched up my work, and scheduled long sessions for myself on the terminals.
For a class with Mitch Wand, or maybe it was Gene Freuder, I decided to write a Lisp program to play five-card draw poker. Or maybe it was a different problem. And maybe I wrote it in Prolog. It was a long time ago, and I’m a little fuzzy on the details. I do remember that I set up a TV tray in front of my comfy chair in my off-campus apartment, got my first of many cups of coffee and a pen and a fresh new yellow pad, and started writing.
I wrote a top-level solution to the problem in five lines of Lisp—or possibly Prolog—and went on from there. I tackled the problem with my newly-embraced principles of five-line functions and stepwise refinement. I grew a mighty tree of desirable help functions in good clean four-to-five-line chunks of Lisp (or Prolog), not stopping until every leaf of the tree was “expressed in terms of an underlying computer or programming language.” It was a thing of beauty.
And it remained a thing of beauty until I got on my bike and pedaled in to campus and sat down at a terminal and started keying it in and debugging it.
Then it became a total disaster.
And it remained a total disaster right up to and past the deadline for turning in the assignment. Mitch chastised me severely. To have so much written and so little tested showed a fundamental misunderstanding of software development practice, Mitch said. Or possibly Gene.
Anyway, that’s how I became educated in the necessity of testing code as you go. Finally, now I knew how to write code.
Stepping Away from the Keyboard
More years would pass before I learned that I still didn’t know how to write code, and that it might actually make sense to write the test even before writing the code.
I share these embarrassing experiences from my early days as a programmer as a preface to saying something really obvious: It’s still useful to code offline.
Granted, programming has changed since those long-ago days. Today the tools and techniques we have for testing and debugging make it silly to think of making the bonehead mistakes I made back then. And when the typical programming project is made up of many pieces complexly combined, the idea that you might go off and write an entire program with pen and paper seems quaint.
But it’s not hard to think of reasons to work on paper for a while. I’m suggesting something more specific. Because I needed to find a way of referring to this tool that I find so useful, I call it the rhythm of focus.
It’s something that I use regularly in writing prose, and it’s one of the tricks that allowed me to finish a 50,000-word novel (well, draft of a novel) in 30 days in November. It’s really simple: when I find myself staring at the screen and no longer making progress, I print out the current chunk of writing and go somewhere else and hack away at it with a pen. This never fails to get me past the current difficulty. I see the work with a fresh perspective and I see a way of approaching my difficulty. I don’t necessarily solve any major problems in this way, but it gets my wheels out of the ditch. Every time.
And then I go back online, starting in gently with the mindless task of keying in the changes I made offline. At this point I’m ready to work online again. In a longer piece of writing, this back-and-forth becomes a steady rhythm that keeps me moving forward. For the novel, I worked offline in the house in the evening and online in the office in the morning, every day. And in this way, I wrote an average of 1667 words a day for 30 days. It’s not just a matter of getting a different perspective on the work, although it is that. It’s also about getting in touch with the rhythm of your own attention. I call it the rhythm of focus, and I know from experience that it works for writing prose.
Does it work for writing code? In my limited experience, yes. As a programmer, I'm still a cowboy, though I hope not of the spaghetti code variety. I write chiefly for myself. And all I can say is that this is exactly how I worked on the most recent program I wrote, a cryptogram generator that I used for this magazine and for a staff party. It worked for me. It might work for you.
Michael Swaine is the editor of PragPub.