[Oldletter #13] Complexity has to live somewhere, Developer marketing doesn't exist and First principles

Every Friday, I’m sharing a short list of evergreen articles/resources broadly related to software engineering that wouldn’t typically get shared in most tech newsletters or social media feeds.

---

This week’s links

• Complexity Has to Live Somewhere (2020) by Fred Hebert. As software engineers, we’re often striving to simplify things and reduce or eliminate complexity. But in doing so, we can inadvertently create complexities elsewhere.

  Focusing on simplicity is fraught with peril because complexity can’t be removed: it can just be shifted around. If you move it out of your code, where does it go?

  The trap is insidious in software architecture. When we adopt something like microservices, we try to make it so that each service is individually simple. But unless this simplicity is so constraining that your actual application inherits it and is forced into simplicity, it still has to go somewhere. If it’s not in the individual microservices, then where is it?

   If you just tried to pretend complexity could be avoided altogether, it has no place to go in this world. But it still doesn’t stop existing. With nowhere to go, it has to roam everywhere in your system, both in your code and in people’s heads. And as people shift around and leave, our understanding of it erodes.

• Developer Marketing Does Not Exist (book) (2021) by Adam DuVander. I mentioned this briefly in a recent email, but worth including here. If you’ve any intentions of serving a developer audience, either by building your own product or working in a developer relations role, this book gives you a great insight into the developer’s mindset and tactics to help build trust with them.

• First Principles: The Building Blocks of True Knowledge (2018) by Farnam Street. This one’s not specific to software engineering, but more generally to problem solving (and new product building).

  First-principles thinking clears the clutter of what we’ve told ourselves and allows us to rebuild from the ground up. Sure, it’s a lot of work, but that’s why so few people are willing to do it. It’s also why the rewards for filling the chasm between possible and incremental improvement tend to be non-linear.

---

Submitting your recommendations

If you’d like to share an evergreen article/book which has significantly influenced your thinking or practice around software delivery, please email it through to me and I’ll add it to my backlog for sharing in future editions.

Have a great weekend!

— Paul