Builders often define themselves by what they create and the tools they use. It's natural - after all, that's where we spend our time and direct our focus. But what if this attachment to building is actually getting in the way of our primary job: solving problems?
In DEV347, Ben Kehoe, Distinguished Engineer at Siemens and AWS Serverless Hero, delivered a thought-provoking session that challenges how we think about being builders. His central thesis: "A builder's true job is solving problems, which may or may not require building something."
Watch the Full Session:
The Problem with Traditional Builder Mindsets
Ben identified three common mindsets that can limit our effectiveness:
Identifying with your tools - Whether it's VI versus Emacs, SQL versus NoSQL, or any other technology choice, when tools become part of our identity, disagreement feels like a personal threat. This leads to flame wars and poor decision-making.
Identifying with your output - When we view our code as "our baby," not-invented-here syndrome takes hold. If someone suggests our creation isn't useful, it feels like an attack on ourselves.
Isolation from greater purpose - When we narrow our focus to just delivering to the next team without understanding the broader organizational context, we lose sight of why customers would care about our work.
These mindsets share a common problem: they focus on outputs (the things we build) rather than outcomes (the problems we solve).
Why Mindset Matters: Lessons from DevOps
Ben drew powerful analogies from software development practices to illustrate why examining our mindset is valuable:
Continuous Deployment - The value isn't just faster time to market. It's that continuous deployment forces you to be good at testing, rollback, and mean time to resolution. It creates accountability and requires humility - you're acknowledging you won't get it perfect, so you need robust safety mechanisms.
You Build It, You Run It - When the same team is responsible for both development and operations, they're held accountable for software quality. If it's hard to run, that's their problem to solve.
Blameless Postmortems - We don't assign blame not because there's nobody to blame, but because blaming people prevents us from understanding why things went wrong. We prioritize introspection over finger-pointing.
As Ben noted: "Humility and self-confidence are not mutually exclusive. Humility and ego are." Self-confidence means believing in your abilities while remaining open to being wrong and always improving.
The Outcome-Focused Mindset
Ben's core argument centers on a crucial distinction: outcomes are assets, implementations are liabilities.
"When we talk about a software feature, the feature is the asset, but the implementation is a liability. At best, in a perfect world, it does exactly what you expect it to do. The only thing your implementation can do is subtract value from the feature."
This reframes everything. Every line of code you write is a potential source of bugs, maintenance burden, and technical debt. The feature itself - the problem it solves - is what has value.
This perspective also helps us understand our place in the organization. When you focus on outputs, you only see the next step in the value chain. When you focus on outcomes, you can trace how your work connects to customer needs through multiple teams and layers.
Ben referenced the classic saying: "People don't buy drills, they buy holes." Understanding the outcome (the hole) rather than just the output (the drill) allows you to work with customers to find better solutions than what they initially requested.
Applying the Outcome-Focused Mindset
Technology Selection
View tools as means to an end - Don't identify with your technology choices. Understand yourself as adaptable. If your dev setup has to be exactly right or you can't work, that's brittle - and we don't want brittle systems.
Focus on total cost of ownership - The AWS bill is only part of the cost. A system that runs cheaply but requires constant operational attention may be more expensive than one with higher infrastructure costs but minimal maintenance. Consider costs across you, your team, your organization, and your company.
Optimize for runtime over development time - Code runs far more often than it's built. Optimize for ongoing maintenance and operations costs rather than development speed.
Understand technical debt strategically - Ben made a brilliant point: if you ask your finance team whether your company should have zero debt, they'll say no. Debt is leverage. The same applies to technical debt. "If you have none of it, you are not moving fast enough." Take on technical debt strategically when it provides value, but have a plan to pay both the interest (keeping it running) and the principal (fixing it properly).
The Productivity Paradox
Here's an uncomfortable truth: "The feeling of productivity is a poor proxy for actual productivity."
When you're in flow state writing code, that feeling is about your outputs - how effectively you're creating code. But whether that code is the right thing to create isn't something you feel in the moment.
Ben shared a story about AWS Step Functions in 2017. Back then, Step Functions was hard to use - writing JSON, wrestling with JSONPath, poor documentation. It felt unproductive and frustrating. But if you spent that afternoon struggling with it, you often ended up with something you never had to touch again. It just worked, scaled automatically, and ceased to occupy mental space.
Compare that to building the same workflow in a different way that felt more productive in the moment but required ongoing maintenance, updates, and occasional firefighting. The total cost of ownership was much higher, even though it felt better to build.
Technology Transformation
Throwing away code should be a joyous act - When a feature is no longer needed, or when a third-party service or AWS service now does what you built, celebrate. That implementation was always a liability. Now it's off your balance sheet and you can create something else valuable.
This requires not identifying with your output. That code you poured blood, sweat, and tears into isn't you. If it's no longer useful, let it go and do something else useful.
Organizational Transformation
When your organization changes - through reorgs, new strategies, or different ways of working - understanding your place through outcomes rather than outputs makes you resilient.
If you're not your tools, then changing what tools you use or what you're building doesn't threaten your identity. You can understand how you're serving the organization in new ways, potentially moving up the value chain or into different value chains entirely.
The AI Factor
Ben addressed the elephant in the room: how does AI change this mindset?
Accountability still lies with you - Currently, if AI gets it wrong, you're accountable. This means you need to know what good looks like to catch and fix problems.
Apply the same thinking to AI-generated code - If AI is generating boilerplate, ask why that boilerplate is necessary. Reducing boilerplate means less code that can be wrong, whether written by humans or AI.
The senior/junior engineer gap - Historically, new technologies allowed junior engineers to compete with senior engineers by eliminating things seniors had to worry about. AI works differently. It's more effective in the hands of senior engineers who can evaluate its output and fix problems. Junior engineers using AI may not develop the skills they need because AI is doing the work for them. This creates a training challenge we must address.
Quality versus cost curves are shifting - AI can create something that works at extraordinarily low cost (vibe coding). But for very high-quality software, AI lowers costs much less dramatically. This changes business decisions about acceptable quality levels. "High quality software is not the point." The appropriate level of quality is a business decision based on needs, not an absolute standard.
Key Takeaways
We are not artisans - Software isn't craft work requiring perfection. It's easy to make software (though not easy to make good software). We're not creating objects of beauty; we're solving business problems.
Focus on outcomes over outputs - Features are assets. Implementations are liabilities. The less you have to build to achieve an outcome, the better.
Don't identify with your tools or output - You are not your technology choices. You are not your code. These are means to an end.
Understand total cost of ownership - Consider all costs: development, operations, maintenance, opportunity cost. Balance them intelligently.
Be strategically comfortable with technical debt - Like financial debt, technical debt can be leverage. Use it wisely.
Embrace change and obsolescence - When your code becomes unnecessary, celebrate. When the organization shifts, adapt by focusing on the outcomes you provide.
Builders are problem solvers - The thing that makes us builders is that our mechanism for solving problems is to build. But building is the tool, not the job.
As Ben concluded: "When we ask who am I, and we acknowledge that we are not our tools, that we are not our output, we can answer that we are problem solvers. That is the thing that we do. We are asked to solve problems in interesting ways. The thing that makes us different from other people, where we get that label, is that the mechanism by which we solve problems is to build, and that is what makes us builders."
About This Series
This post is part of DEV Track Spotlight, a series highlighting the incredible sessions from the AWS re:Invent 2025 Developer Community (DEV) track.
The DEV track featured 60 unique sessions delivered by 93 speakers from the AWS Community - including AWS Heroes, AWS Community Builders, and AWS User Group Leaders - alongside speakers from AWS and Amazon. These sessions covered cutting-edge topics including:
- 🤖 GenAI & Agentic AI - Multi-agent systems, Strands Agents SDK, Amazon Bedrock
- 🛠️ Developer Tools - Kiro, Kiro CLI, Amazon Q Developer, AI-driven development
- 🔒 Security - AI agent security, container security, automated remediation
- 🏗️ Infrastructure - Serverless, containers, edge computing, observability
- ⚡ Modernization - Legacy app transformation, CI/CD, feature flags
- 📊 Data - Amazon Aurora DSQL, real-time processing, vector databases
Each post in this series dives deep into one session, sharing key insights, practical takeaways, and links to the full recordings. Whether you attended re:Invent or are catching up remotely, these sessions represent the best of our developer community sharing real code, real demos, and real learnings.
Follow along as we spotlight these amazing sessions and celebrate the speakers who made the DEV track what it was!
Top comments (0)