The motivation
Though their approaches and literary outputs were distinct in style and scope, Robert Heinlein (1907–1988) and Harlan Ellison (1934–2018) were two of the most influential writers in the science fiction genre.
Heinlein’s works were expansive in scope, producing over 30 novels, numerous short stories, and essays. Ellison wrote over 1700 works, like the iconic short story “I Have No Mouth, and I Must Scream” on 1967.
Ellison’s productivity was staggering in terms of shorter works, but he did not produce as many long novels as Heinlein. Instead, he focused on high-impact, tight stories.
In Argentina, Alberto Laiseca (1941–2016), known for his magnum opus, “Los Sorias”, a sprawling 1300-page novel that combined elements of history and fantasy to construct a parallel reality, demonstrated a similar drive for proficiency.
We could thus say that proficiency is likely to produce greatness.
Let’s summarize their approaches: all of them achieved a combination of mastery in their craft, an ability to articulate complex ideas, and a consistency with which they delivered their work.
This leads us to Heinlein’s “Five Rules for Writers”.
They were first published in 1947 as part of his essay “On the Writing of Speculative Fiction”, reflecting a practical, no-nonsense approach to writing.
Could we apply those rules to programming?
Rules for Writers
The rules are as follows:
Rule One: You must write.
Rule Two: You must finish what you start.
Rule Three: You must refrain from rewriting, except to editorial order.
Rule Four: You must put it on the market.
Rule Five: You must keep it on the market until it has sold.
Inspired by James Scott Bell’s article, I’d like to offer my commentary on this list too.
Rules for Programmers
Rule One: You must write.
This seems self-evident. Yet, how many of us find ourselves get caught in useless research, tutorial-watching, or worse, procrastination?
Now, THINKING ABOUT coding is not coding. WRITING ABOUT coding is not coding. “Getting Ready” to code is not coding. RESEARCHING is not coding.
Coding is putting new instructions on the file. Period. All that other stuff is your conscious mind talking you into thinking you’re coding.
As James Bell explains, writers from Heinlein’s era set strict quotas for themselves because they earned about twenty cents for each word they wrote if we adjust for inflation. They didn’t have the luxury of writer’s block and we neither, because:
you can’t sell what you don’t produce.
Rule Two: You must finish what you start.
Heinlein was primarily thinking about short stories, something akin to an advanced and mechanically complex component. Something that not just everybody could make, but manageble by a single senior or semi-senior programmer in a short span of days, over pressure.
If you don’t identify yourself as senior or semi-senior, this doesn’t mean that everything that you could make could be made better by someone else. Ideally, pick a stack and stick to it. Find a niche.
Whatever your situation is, push through no matter what.
Most often, the most common but unspoken reason we don’t finish something is fear. If we finish something, we might have to show it off and risk rejection, ridicule and dissapointment. The desire to create is cancelled by the fear of bad performance.
There will always be moments when we think our code is subpar, when we wonder if we should scrap everything and start anew. Fight through it. Complete your project. The act of finishing makes you stronger.
Rule Three: You must refrain from overengineering, except to editorial order.
Rewriting is going back to what yourself wrote, in the search of perfection and perfect is the enemy of done: a better adjetive, a better verb, a better noun. But rewriting for a professional writer like them woudn’t be akin to refactoring to us, but to the tendency we have to plan for future features, unnecessary abstractions, and overoptimization.
As Bell points out, for “editorial order”, Heinlein meant that once his product sold, he would make the changes the editor wanted. That editor would be the person that’s commending your work and as an example, an issue from a non-substantial paying supporter is not an editor.
Rule Four: You must put it on the market.
Sending the story out to a prospective publisher is the equivalent of making it known to a potential customer.
Cold sales are not the best strategy, altough a necessary one, so you must work on your networking skills.
Rule Five: You must keep it on the market until it has sold.
What if the prospect doesn’t like it? What do you do then? You write the next piece of code and send it off. That’s what you do.
As Bell says,
When a manuscript came back, rejected, you just got another envelope and sent it out again
There is no much to it. Just keep going.
Conclusion
In conclusion, these rules don’t need much adaptation for us as code writers. Our components tell a story, our algorithms are the script of the actors, our UI is our scenario, and so forth.
So, send me your short-story or your “Los Sorias” when you finish it. I want to read it.