Whether you’re building software, an AI app, an LLM solution, or learning a new skill, the most progress happens when you break the problem down into smaller pieces.
I’ve noticed this pattern countless times. I’ll be working on a feature, getting frustrated after multiple attempts, re-implementing it in different ways, and then—after some deeper reflection—I realize the core issue: I wasn’t building one feature. I was unknowingly tackling multiple features at once. What seemed like a single unit of work was actually a series of smaller, sequentially ordered tasks.
This idea isn’t new. It’s been discussed under various names—atomic habits, first principles thinking, divide and conquer, and many other frameworks. But despite knowing this in theory, I often forget to apply it in practice. I think I’m breaking things down enough, but in reality, I’m still trying to take too many steps at once.
I’ve also seen this approach work wonders in debugging. When I’m pair programming with a colleague and helping them with a bug, I always ask: Can you try to narrow the scope of what you’re tackling? Can you at least confirm that this fundamental part is even working? More often than not, the answer is no—and that’s where the real bug is hiding.
So why do we keep forgetting to break things down? Maybe it’s because our idea of a “small enough unit” isn’t actually small enough. Maybe we underestimate complexity. Whatever the reason, I think it helps to consciously adopt a mental model that forces us to aggressively simplify and focus on fundamental building blocks. Debugging, feature development, problem-solving—everything benefits when we stop trying to take multiple steps at once.
The key takeaway? When you’re stuck, step back and ask yourself: Am I actually solving one thing, or am I unknowingly solving five? The answer might save you hours of frustration.