A recent discussion on Lobsters asked developers what blog posts influenced their thinking the most. That discussion has inspired me to start keeping track of those posts for myself.

This is a living list of articles which I think about a lot, for one reason or another.

---

“The Configuration Complexity Clock” - Mike Hadlow

Writing a DSL is a devious trick for a software engineer, that I’ve fallen for (or almost fallen for) too many times.

It’s really fun - I’d love to flex my language implementation muscles to solve a real problem! However, it’s often a terrible idea for long-term maintainability.

“Using LLMs at Oxide” - Bryan Cantrill

This RFC pretty much exactly matches my own opinions about LLM usage, while also being much better articulated than I could ever manage.

The section about LLMs as writers particularly resonates with me:

Finally, LLM-generated prose undermines a social contract of sorts: absent LLMs, it is presumed that of the reader and the writer, it is the writer that has undertaken the greater intellectual exertion. (That is, it is more work to write than to read!) For the reader, this is important: should they struggle with an idea, they can reasonably assume that the writer themselves understands it — and it is the least a reader can do to labor to make sense of it.

If, however, prose is LLM-generated, this social contract becomes ripped up: a reader cannot assume that the writer understands their ideas because they might not so much have read the product of the LLM that they tasked to write it.

“Parse, don’t validate” - Alexis King

This article, and even just its name as a concept, get thrown around a lot - and for good reason!

Even in languages which don’t lend themselves quite as nicely to this pattern as Rust or Haskell, it’s still influenced how I think about designing the parts of software which need to deal with potentially-malformed inputs.

“Ratchets in software development” - qntm

Unwritten rules for a codebase are so demoralising for a new team member. This part has really stuck in my mind:

In general, I dislike having bad practice left over in our codebase. This can be difficult to avoid, but is very misleading for newcomers […] “Ah, I see you have diligently followed the example set by your predecessors. Well done, and bad luck. Changes requested.”

We’re lucky that rapid, IDE-integrated, customisable linting is now the norm. I have written ratchets by adding custom lint rules, with exclusions scattered around existing code.

“The Wrong Abstraction” - Sandi Metz

A cautionary tale of building your software for your requirements today, in a way that leaves no scope for your requirements tomorrow.