Our industry is moving so fast that a lot of what we thought about as engineers, like the way we approach adapting to our environment is becoming stale. The mistake I’m seeing most often: seasoned engineers are over-focusing on practice and not recognizing that we actually need adaptation right now.
When I started in software engineering, learning felt like one continuous effort. You absorbed new frameworks, new patterns, new constraints and the industry moved at a pace that roughly matched your ability to absorb them.
I think most of us bought into this view early on:
Improvement equals learning.
That’s our identity as engineers, right? You’re always looking, paying attention, absorbing something new.
But this breaks down as our careers stretch out. Because there are two fundamentally different things happening here, and they’re getting confused with each other.
One is practice: wielding the techniques you’ve already adopted and getting better at them. The other is adaptation: stepping up to change the way you think about a problem entirely, before you’ve even started building a solution.
The mistake is treating them as interchangeable.
One is practice: wielding the techniques you’ve already adopted and getting better at them. The other is adaptation: stepping up to change the way you think about a problem entirely, before you’ve even started building a solution.
The incremental improvement trap
Teams spend most of their energy getting incrementally better at what they already do. Our bug rate is a little high, let’s get better at writing tests; we’re slow to ship, let’s refine our process.
But those are practice goals. They improve what you already know. They don’t change the way you’re approaching a problem space that has shifted under your feet.
The current wave of tooling with AI-assisted development, agentic workflows, new abstractions that didn’t exist six months ago is not a problem of refinement. It’s a problem requiring a fundamentally different way of thinking about what software engineering means.
This comes up in conversations I have every day. A seasoned engineer will tell me, honestly, that they’re working on getting better at prompting. And I respect the earnestness of that effort: it is a skill, and you can get better at prompting.
But what if the real question is whether you’re thinking about prompting in the right direction at all?
When I tell a team they should rethink their whole planning process under AI: that agents should be picking up entire stories, not tickets, that’s an adaptation call. It’s a shift in how I’m thinking about the system, not just getting better at doing things faster.
This is a spectrum, to be clear. Small refinements have their place, especially when things aren’t broken.
In a fast-moving industry, the mistake is mistaking practice for adaptation because it feels safer and more controllable.
The Adaptation Time
The best senior engineers I know now schedule “adaptation time” explicitly, not just the time to become more efficient at things they already do, but time to step up a level and inspect their own assumptions.
So here’s what I’m doing differently now: every quarter, I set aside time to ask the question that feels most uncomfortable. It’s always at least as uncomfortable as “we need to change how we work” usually more. I ask things like whether the team structure that works today should exist at all, or what’s missing from my perspective because I’m optimizing the wrong problem.
What I’ve noticed is that practicing your way through this transition means getting faster at processes and tools that won’t be useful in six months.
The engineers who adapt, who inspect their own mental models and change them, tend to emerge better positioned.
If I were advising a senior engineer who’s been building the same way for five years:
Stop optimizing the practice of your old work. Start adapting to this new one.
