I’ve been thinking about how we talk about our work.
When I look at a resume, I see a list of tools. JavaScript. React. Python. AWS. Kubernetes. The hammers in the toolbox. And sure, knowing your tools matters. But lately, I’m noticing something missing.
What problems did you solve? What need were you fulfilling?
The House, the Hammer, and the Need for Shelter
It’s not about the hammer. It’s not even about the house being built. It’s about the need for housing and the problems preventing that need from being fulfilled.
This shift in perspective changes everything.
When I review someone’s experience, I want to know: What was the need? What problems stood in the way? What solution did you build? And yes, what tools did you use to get there?
That sequence matters. It tells me how someone thinks. It shows me whether they start with the problem or start with the tool they want to use.
I’ve seen developers reach for complex frameworks because they wanted to use them, not because the problem called for them. I’ve seen teams build elaborate architectures when a simple solution would have served the need better.
The tool doesn’t define the work. The need does.
What This Means for How We Hire
If we restructure how we think about experience—focusing on problems solved and needs fulfilled first, tools second—we get better information.
Our marketing department can promote the problems we solve, not just the technologies we know. We can find people who have tackled similar challenges, regardless of whether they used the exact same stack.
Someone who solved a complex data synchronization problem in Java might be exactly who we need for a similar challenge in Python. The problem-solving patterns transfer. The specific syntax is learnable.
This takes me back to a framework I keep returning to: Need → Problem → Solution.
- Identify the need
- Identify what problems are getting in the way of fulfilling that need
- Identify the solution for it
The tools come after. They’re part of the solution, not the starting point.
The Speed Trap
This connects to something else I’ve been noticing: our obsession with velocity metrics.
Lines of code per hour. Story points per sprint. Commits per day.
If someone is producing a thousand lines of code per hour, is that fast or slow? Compared to what? And more importantly: are they building the right thing?
I watched a developer write several hundred lines of code to build CRUD functionality. It was supposed to be simple—Create, Read, Update, Delete. Basic stuff. But the implementation was complex, hard to understand, hard to maintain. And when it came time to actually use the feature, it required even more lines of code to work with it.
The velocity was high. The trajectory was wrong.
Tracking Trajectory, Not Just Speed
Speed is one data point. But what about knowing where we are? What about checking our trajectory?
We can be traveling fast and heading the wrong way. That puts us further from the goal, not closer to it.
I’m thinking about the developer who knows when to apply the brakes. The one who asks, “Wait, are we solving the right problem?” before writing another thousand lines.
What are the metrics for that?
We measure velocity. We measure throughput. But do we measure alignment? Do we measure whether we’re addressing the actual need?
I don’t have a perfect answer for this. But I know that tracking speed alone is incomplete. It’s like measuring how fast the train is going without checking if it’s on the right track.
What I’m Trying to Do Differently
I’m trying to start conversations with the need, not the tool.
When someone asks me for help, I’m asking: What are you trying to accomplish? What’s the need you’re fulfilling? What’s getting in the way?
Only then do we talk about React or Python or whatever tool might help.
When I write about my own work, I’m trying to lead with the problem. What was I noticing? What wasn’t working? What did I try?
The tools are part of the story, but they’re not the story.
And when I’m reviewing code or mentoring developers, I’m asking about trajectory as much as velocity. Are we building the right thing? Are we making it easier or harder for the next person?
A Pause, Not a Conclusion
I’m still figuring this out. But I’m noticing a pattern: the best work I’ve seen starts with a clear understanding of the need and the problems in the way.
The tools matter. The craft matters. But they serve the need, not the other way around.
Maybe that’s what we should be optimizing for—not just how fast we’re going, but whether we’re heading in the right direction.
Leave a Reply