Latest news about Bitcoin and all cryptocurrencies. Your daily crypto news habit.
Science fiction writer William Gibson, author of the 1984 cyberpunk classic Neuromancer describes a very interesting writing style in a 2011 interview with The Paris Review.
He says, âEvery day, when I sit down with the manuscript, I start at page one and go through the whole thing, revising freely.â
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
How the Godfather of Cyberpunk would write software was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.
Disclaimer
The views and opinions expressed in this article are solely those of the authors and do not reflect the views of Bitcoin Insider. Every investment and trading move involves risk - this is especially true for cryptocurrencies given their volatility. We strongly advise our readers to conduct their own research when making a decision.