The long game

You already have everything you need to become exceptional at this. You just need to know where to look.

Most engineers never realize they’re playing the wrong game.

They’re optimizing for speed. For output. For visible productivity. Lines of code, tickets closed, features shipped. The metrics are clear, the feedback immediate, and there’s real satisfaction in watching those numbers climb. Especially now, when AI can generate entire modules while you’re still reading the requirements—the temptation to treat volume as victory is overwhelming.

But volume isn’t mastery. It’s just noise with a commit history.

The real game—the one that separates adequate from extraordinary—has nothing to do with how fast you ship. It’s about whether you’re getting better. Whether yesterday’s impossible problem is today’s warm-up. Whether you can feel yourself becoming more capable, more certain, more clear in your thinking.

This is hard to see when everything around you screams faster, more, now.

The Pressure to Perform

When product asks for a feature, you feel it immediately: the weight of expectation. Everyone’s moving fast. Everyone’s delivering. The fear of saying “I need time to think about this” feels almost physical. What if they think you’re slow? What if they think you can’t handle it?

So you race. You take the first approach that works. You let the AI generate the boilerplate and move on. You ship it, feel the brief dopamine hit of completion, and grab the next ticket.

The code works. The tests pass. You’re productive. You’re keeping up.

But here’s what you don’t notice: you’re standing still. The problems you can solve today are the same problems you could solve six months ago. The patterns you recognize are the same patterns. The depth of your understanding hasn’t changed at all.

Speed without growth is just expensive motion.

The Devil’s Bargain

Here’s what’s insidious about this moment: AI makes it easy to feel productive while learning nothing.

You can scaffold applications in minutes now. Generate test suites, solve syntax errors, refactor entire modules—all before you’ve had your second coffee. And yes, this is powerful. There’s no virtue in memorizing API signatures or rewriting the same authentication logic for the hundredth time.

But if you’re not careful, you stop thinking entirely. You take the first solution that compiles. You ship it. You move on.

And something crucial stops happening in your brain.

Your neurons aren’t firing in new patterns. Your synapses aren’t forming new connections. The mental models that separate good engineers from great ones? They’re not building. They can’t build, because you’re outsourcing the very struggle that creates them.

AI offers a shortcut to an outcome. But there’s no shortcut to understanding. Your brain doesn’t learn from outcomes—it learns from process. The wrestling with a problem. The failed attempts. The moment something finally clicks and you understand it in a way you didn’t before.

Skip that process and the gap between what you can produce and what you actually understand grows wider every day.

This matters because mastery isn’t about what you can generate—it’s about what you can see. The ability to look at a problem and immediately recognize its shape. To know which complexities are essential and which are self-inflicted. To build systems that feel inevitable because you understand, deeply, why they have to be this way.

That kind of judgment—that’s what AI can’t give you. It can’t teach you to distinguish good architecture from clever architecture. It can’t show you when to add complexity and when to ruthlessly eliminate it. It can’t build the pattern recognition that comes from solving the same class of problem fifty different ways until you can feel the right approach before you’ve written a line of code.

The engineers who use AI to avoid thinking will stay stuck. The engineers who use it as leverage—who make it regenerate solutions until they’re not just working but clear, who treat it like a tool that handles mechanics so they can think more deeply about design—those are the ones who’ll keep growing.

But only if they’re doing the work. Only if they’re building the mental models. Only if they’re staying in contact with the struggle that creates understanding.

This takes time. It takes repetition. It takes doing the same thing badly, then better, then well, until your hands know what to do before your conscious mind catches up.

There’s no shortcut to this. The struggle is the point.

Are You Mad About This?

If you’re young, you have an advantage you don’t fully appreciate yet: your brain is still incredibly plastic. Neural pathways form faster. Skills compound quicker. The hard work you put in now will pay dividends for decades.

But only if you actually do the work.

The older you get, the harder it becomes to build new mental models from scratch. Not impossible—nothing’s impossible—but harder. Unless you’ve made learning itself your life’s work. Unless you’ve kept your brain in the habit of struggling with hard problems, of building new understanding, of staying uncomfortable.

So if you’re in your twenties and treating this like just a job, you’re wasting the most valuable learning years you have. Not because you owe anyone unpaid overtime—fuck that—but because you’re standing in front of an open door and choosing not to walk through it.

The real question isn’t about age though. It’s this: are you mad about this?

Does it matter to you? Not abstractly, not as a career strategy, but viscerally—do you care about getting better at this thing? Does it pull at you? Do you think about problems when you don’t have to?

If you don’t, that’s fine. Genuinely. Not everyone needs to burn for their job. The world needs people who show up, do good work, and then go live their actual lives. There’s dignity in that.

But if you do care—if there’s even a spark of obsession buried somewhere in you—then feed it. Because the luxury of getting paid to do something you actually give a shit about is rare. Most people never find it. And if you’ve stumbled into it, even accidentally, lean the hell into it.

Not for your employer. For you.

The Mat Time Problem

In jiu-jitsu, there’s a saying: the only way to get better is more mat time. Period.

You can watch every instructional video ever made. You can study technique breakdowns, memorize sequences, understand the theory perfectly. None of it matters until you’re on the mat, getting crushed, learning to feel when something’s about to go wrong before your conscious mind registers it.

