The next architecture book you must read

Today, another tweet about “how can I write the cleanest, best architected code?” gets piles of book references in response.

Yes, we want to be good at writing code. We want to write the best code. The best code for what? “Writing code” is an abstraction, like a transitive verb without an object. I can’t just “write code,” I must “write code to….”

The work is software development is not typing, it is making decisions. To make those decisions, we have to understand the details of code and technology, yes. We also have to understand the context and purpose, what we are writing the code to do.

My advice for “What should I read in order to write better code?” is usually, a book or magazine or internal memos about the business. Better is having conversations about the business with the experts inside your company, and to do that well, you need the vocabulary.

We need both the specific technical understanding and the business understanding. It’s so much easier to push for technical understanding. Because the business understanding is specific to each context. I can’t make a wide-audience tweet recommending a book, you have to find that closer-in.

Supplement Twitter with kitchen conversations or internal Slack channels that give you a broader perspective on the purpose of your work in the specific context you work in.

Zooming in and zooming out

Inner coherence vs usefulness

Around 1900, when modernist art was emerging, art historians talked about the significance of art in context: the painting is not complete without the beholder.

Before that, the beholder wasn’t so important. People looked for art to express some universal truth through beauty.

Before cultures and artists considered the role of the beholder, they made art that didn’t need you. The art has inner coherence.

A lot of software development aims for inner coherence. Code that is elegant, that is well-designed and admirable on its own.

I used to like that, too. But now I want to think about code only in context. Software is incomplete without use.

If my code is full of feature flags and deprecated fields for backwards compatibility, that’s a sign that it is used. The history of the software is right there to see. I don’t want to hide that history; I want to make it very clear so that I can work within it.

My job isn’t to change code, it’s to change systems, so that we can adapt and grow increasingly useful instead of obsolete.

This old painting may be beautiful, but it doesn’t affect me the way Gustav Klimt’s work does. (some drawings, NSFW) He was one of the early modernist artists to speak of contextual, rather than universal, truths.

Within our teams, contextual truths have the most power. In my software, it’s a contextual coherence of its larger system that I care about.