How the Godfather of Cyberpunk would write software
Science fiction writer William Gibson, author of the 1984 cyberpunk classic Neuromancer describes his interesting writing style in a 2011 interview with The Paris Review.
You read that right.
He begins each day by reading the whole manuscript again.
In the beginning, while the book is short, re-reading may only take a few minutes. Along the way he makes corrections and edits liberally.
As you might expect, by the middle of the project he’s spending 1–2 hours each day re-reading what he’s already written. Toward the end of the book, the re-reading may take 4–5 hours (or longer!).
This has some interesting effects:
1.The first half of the book receives far more editing than the last half.
2.As the amount of reading per day increases, the amount of writing decreases.
3.He has less plot re-work, because reading keeps the context in the forefront of in his mind for writing.
When I read this, I was surprised. Not only am I a fan of his work but, as an aspiring writer, I find the way writers write very interesting. I’ve not heard of other writers doing it this way, although my sample size is certainly limited.
I didn’t realize there was so much reading in writing.
I see parallels between writing a book and writing software, and I see some interesting ideas in Mr. Gibson’s approach. Maybe there’s something we can apply to software development.
What if we began each day by re-reading all the code we’d written for the story/feature/bug we were working on?
That may reduce problems such as:
- Hanging threads of thought, which may wake us up at 2am in a cold sweat
- Errors introduced due to the problem of forgetting the of context in our work
- Logic problems introduced because we forgot the details of yesterdays work
- Partially implemented features, because we forgot where we left off, and picked up somewhere else
- Spotty unit test coverage, because we forgot to finish where we left off
I’ve suffered from all of these problems, and have seen them on my team. For example, have you ever seen an IF statement that is missing an obvious ELSE clause? Or code which declares a variable, assigns it from a calculation, yet fails to do anything with it? Or, functions which that never get called?
These types of problems are common in software. And they stem from forgetting. That’s where re-reading comes in. In fiction terms, maybe these are considered plot problems. Or, loose ends. But in software, these bugs often result in errors.
Humans are forgetting machines
Computers are good at “remembering”, but humans are good at forgetting. Or, maybe more accurately, remembering incorrectly. (In fact, there’s an entire Wikipedia article on memory biases!) Unsurprisingly, we’re particularly good at forgetting that we forget. Which means we might believe we’re good at remembering, even when we’re not.
We might also believe that creating software means writing code, not reading code. Somewhere, our profession adopted the idea that reading code is the work of OtherPeople(TM), not programmers. This could be Quality Assurance, Architects (code-reviews) or Consultants (code audits.)
We might believe that there should be very little reading involved in our code writing, because re-reading seems ridiculous and wasteful. And as software engineers, we could never be either of those things, so we may have decided that we’ll leave the reading to someone else.
As I look back on my career, many good things have come from reading code, such as:
- Identifying the source of a bug
- Speeding up a query
- Understanding someone’s design
- Identifying how to extend an existing system
- Learning a new system
In fact, all the hard problems I worked through required a tremendous amount of reading and re-reading.
I have spent countless hours searching for bugs which would have been caught by carefully re-reading the code (such as a semi-colon at the end of a for() statement, and other C joys!)
Maybe the most common place we read code is when approaching a new system, but even then we might only skim file names, class names or function names. Skimming is a kind of reading, but it’s often fooled me into believing I know more than I do. But that’s another problem, for another day.
Every day our brain reboots
Every day we get a type of bio-reboot when we sleep. It’s a blessing to forget the troubles of yesterday, because today has enough for itself. In a way, each day we approach a project we are approaching a “new system”, because we’ve forgotten a great deal about it in our slumber.
When asked why he re-reads every day, Mr. Gibson replies, “It would be really frustrating for me not to be able to do that. I would feel as though I were flying blind.”
And that’s often our problem. We’re flying blind, but we don’t realize it.
Questions for the reader
1.When are you most likely to re-read your code?
2.What do you feel is the optimum code reading:writing ratio (CR:WR)?
3.Do you see errors that would have been caught earlier if someone had re-read their work?
4.What might be standing in your way of spending time reading code?
I’d love to hear from you about this, so drop me a line with your thoughts on code reading at marcus@marcusblankenship.com