Engineering is the same.

You need time writing code that matters. Not toy examples. Not tutorial projects. Code that has constraints, that has to work, that other people depend on. Code where your decisions have consequences and you have to live with them.

This is why work can be so valuable—even when the work itself isn’t your passion project. The constraints are real. The deadlines are real. The need to collaborate, to compromise, to deliver something even when you don’t have all the answers—that’s all practice you can’t get anywhere else.

But here’s the thing: you can get mat time anywhere. At your job, sure. In open source. In side projects that matter to you—not because they’ll make money or look good on your resume, but because you’re genuinely curious about solving them.

The location doesn’t matter. What matters is whether you’re actually grappling with real problems. Whether you’re building something substantial enough that you have to think deeply about architecture, about trade-offs, about what happens when your assumptions are wrong.

And whether you’re paying attention while you do it. Most engineers rack up years of experience but never actually learn from it because they’re not watching closely enough. They’re solving problems on autopilot instead of noticing why certain approaches work and others don’t.

That awareness—that deliberate attention to what’s happening while you code—that’s what turns time into growth.

What Actually Changes You

Most engineers never ask themselves: “Am I better than I was six months ago?”

Not “did I ship more features” or “did I get promoted” but—can I do things now that would have been impossible for me then? Can I see solutions more clearly? Do problems that used to terrify me now feel manageable?

This is the only metric that matters.

Because here’s the thing about mastery: it feels different. When you build something and you really understand it—not just how it works but why it has to work this way—there’s a satisfaction that has nothing to do with anyone else. It’s not about impressing your team or getting praise. It’s the quiet pleasure of knowing you’re better at this than you used to be.

That feeling is your compass.

If you’re not experiencing it, if every project feels roughly the same as the last one, you’re not growing. You’re just repeating yourself with different variable names.

Growth requires discomfort. It requires taking on problems you’re not sure you can solve. It requires caring enough to redo something when the first attempt works but doesn’t feel right. It requires staying curious about why things are the way they are instead of just accepting that they work.

And yes, it requires a lot of fucking work. Hard work. The kind of work where you stare at a problem for hours and feel stupid, where you throw away entire approaches, where you question whether you’re even cut out for this.

That’s not a bug. That’s the feature. That discomfort is your brain rewiring itself. Those failed attempts are building the pattern recognition that will make future problems easier. The struggle is the progress.

The Luxury No One Talks About

Here’s something nobody mentions: work doesn’t have to be just work.

Most people clock in, do the job, get paid, clock out. Their real life happens elsewhere. And that’s fine—that’s most of human history. There’s dignity in that trade.

But if you’re one of the rare people who actually gives a shit about this craft, then you have an opportunity that most people never get: you can use your job as a training ground. Not for your employer’s benefit—for yours.

The constraints are real at work. The problems are messy. You have to collaborate, compromise, deliver something even when you don’t have all the answers. That’s valuable practice. That builds capabilities you can’t get from side projects or tutorials.

So squeeze everything you can out of it. Not more hours—more learning. Pay attention to why certain approaches work and others don’t. Notice what makes code maintainable versus what makes it a nightmare. Build the mental models that will serve you for the next thirty years, not just the next sprint.

Some places make this easier than others—some actually let you focus on solving real problems instead of drowning in politics and process. If you’ve found one of those, use it. If you haven’t, extract what you can anyway. Because ultimately, companies are companies. They’ll make decisions based on what’s best for them, not you.

The work you’re doing right now? It’s either building you into someone more capable, or it’s just filling time between paychecks.

The choice is yours. No company can make it for you. But you should.

The Only Question That Matters

Are you better than you were yesterday?

Not by much. Not in ways anyone else would notice. But can you feel it? That slow accumulation of capability, of confidence, of clarity?

That’s the game.

Everything else—the velocity, the metrics, the visible output—that’s just scorekeeping. It feels important because it’s measurable. But it’s not the thing.

The thing is whether you’re becoming someone who can solve harder problems. Whether you’re building the kind of deep understanding that lets you see solutions other people miss. Whether you’re growing into the engineer you want to be instead of staying the engineer you already are.

This takes time. It takes thousands of hours of deliberate practice. It takes caring when you don’t have to, trying when it’s easier not to, starting over when the first attempt works but isn’t quite right.

And here’s what nobody tells you: it never stops. There’s no finish line where you’re finally “good enough” and can coast. The problems just keep getting more interesting, the solutions keep getting more subtle, the understanding keeps deepening.

But that’s the beautiful part.

Not the career ladder, not the compensation, not the title on your LinkedIn. Those things come and go. Companies reorganize. Markets shift. The hot framework of today is legacy code tomorrow.

What persists is what you’ve built inside your own head. The mental models. The pattern recognition. The ability to look at a system and just know. That’s yours. Nobody can take it from you, nobody can obsolete it with a new language or framework. It compounds every year you do this work, every problem you solve, every time you choose to understand something deeply instead of just making it work.

If you’re paying attention—if you’re chasing that feeling of getting better, of understanding more deeply, of building more clearly—you’ll still be excited about this in twenty years. Thirty years. However long you do it.

Because you’re not just doing a job. You’re practicing a craft.

And the craft gives back everything you put into it.

That’s the long game.