Phil Karlton once said, “there are only two hard things in Computer Science: cache invalidation and naming things.”
I don’t remember where I first read this but it stuck with me over the years. I’ve been working on cache invalidation this week — and let me tell you, it’s no joke! But I found one of the hardest things about cache invalidation, as with every other programming challenge, has been breaking it down into small, well-named concepts and components that are easy to comprehend.
Phil’s joke works because it’s shocking — cache invalidation is incredibly technical whereas, on the face of it, naming things doesn’t seem like it should be that hard. Yet it remains a constant challenge and one of the most important skills you can develop as a programmer.
It’s not just coming up with names but knowing how to spot the nameless vacuums around you. Take this method signature for example:
send_letter(street:, city:, state:, post_code:, country:, when:)
There’s a concept here just waiting to be extracted and named. If we define an Address as a Struct of street, city, state, post_code and country:
Address = Struct.new(
:street,
:city,
:state,
:post_code,
:country
)
…then our method can be rewritten like as:
send_letter(to: address, when:)
The new method is functionally identical but conceptually very different to the one before. Naming the address concept compresses it in our minds such that it requires less effort to comprehend. Everyone who reads this signature knows what an address is and they can discover the technical definition of Address if and when they need to know by looking at the struct. By naming it, we’ve compressed five concepts into one.
We often talk about “object allocation” when optimising software performance but I think it’s equally important to consider concept allocation — how many concepts does the reader need to grasp in order to comprehend this code? Better, faster code comprehension is a valuable type of performance in itself.
Naming things is the soul and essence of abstraction and our main objective as software writers: taking something complex and giving it a simple, descriptive name or interface. Naming things well is our best chance at understanding and sharing the software we write.
That’s why Naming Things is the name of a new show I’m co-hosting with Kasper. Every week, we’ll be sharing a mostly un-edited screen recording of a pair-programming session on Tuple. We could be tracking down a bug in an open source library, digging into a tricky domain modelling problem, going on a meta programming adventure or maybe something more abstract.
I hope this new show will help you discover new approaches, systems and ways of thinking about software. Some concepts are best absorbed through osmosis.
I’ve paired on software with a lot of people — some more experienced than me, some less — but I’ve always come away with a valuable lesson or insight in addition to the code we wrote together. I hope you can share in that experience by watching us solve novel problems each week. Hope to see you there!