There's a pervasive anxiety in the software industry. It's the feeling of never being good enough, of working late with the constant worry that what you just shipped will explode in production. It's the pressure to go faster, even when you know you're sacrificing quality. It's the frustration of feeling unprofessional, of never quite reaching a state of sustainable, high-impact work. Many of us have been there, living with this constant, low-grade stress.
But there is a better way. There is a path to professional tranquility that also delivers greater business impact. It doesn't come from a new framework or the latest methodology, but from a fundamental shift in how we think about our work. After nearly three decades in this industry, I've come to rely on five counter-intuitive but powerful mindset shifts.
1. Stop "Building" Software. Start Cultivating It.
One of the most damaging ideas I've encountered in our industry is the metaphor of software development as construction. We talk about "building" applications like we build houses. This metaphor is flawed, and it is the root cause of immense dysfunction.
It's harmful because it implies a static, finished product. A house, once built, is largely done. This mindset separates the "building" phase from a supposedly smaller "maintenance" phase. It leads to the absurd but common belief that software must be thrown away and completely rebuilt every few years.
We need a new metaphor: software as something that evolves, like a garden or a living system. It must be cultivated and guided. The single greatest advantage of software is its malleability, its ability to change. The construction metaphor negates this core strength. We are not masons laying permanent bricks; we are gardeners tending to a system that must constantly adapt to its environment.
If we saw the nature of software as something more evolutionary, as something that is alive, as a system that we are modifying all the time... that metaphor seems to me to be much more in line with the real nature of software development.
2. Your Most Valuable Contribution Might Be the Code You Didn't Write
Our industry often rewards the wrong things. Résumés are filled with lists of technologies used and massive projects "built." Productivity is mistakenly measured by the quantity of code written. More features, more complexity, and more lines of code are seen as signs of progress.
The truth is that true impact often comes from simplification. The most valuable work an engineer can do is often invisible. It's achieving an 80/20 solution that delivers most of the value with a fraction of the effort. It's proposing a simpler path that avoids a six-month project. It's having the courage to delete a feature that adds more cost than value.
Every feature, every line of code, has a "basal cost", an ongoing tax on the system. It adds to the cognitive load for new developers, increases maintenance, and creates friction that slows down all future innovation. The best engineers are masters of preventing unnecessary complexity. Their biggest wins, a disastrous project averted, a legacy system retired, will never appear on a performance review, but they are immensely valuable.
3. Agility Is a Strict Discipline, Not a Free-for-All
The word "Agile" has been misinterpreted to the point of becoming meaningless in many organizations. Teams use "delivering value" as an excuse for shipping shoddy work at high speed. For others, "being agile" has come to mean "anything goes", no documentation, no planning, no rigor.
This interpretation is a complete departure from the concept's original intent. True agility is a difficult and demanding discipline. It is not a shortcut or an excuse for chaos. It is a rigorous commitment to practices that enable sustainable speed and responsiveness.
In my head, agility is equivalent to a discipline, and a difficult one at that... a discipline of "Hey, I'm going to write the test first, then I'll do the implementation, then I'll refactor, I'll even eliminate functionalities that aren't useful." It's actually a tough discipline.
This discipline is embodied in concrete, systematic practices. On the technical side, it means Test-Driven Development (TDD) as the foundation for design and quality, Continuous Integration (CI) and Continuous Delivery (CD) to enable rapid, safe deployment, and continuous refactoring to keep the codebase simple and maintainable. On the product side, it means applying Lean Product Development principles to validate ideas before committing to full implementation, running experiments to test hypotheses, and ruthlessly prioritizing based on real user feedback.
But as the above highlights, it's not just about additive practices. It's also a discipline of subtraction, of proactively controlling technical debt before it becomes a crisis, of simplifying systems even when they're "working," and of removing features that don't add value. The goal is to maintain agility, both from a technical perspective (the codebase remains easy to change) and from a product perspective (the team can pivot based on what they learn).
These are not optional extras; they are the very foundation of agility. They require an uncompromising commitment to quality, because it is only through high quality that we can earn the ability to move fast, adapt, and innovate sustainably over the long term.
4. Individual Performance Metrics Are a Trap
There is a growing and dangerous trend of trying to measure individual developer productivity with simplistic metrics like the number of commits, pull requests, or story points completed. This approach is devastating. In 2023, McKinsey published an article proposing a framework to measure individual developer productivity using metrics like "contribution analysis" and "inner/outer loop time spent." The response from the software engineering community was swift and unequivocal. Kent Beck, creator of Extreme Programming, called it "absurdly naive," while Kent Beck and Gergely Orosz wrote a detailed rebuttal explaining why such frameworks do far more harm than good.
The problem isn't just with McKinsey's specific approach. It's with the entire premise of measuring individuals in a collaborative discipline. This is a direct application of Taylorism, the management philosophy developed by Frederick Winslow Taylor in the early 1900s for factory work. Taylorism treats people as interchangeable resources to be optimized locally, decomposing work into specialized tasks and measuring each person's individual output. It took manufacturing 50 years to move past this thinking. Yet in software development, a creative, knowledge-based discipline where these ideas are least effective, we continue to apply them universally.
When you incentivize local optimization through individual metrics, the negative results are entirely predictable. As W. Edwards Deming taught, over 90% of an organization's performance is a result of the system, not the individuals within it. But individual metrics create perverse incentives that optimize for the wrong things. We reward behaviors that are easy to measure but destructive to the whole: a high number of commits (encouraging smaller, more frequent check-ins regardless of value), celebrating people for "being 100% busy" (even if they're blocking others), or lionizing "heroes" who constantly put out fires (often of their own making). These incentives inevitably lead to chronic bottlenecks, constant rework, and a toxic hero culture where knowledge is hoarded and collaboration is discouraged.
It is devastating because it promotes individualism in a profession that is fundamentally about collaborative problem-solving. It discourages essential practices like pair programming because it makes it harder to assign "credit." It optimizes for busy-ness (output) instead of actual business results (impact). As Beck and Orosz point out, measuring effort and output is easy, but it changes developer behavior in ways that work against the outcomes that actually matter.
Software development is a team sport centered on learning. The true measure of performance is the impact and health of the team. The most valuable person on a team would often score terribly on these individual metrics. They might be the "glue" that holds everyone together, the mentor who elevates the skills of others, the person who prevents bad code from ever being written, or the engineer who just deleted 10,000 lines of obsolete code, making the system simpler for everyone. Their contribution is profound, yet these metrics would render them invisible or, worse, label them a poor performer.
5. Don't Ask for Permission to Be a Professional
Too many engineers wait for permission to do their job properly. They see quality practices like writing automated tests as something they need to negotiate or justify to management. This is a fundamental mistake.
You don't ask your manager for permission to use a for loop or a recursive function; you use the right tool for the job because you are a professional. Writing tests is the same. It is a non-negotiable, foundational part of professional software development, not an optional feature you need to bargain for.
This responsibility extends beyond just testing. Your job is not merely to execute instructions. It is to solve problems. That means taking the initiative to understand the "why" behind a feature, respectfully challenging requirements that don't make sense, and proposing simpler, better solutions. This isn't overstepping; it is the very core of engineering. By taking this professional responsibility, you build trust, earn autonomy, and position yourself to make a real, lasting impact.
Conclusion: A More Sustainable Future
The key to a more sustainable, impactful, and professionally satisfying career is to abandon the "construction" mindset. When we stop thinking of ourselves as builders of static artifacts and start seeing ourselves as cultivators of living, evolving systems, everything changes.
This single shift in perspective is the thread that connects all five of these principles. It leads us to value subtraction over addition, to embrace discipline over chaos, to measure team impact over individual output, and to take ownership of our professional standards. It is the path away from anxiety and toward durable, meaningful work.
The arrival of AI does not invalidate these principles; it reinforces them. If anything is going to change, it's that these mindset shifts will become more critical, not less. When we can generate code faster than ever, distinguishing between building and cultivating becomes more important than ever. When AI can produce features at unprecedented speed, knowing what NOT to build becomes the differentiating skill. The tools evolve, the disciplines adapt, but the goal remains constant: sustainable impact over time, real value delivered, and complexity kept under control. Now we have new tools and evolving disciplines, but they're still pursuing the same fundamental objective.
What is one "construction" habit you can challenge in your team this week to start cultivating your software instead?
References
- Stop Building Waste: 6 Principles for High-Impact Engineering Teams Eduardo Ferro (2025)
eferro.net/stop-building-waste
A complementary piece exploring how to maximize outcomes while minimizing software complexity. - Perverse Incentives, Predictable Results: When Your System Sabotages Your Teams Eduardo Ferro (2025)
eferro.net/perverse-incentives
Explores how Taylorist thinking creates perverse incentives in software development and offers systemic solutions. - Measuring developer productivity? A response to McKinsey Kent Beck and Gergely Orosz (2023)
Kent Beck's version | Gergely Orosz's version
A detailed rebuttal to McKinsey's framework, explaining why measuring effort and output damages engineering culture. - Yes, you can measure software developer productivity McKinsey (2023)
mckinsey.com
The original McKinsey article proposing individual developer productivity metrics. - Basal Cost of Software Eduardo Ferro (2021)
eferro.net/basal-cost-of-software
Introduces the concept of ongoing cognitive and maintenance costs each feature adds to a system. - Extreme Programming Explained: Embrace Change Kent Beck (1999, 2nd Ed. 2004), Addison-Wesley
- Software has diseconomies of scale – not economies of scale Allan Kelly (2015, revised 2024)
allankelly.net/archives/472 - The Most Important Thing Marty Cagan (2020), Silicon Valley Product Group
svpg.com/the-most-important-thing
