"How Many More Years Can I Code?" Is the Wrong Question

Last month, an engineer in his early thirties asked me out for coffee. We hadn't been talking long when he suddenly asked:

"Honestly... how many more years do you think I can keep coding?"

He was serious, but I didn't rush to answer.

Not because the question was hard, but because the question itself was flawed.

Over the years, I've seen too many technical people get stuck behind this mental wall: worrying about their skills becoming obsolete while starting to plan for retirement; working overtime to deliver while scrolling through podcasts about financial freedom.

Some go even further, tying all their future career options to a single dimension: "how much longer can I code."

It sounds pragmatic, but it's actually looking for an exit on the wrong map.

Many people assume that anxiety at 35 is the beginning of a midlife crisis. But from where I stand now (😄, I won't reveal my age), what's more common is a trap of pseudo-planning that starts at 30.

What they're anxious about isn't the future itself. It's this:

They've mistaken a short-term skill for the backbone of a long-term life.

So the questions become:

How much longer can I code?
Should I move into management?
Should I find a job I can keep until retirement?

These seem reasonable, but they all rest on one assumption: technology is a phase, and life is linear.

Yet the most important thing our generation should understand is this: change is the default, and stability is the exception.

I fell into this kind of anxiety myself at 35.

I asked similar questions back then: Should I jump out of the "technical pit" and find a role that can't be replaced? Or just switch to product management or start a company?

But what actually helped me move forward wasn't a career change. It was a shift in how I thought.

I realized: we don't need to exit. We need to restructure.

Not restructure our resumes, but restructure our entire career architecture.

Now I believe something more strongly:

Technical people who go far don't treat themselves as coding machines. They treat themselves as problem-solving systems.

They do three things:

The first layer is dynamic balance in your skill portfolio.

In the past, you were an expert in a particular backend framework. Now you might need to understand the underlying logic of DevOps. Tomorrow you might need to step into AI engineering applications.

The key isn't how much you know, but whether you can connect problems across modules.

I have a friend who was still writing frontend components at 30 and became the head of a data platform at 40. He put it clearly:

I didn't change careers. I just made myself able to participate in building more systems.

It's like investing: you can't put everything on a single stock.

What about AI? Do you have to switch to AI to avoid being left behind?

I've been asked this a lot recently. My personal take is:

AI is a new tool, not a savior. Use it to enhance your core strengths, not to replace the value you already have.

Over the past two years, I've also started experimenting with various AI tools, because I understand where this wave is heading: AI won't replace us, but it will amplify our systemic weaknesses.

If we don't understand the business to begin with, AI will make us even more like assembly-line workers.

If we already have modeling and analytical skills, AI will make us even more capable.

So what we should really learn isn't just how to call a particular large model API. It's how to use AI to strengthen our ability to define problems, abstract, and connect.

That's the real way to add value to your skill portfolio.

The second layer is the compounding growth of influence.

You don't wait for a title promotion to influence others. You start today: reviewing other people's PRs, writing good documentation, defining the logic behind technical decisions, summarizing team consensus.

Influence doesn't mean being a leader. It means making it easier for others to work with you and grow stronger together.

The most trusted individual contributors I've seen aren't trusted because they write the most code. They're trusted because people want to discuss problems with them.

This is an engineer's "second-order survival skill."

And in the AI wave, this kind of influence will only become scarcer.

Prompts can generate code automatically, but no one can generate consensus automatically.

A model can tell you the optimal path, but no one can tell you "whether we should choose this path in this particular business context."

Human judgment, trust, and the ability to integrate complex problems are the parts AI cannot replace.

The third layer is the slow variable of relationship assets.

This is what technical people most easily overlook.

You might think relationships are built through showing your face and handing out business cards. But real relationships are built through working together, enduring difficulties together, and winning together.

Half of my current job opportunities came from former interns, ex-colleagues, and old friends recommending me.

When your network is built on shared experience rather than mere acquaintance, it has real value.

In an era where AI is leveling the playing field of skills, connections between people will become even more important.

You're not looking for a collaborator who can be replaced by anyone. You want to become the person who is trusted, willing to cooperate, and worth bringing along.

So, back to that question:

How many more years can I code?

I'd say—that's not the question we should be asking.

The questions truly worth asking are:

"Is my skill portfolio strong enough to let me enter different systems?"
"Would others want to bring me into their next battle?"
"In how many possible futures will what I'm doing now still contribute value?"
"After AI arrived, has my value been amplified or diluted?"

Stop worrying about "not being able to code anymore." That's just the surface.

Technology is our language, not our boundary.

Turn yourself into a system that can adapt to change, and you won't fear change.

Have you ever asked yourself "how many more years can I code"? Now, how would you ask the questions that really matter?

In the AI era, which layer do you plan to strengthen first: skill portfolio, influence, or relationship network?

Maybe he's not unable to code anymore. He's just stuck on a question he shouldn't be asking.