Context

One of the most extreme examples I've faced was environmental variables. Getting a NextJS app into a production Amplify application was brutally difficult. AWS's directions were not super clear, and relying on an LLM to do the work was probably one of the worst LLM experiences I have experienced.

Here's the setup: I was deploying a Next.js app to AWS Amplify, which lets you run a complete web stack for about $2/month. Incredibly efficient. I'll tell you what was not efficient, trying to actually do deployment as my stack got more complicated.

I would configure all my variables. Everything would run perfectly in my local environment. I'd deploy to production — perfect. Then I'd add one new environmental variable, and the deployment would silently fail. No clear error. No obvious cause. Total hair-puller. For example, did you know that AWS has different requirements for accessing compute and resources when it runs? I know now, but it isn't intuitive when I first started.

At that point, developers have two choices: throw their hands up in frustration, or sit down and think through it clearly.

I did not choose the clear path at first. I decided to keep hitting LLMs and clicking, I believe, I believe, I believe. After several Git resets in clearing out agents, I had to do what I should have done from the beginning. I chose the clear path.

I started taking micro steps to improve my environment. I wrote a small script — maybe 30 lines — that prints out every environmental variable in my codebase: where it's defined, where it's used, and how my deployment hooks install it for both AWS and local development.

That tiny tool changed everything. Now I could diagnose env var issues in seconds instead of hours. I can now jump into new projects and solve this problem for other developers immediately. What started as frustration became acceleration. It all started by taking a little step, and then taking little steps to move the ball along, while I was doing other real work as well.

Lesson

The lesson here is simple: identify your friction points and remove them, one micro improvement at a time.

Every time I hit that environmental variable wall, I was losing hours. That's friction. And friction compounds — it drains your momentum, kills your focus, and makes you dread the work.

So I stopped tolerating it. I didn't try to solve the whole problem at once. I just asked: what's the smallest thing I can build to make this less painful? The answer was a 30-line script that showed me where every variable lived.

That tiny tool removed the friction. And here's what happened next: by building it, I actually understood the system. Not because I set out to learn it, but because removing the friction forced me to engage with the details.

That's the real power of micro improvements. You're not just fixing an annoyance — you're building knowledge and momentum with each small step. The friction disappears, and understanding takes its place.

How to apply at work

Notice the friction. Pay attention when something annoys you. That deployment that always breaks. That config file you have to look up every time. That manual process you dread. Don't ignore it — name it.
Ask one question: what's the smallest fix? Not the complete solution. Not the refactor. Just the tiniest improvement that makes it slightly less painful. A script. A checklist. A single comment in the right place.
Build it while you work. Don't block out a whole afternoon. Spend 15 minutes between tasks. The micro improvement happens alongside the real work, not instead of it.
Repeat. Next week, you'll notice another friction point. Same process. Over time, these small fixes compound into a workflow that feels effortless.

The key is not waiting for permission or a dedicated "improvement sprint." You just fix small things, continuously, as you go.

The Payoff

The payoff is huge.

Every micro improvement is a private victory. No one sees you write that 30-line script. No one applauds when you finally understand how Amplify handles runtime variables. But you know. And that knowledge compounds.

Think about Larry Bird. Michael Jordan. Kobe Bryant. These guys didn't sit around talking about what they should do. They didn't theorize about greatness. They got in the gym before sunrise and ground out thousands of shots, alone, when no one was watching. Private victories, over and over, until their skills became undeniable.

Coding is the same. You grind out small victories every day. You fix the friction. You learn the details. You build the tiny tools. And one day you look up and realize you've become someone who actually knows what the fuck they're doing and become the best in the world at it.

These private victories add up. They build your confidence, sharpen your instincts, and give you something most people don't have: proof. When I sit down with my team now, I can make real recommendations — not theory, but experience. I can say, "Here's what I think you should do," and back it up with a working example. That's not bullshit. That's earned knowledge.

And there's the momentum. Every small win creates energy for the next one. You start to feel flow — that state where work stops feeling like a grind and starts feeling like progress. You're not just surviving your environment anymore. You're shaping it.

That's the real payoff: private victories become public credibility.

Blog

Micro Improvements: Your Engineering Edge