A question that stuck with me
Twenty years ago—mid‑2000s—I was giving talks on developer productivity. Back then, productivity talks involved mastering the tools. ReSharper. CodeRush. Visual Studio add‑ins that let you refactor, generate boilerplate, and move code around at impressive speed.
I had gone pretty far down that road myself. Code generators. Custom Visual Studio extensions. Point a tool at a database table, hit a few keys, and suddenly you have layers of C# scaffolding ready to go. At conferences, I’d demo how quickly you could create classes, properties, methods—almost without thinking.
At the end of one of those talks, someone came up and asked a simple but uncomfortable question:
“How do you know you were more productive?”
That question stuck with me.
Fast code isn’t the same as productive work.
It’s easy to confuse speed with productivity. Suppose you can generate lots of code quickly—whether by typing fast, using snippets, or writing a code generator—you feel productive. But that feeling doesn’t mean much.
Lines of code should measure nobody. If that were the case, the most productive person on the team would be the one who wrote the biggest generator.
That question forced me to rethink how I talked about productivity. Not what tools we were using. Not how clever the shortcuts were. But why did they matter at all?
Keeping my mind free for the real work
The way I eventually learned to articulate it was this:
The tools matter (or rather, why I use them, and what I use them for) because they keep my mind free to focus on the problem we’re actually trying to solve.
That’s the part that doesn’t show up in metrics easily.
And that’s where the driving analogy comes in.
Learning to drive in São Paulo
I learned to drive in São Paulo, Brazil—a city full of hills, traffic, and almost exclusively manual transmissions.
When you’re learning to drive a stick shift, everything takes attention:
- Where your feet are
- When to press the clutch
- When to release it
- How much gas to give
- What gear you are in
Stopping on an uphill in traffic is especially memorable. You feel the car roll back slightly. The driver behind you starts honking. Your brain is fully occupied with not stalling and not hitting anyone.
Back then, before GPS, we’d plan routes using paper maps. And early on, we’d actively avoid streets with steep uphills. Not because they were bad roads—but because we weren’t comfortable yet.
Later, once those motions became automatic, everything changed. We stopped thinking about pedals and gears and started thinking about the route instead:
- Do I want the fastest way?
- The safest way?
- The scenic way?
Driving faded into the background. Navigation moved to the foreground.
Software development works the same way
I’ve come to see software productivity the same way.
I never really thought of myself as a coder. Even early on, I saw myself as a problem‑solver who happened to use computers. Code was a tool, not the goal.
The real work was always about:
- Solving people’s problems
- Helping the business move forward
- Making sure stakeholders were satisfied
When the mechanics of coding become automatic—refactoring, testing, scaffolding, navigating a codebase—you get mental space back. That space is what lets you reason about the system, explore alternatives, and make better decisions.
That’s productivity.
AI doesn’t change that—it amplifies it
I see many developers talk about AI primarily as a way to write code faster. That’s not how I think about it.
To me, AI is just another tool in the toolbox—one that helps shorten the distance between an idea and a working solution.
It lets us:
- Try multiple approaches quickly
- Test different hypotheses
- Explore solutions before committing
And then—this part matters—let the people who need the solution decide what works best.
The value isn’t speed for its own sake. The value is faster learning.
A sprint that validated my perspective
The sprint we just wrapped up was, by perception, quite possibly the most productive sprint I’ve ever been part of.
Not because we wrote the most code.
But because:
- We delivered meaningful features
- We addressed critical issues
- Stakeholders clearly saw value
- The feedback was overwhelmingly positive
Those outcomes didn’t come “for free” just because we used AI tools.
AI helped—but only because we already had:
- A solid architecture
- Clear processes
- Strong technical and product discipline
We were doing good work before AI showed up. AI multiplied the effect.
Why measuring productivity is still hard
People love talking about “10x productivity,” but I’m skeptical of the number.
What are we measuring?
- Lines of code? Misleading.
- Story points? They shift over time.
- Number of commits? Interesting, but incomplete.
I’ve looked at all of these. Some went up. Others went down—because AI compressed work that used to require multiple tasks into one.
Paradoxically, adding more granular tasks can slow teams down.
So I don’t think I have great metrics yet.
I’ve been exploring The SPACE of Developer Productivity, and it feels promising. Maybe in a few months—or a year—I’ll have better data.
For now, what I have is a strong signal: satisfied stakeholders, meaningful outcomes, and a team that feels effective.
The quiet definition of productivity
Real productivity is when the tools fade into the background.
When you stop thinking about how you’re doing the work and start focusing entirely on why the work matters.
That’s when you know something important has shifted.
I’ll let you know what the numbers say when I have them.
Leave a Reply