Stop Chasing Results. Start Building a Process.

What The Inner Game of Tennis taught me about deep work, skill-building, and becoming a better developer.

There's a particular kind of frustration developers know well. You grind for weeks on a project, a skill, a codebase and still feel like you're not moving fast enough. You check your metrics obsessively. You compare your progress to others. You wonder if any of it is working.

I've been sitting with a question lately: what if the outcome is the wrong thing to measure entirely?

I picked up The Inner Game of Tennis recently not because I play tennis, but because someone kept referencing it alongside Cal Newport's Deep Work, and the overlap was too interesting to ignore. I didn't expect a sports psychology book to reframe how I think about learning and shipping. But here we are.

The problem with outcome-focused work

In tennis, players often lose not because of poor technique, but because of what's happening in their head. They obsess over the scoreboard instead of the ball. They spiral into self-criticism after every bad shot. They play to look like they're winning rather than to actually win.

Sound familiar?

As developers, we do this constantly. We optimise for lines of code. We care too much about what a portfolio project looks like on GitHub. We context-switch endlessly trying to appear productive instead of doing the slow, boring work that actually builds expertise.

Newport calls this shallow work the kind of busy-ness that keeps you active but doesn't compound. The Inner Game calls it "trying too hard from the wrong place."

Both are pointing at the same thing: outcome obsession is the enemy of deep progress.

Process is the only variable you control

Here's the reframe that helped me: the outcome is not yours to control. Your process is.

There's a line from the Bhagavad Gita that says it plainly: Karmanye vadhikaraste, ma phaleshu kadachana you have the right to your actions, but not to the fruits of those actions.

In practical terms: you can control whether you write for an hour today. You cannot control whether that writing becomes something great this week. You can control whether you study a new concept every day. You cannot control when mastery arrives.

This is freeing, not discouraging. Because once you let go of the outcome, you can actually build a process worth trusting.

What a real process looks like

The Inner Game of Tennis gives a deceptively simple technique: instead of telling yourself "don't mishit the ball," you visualise where you want the ball to go. You work with your mind, not against it.

Applied to developer skill-building, this sounds like:

Instead of: "I need to finally understand distributed systems"
Try: "Every morning this week, I'll read one chapter of the DDIA book and write a one-paragraph summary."

The first is a wish. The second is a process. A process is:

• Specific you know exactly what you're doing when you sit down
• Daily consistency beats intensity, every time
• Written down put it somewhere you'll see it; the act of writing it makes it real
• Boring on purpose if it sounds exciting, it's probably too vague

The cost of context switching

One of the biggest process killers I've noticed is context switching. Every time you abandon one thread to pick up another, you're not just losing the time to switch you're losing the depth you'd built up in the first thread.

This is what Newport means when he talks about deep work. Depth isn't about how many hours you work. It's about how long you can sustain focused attention on a single hard thing.

The shallow alternative is easy to mistake for productivity: Slack messages, quick PRs, bouncing between three half-finished features. It feels busy. It doesn't compound.

A good process protects your depth. It says: for the next hour, this is the only thing.

When you feel weak, keep the process

There will be days when you don't want to follow the process. When distraction wins. When you feel unfocused, scattered, or just tired.

The Inner Game has something useful here too: don't fight those states. Notice them, then return to the process anyway. The process doesn't require you to be in peak condition. It just requires you to show up.

This is the thing that separates people who build serious skills from people who stay perpetually intermediate: not talent, not intensity but consistency when it's hard. Especially when it's hard.

Choose depth over coverage

One last idea worth sitting with: as you build your process, resist the urge to be broad. The developer who knows five frameworks passably is less formidable than the one who deeply understands one and can reason from first principles.

Depth is uncomfortable because it means being a beginner again even after you've gotten good. It means sitting with a problem longer than feels necessary. It means being okay with boredom.

But boredom, it turns out, is just what deep work feels like before it starts paying off.

The short version

• Focus on process, not outcome the outcome follows eventually
• Context switching kills depth; protect your focused time fiercely
• Define your process concretely and write it down
• Show up when it's hard; that's when it actually matters
• Choose depth over coverage every time you can

The score will take care of itself. Watch the ball.