Being highly dogmatic does not make you perfect.
Ten years ago, I stood in front of a room full of agricultural business stakeholders, proudly presenting an elaborate technical framework that absolutely nobody cared about. That moment changed everything I thought I knew about successful software development.
Photo by Erick Butler on Unsplash
One of the most challenging lessons I’ve learned in my software engineering career centers around developer perfectionism—that tendency to set down principles as incontrovertibly true. Even today, as a technical leader where people look to me for guidance and assurance, I still wrestle with this challenge.
Blueprints vs. Buildings: A Critical Distinction
What I’ve discovered is surprising: most software development projects don’t actually require rigid, dogmatic principles to be successful. This might sound counterintuitive, but the criteria for success in many projects isn’t necessarily rooted in having a high-quality codebase.
Photo by Kseniia Samoylenko on Unsplash
Just because you wrote a really excellent codebase does not mean you’re left with good software. While code quality and philosophical consistency are crucial elements of maintaining excellent code, they don’t automatically translate to a high-quality software product.
This distinction between code quality and software usability is crucial.
A codebase is merely the infrastructure that creates an application – it’s like the blueprint, not the building itself. At the end of the day, what matters to users is the application, not the codebase. The codebase facilitates the application but isn’t the application itself. This is a stumbling block that many developers, including myself, have tripped over.
A Humbling Leadership Lesson
Let me share a story…
I had just started my first role as a lead developer. I launched into an extensive discussion about technical choices: Tailwind vs. Bootstrap, React vs. Angular… all from the mindset of a developer chasing perfection.
Photo by Ben White on Unsplash
This project showed me how wrong that assumption was. While I was deep in the weeds of technical frameworks and paradigms, my audience included project managers and business stakeholders who cared about creating a usable product. My technical focus created a disconnect between what I was saying and what was actually needed.
The situation was further complicated because we were collaborating with the client’s existing development team. In laying out our company’s fundamental principles for how the software should be built, we failed to consider their perspective and preferences. This revealed another critical flaw in dogmatic thinking: the assumption that your way is the correct way.
Looking back, I realise I was focused on developer perfectionism—assuming that great code naturally results in great software. But software usability and end-user value weren’t part of that narrative.
Engineering Is the Art of Compromise
What I’ve come to understand is that software development leadership is fundamentally about compromise—in time, in code quality, and in philosophy.
Engineering is inherently a discipline of compromise. If you tried to create the most perfect software product in the world, you’d probably never finish it.
This has become one of the most important lessons of my career: in software development, there’s no room for dogmatism. Principles, philosophy, and rigid rules must all remain flexible and negotiable. Our job as software developers isn’t to create the perfect codebase – it’s to create the best possible software application within our real-world constraints.
Our job isn’t to create the perfect codebase—it’s to deliver good software that works in the real world. That means setting aside perfectionism in favour of progress.
Leading with Context, Not Dogma
Today, when I mentor new technical leads, I share this fundamental truth: our ultimate measure of success isn’t the elegance of our code, but the value we deliver to users. This doesn’t mean abandoning technical excellence – it means pursuing it thoughtfully, within context.
Here’s what this looks like in practice:
Photo by Vidar Nordli-Mathisen on Unsplash
First, start every project by understanding what success means to your stakeholders, not just your development team. Then, maintain open dialogue about technical tradeoffs, explaining them in terms of business impact rather than philosophical purity. Finally, approach technical decisions with flexibility, asking “What serves our users best?” rather than “What’s technically perfect?”
A decade after that humbling presentation, I’ve learned that true technical leadership isn’t about enforcing rigid principles – it’s about making informed compromises that balance code quality with real-world constraints. When we let go of dogmatism, we free ourselves to build software that doesn’t just satisfy our engineering principles, but actually solves problems for the people who use it.
Today, I teach new technical leads:
- Define what success means for stakeholders
- Speak in terms of business value, not frameworks
- Ask, “What serves our users best?” rather than “What’s technically ideal?”
This is how we escape developer perfectionism and build software that matters.
What was the humbling experience that changed how you approach technical leadership? How did it reshape your perspective on balancing technical ideals with practical needs?
Leave a comment