A blog series for engineers living somewhere between “just ship it” and “let’s rewrite it in Rust.”

Hey there fellow generalist 👋🏾

Chasing your next-level self

I wrote my first line of code 13 years ago. Whew! After all this time, there’s still one resounding question looming in the back of my head:

What actually makes someone a great engineer?

• Is it solving a LeetCode hard problem in record time?
• Knowing the deepest corners of your standard library by heart?
• Writing abstractions so beautiful that they never get touched again?

I used to think so.
I chased this idea of a “next-level” version of myself—faster, sharper, perfectly composed.
I never quite caught him.
But I did get closer to burnout than I’d like to admit.
Turns out, most of the real work isn’t at the bleeding edge. It’s in the middle—where deadlines loom, systems creak, and tradeoffs win over ideals.

Welcome to a land of tradeoffs

Let’s be honest: most engineering doesn’t happen at the extremes.

We don’t all wrestle with FAANG-scale problems—and honestly, most of us would rather avoid them if we can.

Instead, the average engineer spends their days working on web applications that could use a refactor but still run the business.

This is the land of tradeoffs, glue work, and “don’t touch that; it’s haunted” systems.

It’s not glamorous. But it’s real.

One Story I Keep Coming Back To

There’s a line from Naruto that stuck with me:

“It’s not the number of techniques you know—it’s the guts never to give up.”

Funny enough, one of the best engineers I’ve ever worked with lived that principle—no anime headband required.

He once spent days chasing a bug that only appeared in a non-English version of Windows (because, of course, it did).

He tried over 50 different things. Logged every approach. He didn’t quit. Eventually, he cracked it.

When I asked what kept him going, he just shrugged and said:

“If someone says they can’t solve it, they just haven’t been creative enough yet.”

That stuck with me.

It wasn’t about brilliance.

It was about refusing to walk away from the problem.

What This Series Is About

This series is for the engineers who:

• Hold things together with duct tape and still ship
• Refactor in the margins of tight deadlines
• Know when “just enough” is the most responsible choice

You won’t find hot takes here.

No grand rewrite stories. There are no idealist purity tests.

Just real engineering judgment, lessons from scar tissue, and the kinds of tradeoffs most of us have to live with.

If you’ve ever looked at a gnarly workaround and thought,

“It’s not pretty, but it works,”

you’re in the right place.

Catch you in the next issue—

I’ll be talking about a use case when things moved quickly from “this isn’t performance sensitive” to spending weeks resolving memory leaks and performance problems.

— Kevin