[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.

  • 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

Join daily email list

I publish short emails like this on building software with serverless on a daily-ish basis. They’re casual, easy to digest, and sometimes thought-provoking. If daily is too much, you can also join my less frequent newsletter to get updates on new longer-form articles.

    View Emails Archive

    Architecture & Process Review

    Built a serverless app on AWS, but struggling with performance, maintainability, scalability or DevOps practices?

    I can help by reviewing your codebase, architecture and delivery processes to identify risk areas and their causes. I will then recommend solutions and help you with their implementation.

    Learn more >>

    🪲 Testing Audit

    Are bugs in production slowing you down and killing confidence in your product?

    Get a tailored plan of action for overhauling your AWS serverless app’s tests and empower your team to ship faster with confidence.

    Learn more >>