Ho! Simpler Machines subscribers!

This letter is late for a few reasons but one of them is that for the past few weeks I've been doing some honest-to-god consulting. Reading code, taking notes, answering questions.

I don't get this opportunity very often – to just sit with one of these things, this thing that we build called a "software system." Look at it, think about it. To think about the design choices from an outsider's perspective, without the guidance or bias of the people who built the thing. Pure archaeology.

Normal software work is so much about changing the system. Add capabilities. Change behavior. Imagine what could be or should be. Understanding what is – always a byproduct or a precondition of change.


The code has layers. Someone thought about those layers a lot – it's a well-thought out, structured design.

Then there are other places – not many, but it's a young code-base – where someone else has come along and put some behavior where it's convenient, the necessary dependencies easily at hand – and not where the laid-out pattern says it should go.


Here's a problem that I have with everything (?) I've ever read about software design: It's written for one person, designing software on their own.

It's not their fault. This is the nature of books, and the audience for the advice – the solo reader.

But the solo reader, working alone, making design decisions on their own – the solo reader doesn't make much software.


My formal, academic training is mostly in writing. Literature. It's different from software – and it isn't.

Books and essays are mostly made by individuals. A handful of people, if you count editors. Advice to an individual about the design of a novel – actionable.

But writers spend tremendously more time than software developers reading, and reading things that are similar to what they write. Poets read poetry. Screenwriters read screenplays.

Software developers? We don't read. We don't read software. We certainly don't read the kind of software we actually make. Maybe, occasionally, we read about software, software we wished we made.


Have you ever spent at least a few days doing nothing but reading code? Why? When? What did you learn?

I don't really have a point here, not even "you should read more code." There's the beginning of some more developed thoughts about design, maybe, but– well, this is already late, and the dog needs his noon walk, and I need an egg sandwich and to get caught up on my e-mail.

More soon.

- Nat

Reading software and thinking about it

Normal software work is so much about changing the system. Add capabilities. Change behavior. Imagine what could be or should be. Understanding what is – always a byproduct or a precondition of change.