Fundamentals First
Before I use anything, I ask one question: what is this hiding from me?
Every tool makes decisions on your behalf. Understanding which decisions — and what they cost — changes how you use it, how you debug it, and how you recognize when it stops working. That question is the habit. Everything else follows from it.
Build Naive. Push It Until It Breaks. Fix the Right Thing.
When I built the collision detection system for the game engine, the naive approach was obvious: check every object against every other. O(m×n). It worked — until the object count grew and the frame rate told me otherwise.
The fix to ~O(m+n) didn’t come from knowing the right algorithm in advance. It came from watching the naive version fail, understanding exactly where the cost was accumulating, and restructuring the comparisons until the performance changed. The naive solution wasn’t wasted — it was the thing that showed me where the complexity actually lived.
That process is how I approach most problems. Start with the simplest thing that could work. Push it until it breaks. Then fix the right thing — not the most obvious thing, not the easiest thing, the right thing.
Beyond DSA
I’ve solved 200+ problems across platforms — 100+ on LeetCode. DSA sharpens pattern recognition and complexity thinking. I respect it and I’ve done it.
But somewhere around problem 150, I noticed that the skills making me better at LeetCode weren’t the same skills making my projects work. DSA tells you how to solve a well-defined problem efficiently. It doesn’t tell you how to structure a system, where the real complexity lives, or what to do when the problem itself is wrong. Those things come from building.
What I Actually Care About
Not shipping fast. Not knowing the most tools. Not having the cleanest abstractions.
Understanding what I’m building well enough that when something breaks — and it always breaks — I’m not guessing. The projects on this site are part of that process.