Tag: software-engineering

  • The Local Optimisation Trap

    - How rational team-level decisions create irrational company-wide outcomes and why zooming out matters.

  • Why Less Is More

    - Why teams that create the most value aren't the ones with the best tech, they're the ones with the clearest constraints.

  • Building an AI Application: Lessons from Lenny's Vault

    - A few lessons from building an application built on top of AI APIs.

  • Making Impossible States Impossible

    - The idea of making impossible states impossible in simple terms, means designing your data types and APIs so that certain invalid or nonsensical program states simply can't happen, the compiler...

  • Product Engineers

    - Product Engineers care more about whether something works for customers than whether it ships on time.

  • Build vs Buy vs Run

    - Self-hosting open-source tools sits between building and buying. Sometimes it's the right call, if you respect the operational cost.

  • Reconsidering Tech Debt

    - There's a phrase I've grown wary of over the years: tech debt. It shows up in all kinds of conversations, often spoken as a half-apology, half-warning. The metaphor is sticky,...

  • Choose Boring Tech

    - This isn't new advice, but some reminders deserve another run: choose boring tech if you're in the business of product engineering.

  • From Scepticism to Collaboration with LLMs

    - LLMs work best when you treat them like a junior engineer, not a magic wand. Same standards, same discipline, same reviews.

  • Doing Leveraged Work

    - Staff and Principal Engineers find work that keeps paying off long after they've moved on, multiplying what teams can achieve.

  • Notes on An Elegant Puzzle

    - Will Larson's excellent "An Elegant Puzzle" deep dives into every aspect of being a tech leader at modern software companies

  • How to quickly plan and estimate an MVP

    - This post outlines my tried & tested strategy for quickly planning and estimating MVP projects. This process departs a little from Agile/Scrum best practices. There are no guarantees on estimation...