7 Lessons for Software Developers from Heinlein

Robert Heinlein wasn't really a programmer, of course. But in his writing career he said or wrote several things (in his own voice or that of a fictional character) that can help any software developer improve her code... or her career.

For instance, one Heinlein comment that has a prominent place in my Quotes file (and I used often back when e-mail .sig files were common) is, "They didn't want it good, they wanted it Wednesday." Heinlein unquestionably understood (and was frustrated by) the deadlines his editors demanded. I can't for the life of me remember where I read about Heinlein's annoyances with the editors, particularly with regard to his "juveniles," but their (to-him) unreasonable requirements were part of what chased him away from that market.

The point is, though: Deadlines are real. They are incredibly annoying to anyone who has a creative spirit, but (speaking as a longtime editor here) sometimes the issue is less about getting a project done perfectly than it is about getting it done on time. Then again, as any manager knows, one must wrest a creation from its creator because, left to that creator, it will never be considered done. "Art is never finished, only abandoned," admitted Leonardo da Vinci, and the people who have the silly idea that a creator should deliver on a schedule have been cranky every since.

If you have a boss or a business client who understands that "good" ought to trump "delivered on time" (particularly when it's an arbitrary and capricious deadline), appreciate her.

"The most important lesson in the writing trade is that any manuscript is improved if you cut away the fat." This quote, which I found in Advice to Writers: A Compendium of Quotes, Anecdotes, and Writerly Wisdom from a Dazzling Array of Literary Lights, probably doesn't need much explanation to software developers, or at least I hope it doesn't. Elegant works of creation (whether software or stories) are almost never cluttered. The first draft is only a first draft — and it should never been confused with a finished piece. It isn't done until it's re-done, and that usually means turned into something that's more concise. Nowadays we'd use terms like "refactoring," but I have an old quote from Grady Booch in which he said, "The task of the software development team is to engineer the illusion of simplicity." That usually includes "cutting away the fat," no?

Here's one Heinlein (character) sentiment that I agree with and disagree with: "A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a well, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects."—Lazarus Long, in Time Enough for Love. I've spent most of my career trying to find a balance between "specialist" (deep but narrow knowledge) and "generalist" (knowing something about everything, but nothing about everything); I suspect you've struggled with that, too. When I first became a computer consultant, I had a long argument with a friend about the subject. Paul's view was that it was important to be considered the #1 expert in at least one category (his was accounting software, at least in the Columbus, Ohio region), because people want to hire the expert. I came to agree with Paul that it's easiest to build a career as a specialist. Yet it's easy to know everything about left-handed widgets and nothing about the right-handed variety, or about anything else, for that matter. That's a particular danger when the market for left-handed widgets goes away (as I learned painfully after becoming one of "the" experts on IBM's OS/2 operating system). So I agree with Heinlein about the importance of self-sufficiency... and I also disagree with him. The Heinlein quote helps me keep myself in balance.

I tend to write a lot about making programming teams successful, as you may have noticed (when I'm not writing about things like 10 Business Lessons I Learned from Playing Dungeons & Dragons). And one premise which I accepted long ago was the advice given to the teenage Podkayne by her uncle, "Politics is good even when it is bad... because the only alternative is force—and somebody gets hurt," in Podkayne of Mars. As much as we all hate "office politics," Heinlein (speaking through the uncle) is right when he says, "Politics is not evil; politics is the human race's most magnificent achievement. ... Politics is just a name for the way we get things done without fighting." I try to keep this in mind during serious team hissing-and-spitting. Not always successfully.

One attribute of Heinlein's personal philosophy with which I can wholeheartedly agree (even during the aforementioned hissing and spitting) is the importance of opinion diversity in a team. My father taught me, "When two business partners agree all the time, one of them is unnecessary" and I have always believed it's among my duties to question authority. (My father appreciated that attitude less when I reached my own teen years and it was his premises I challenged.) Certainly, you've seen me write rather often about the necessity of being wrong in order to achieve a higher degree of wisdom. This viewpoint has a distinct influence from Heinlein, who said both that A society that gets rid of all its troublemakers goes downhill (a viewpoint I touched upon in my other blog last week, The Decline and Fall of the Idealistic Spark) and I never learned from a man who agreed with me.

Sometimes, I learned from Heinlein indirectly. One such lesson is: Your initial work is rarely your best; give yourself permission to fail, as long as you learn from the failure. This isn't a Heinlein quote, per se, but my own observation after reading his first-written novel, For Us, The Living: A Comedy of Customs, which was released several years after his death. He couldn't get the book published in the early 1930s when he first wrote it (for reasons that are obvious to a modern reader). Yet it's obvious that he used it as the source of many other story ideas. In fact, that was one of the many weaknesses of that first novel: It tried to do too much. (Does your software?)

On the other hand, the not-so-hotness of For Us, the Living should encourage you that even if you aren't a great programmer today, with dedication to your craft (and a willingness to write a lot of code), you could become one. Heinlein wrote For Us, the Living two years before he submitted "Lifeline" (his first short story) to a magazine; two years after that (according to Spider Robinson's book introduction), Heinlein was guest of honor at the Denver SF WorldCon. This novel demonstrates how much even a master has to learn — and what's really astonishing is how fast Heinlein learned it. (Four years from this to the WorldCon?!)

That's some of the things I learned from Heinlein. (And perhaps I inspired you to do a little more SF reading.) What did he write that influenced you?

You probably should follow me on Twitter. Because, y'know, you just should.

This story, "7 Lessons for Software Developers from Heinlein " was originally published by JavaWorld.


Copyright © 2009 IDG Communications, Inc.