Why I Optimize for Present and Emerging Technologies

There's a version of this essay that tells you to ignore trends and just use what works. Another version tells you to always be learning the latest thing. I think both are wrong in the same way: they're policies that ignore context.

Here's how I actually think about it.

The Spectrum

On one end: engineers who are always on the bleeding edge. New framework every project. Every tool is a hammer looking for a nail. These engineers are interesting at conferences and exhausting to work with.

On the other end: engineers who never update their mental model. Still reaching for jQuery. Suspicious of anything that wasn't around when they learned to code. Safe, but increasingly limited.

Most people lean one direction or the other. The work is finding the balance.

What "Emerging" Actually Means

I try to stay on top of technologies that are past the experimental phase but before full mainstream adoption. That window usually lasts a year or two.

Why? Because that's when the early adopter advantages are real. The rough edges are known. The patterns for using it are established. But most of the competition hasn't caught up yet.

This is why I've been investing time in applied machine learning, not because AI is new, but because the tooling has matured enough that you can actually ship with it without a dedicated research team.

What "Present" Means

Present technologies are the ones that already work. Postgres. React. REST APIs. These are tools with known failure modes, abundant documentation, and large communities.

My philosophy: reach for boring tools first. Reach for new tools when boring tools would create genuine problems.

The question isn't "what's the best technology?" It's "what's the right technology for this specific problem and team?"

Where I Draw the Line

I don't adopt new technology to be impressive or to satisfy intellectual curiosity on production systems. That's what side projects are for.

But I also don't let "we've always done it this way" be a reason to not look at something better. That's how you end up maintaining a system that technically works but is painful to operate.

The discipline is being able to articulate why you're making the technology choice you're making — not just following instinct in either direction.