Posts

Showing posts from October, 2025

The Documentation Paradox: What Should You Actually Document?

Image
There's an uncomfortable truth about software documentation that nobody wants to admit: Most documentation is solving the wrong problem. Not because documentation itself is bad. But because we're documenting things that shouldn't need documentation in the first place. The Documentation Dilemma Every engineering team faces this cycle: Engineers spend hours writing documentation. It gets skimmed once during onboarding. It's never updated. Six months later, it's wrong. Now it's dangerous—misleading developers who trust it. The question isn't "should we write documentation?" The question is "what should we be documenting, and why?" The Myth of "No Documentation" There's a popular belief that great products don't need documentation. People point to consumer products as proof: "The iPhone didn't ship with a manual!" This is misleading. The original iPhone in 2007 did have a comprehensive 124-page user guide—it wa...

Stop Building: Why Less Is More in Software Development

  Stop Building: Why Less Is More in Software Development The biggest waste in software isn't bugs, technical debt, or slow deployments. It's building features nobody uses. Research reveals a sobering truth: 45% of features are never used, 19% are rarely used, and only 36% are used regularly or often. Translation: nearly half of engineering effort creates zero value. Think about that for a moment. Half of all the sprints, all-nighters, code reviews, bug fixes, and deployment stress—wasted on features that users will never click. This isn't a small problem. It's the silent killer of engineering productivity and product success. The Three Forces Driving Waste Force 1: Engineers Love Solving Hard Problems We're wired to seek complexity. When faced with a problem, we instinctively reach for the sophisticated solution. A simple notification system? Why not build a real-time WebSocket infrastructure with Redis pub/sub and horizontal scaling? A basic reporting feature? Obv...

When to Use AI (And When Not To): A Builder's Guide

Image
  There's a moment in every product meeting where someone says it: "What if we add AI to this?" Sometimes it's brilliant. Often, it's an expensive distraction. The pressure to "do something with AI" is overwhelming. Investors ask about AI strategy. Competitors tout AI features. Teams feel compelled to add AI not because it solves a problem, but because they're afraid of being left behind. Here's the truth:  AI is a tool, not a strategy.  And like any tool, it's only valuable when applied to the right problem. The Three Mistakes Everyone Makes 1. Using AI Where Rules Work Better A startup built an AI expense categorization system using a fine-tuned model to classify transactions. The problem? They had clear rules for 90% of cases: flights are always travel, Starbucks is always meals, Office Depot is always supplies. A simple rule engine would have been faster, cheaper, more accurate, and easier to debug. The lesson:  If you can write explicit ...