Why Aristotle Is Your New DX Consultant
You've tried Agile coaches, productivity gurus, and that one guy who swears by inbox zero. Have you tried a 2,400-year-old Greek philosopher?
Somewhere in your organization, there's a developer who reads the documentation, attends the training, passes the certification, and then writes the same garbage code they wrote before. They know the right way. They just don't do the right way.
Aristotle saw this coming.
In the Nicomachean Ethics, written around 340 BCE, Aristotle made an observation that should be tattooed on every DX team's whiteboard: "We become what we repeatedly do." Excellence isn't an act—it's a habit. And habits aren't formed through knowledge transfer. They're formed through practice.
This is where modern DX gets it catastrophically wrong.
The Documentation Delusion
Most DX teams operate like they're running a publishing company. Ship the docs. Update the wiki. Record the training video. If developers still aren't following best practices, clearly they need more documentation.
But Aristotle would point out the obvious: knowing is not becoming.
You can read every book on swimming. You can watch Olympic athletes stroke-by-stroke. You can pass a written exam on hydrodynamics. None of this matters until you get in the water and flail around for a while.
Developer skills work the same way. Reading about test-driven development doesn't make you a TDD practitioner. Writing tests daily—badly at first, then better—makes you a TDD practitioner. The knowledge is a prerequisite. The practice is the transformation.
The Doctrine of the Mean (Or Why "Best Practices" Is a Lie)
Aristotle introduced the concept of the doctrine of the mean: virtue exists as a balanced middle ground between excess and deficiency. Courage is the mean between recklessness and cowardice. Generosity is the mean between prodigality and stinginess.
Here's the kicker: the mean cannot be prescribed in advance.
What's courageous for a firefighter is reckless for an accountant. The right amount of generosity depends on your wealth, the recipient's need, and a dozen contextual factors. There's no universal formula.
Now think about "best practices" in software development.
How much testing is enough? Too little and bugs slip through. Too much and you're testing getters and setters while the product stalls. The mean depends on your domain, your team, your risk tolerance, your timeline.
How much documentation? Too little and new hires flounder. Too much and it rots faster than you can maintain it. The mean depends on your turnover rate, your system complexity, your communication culture.
DX teams that prescribe "best practices" as universal rules are doing Aristotelian malpractice. The job isn't to hand down commandments. It's to help teams find their mean—the balance that works for their specific context.
Legislators of Habit
Here's where Aristotle gets really useful for DX.
He observed that legislators form citizens by shaping their habits. Good legislators create laws and structures that make virtuous behavior easy and natural. Bad legislators either don't try, or create structures that inadvertently train vice.
DX practitioners are legislators of habit.
Your CI/CD pipeline, your default templates, your code review process, your error messages—these aren't just tools. They're habit-forming structures. Every day, developers interact with them, and every interaction trains a pattern.
If your build takes 30 minutes, you're training developers to batch commits, avoid running tests locally, and context-switch during builds. That's not laziness. That's Aristotelian habit formation in action.
If your error messages say "Something went wrong" with no context, you're training developers to add print statements everywhere, distrust the system's feedback, and develop superstitious debugging rituals.
Lazy legislators make bad citizens. Lazy DX teams make bad developers.
The 30-Year Question
Aristotle wasn't interested in quick wins. He was interested in eudaimonia—human flourishing over a lifetime. What kind of person do you become through decades of practice?
DX teams should ask the same question: After 30 years in this environment, what kind of developer emerges?
Are they masters who still love their craft? Or burned-out cynics who stopped growing at year five?
The answer depends less on individual talent and more on the soil quality—the environment they practiced in, day after day, habit by habit.
Aristotle wouldn't be impressed by your developer satisfaction survey. He'd want to know what character your environment is forming. Are you cultivating wisdom, or just extracting labor?
The Uncomfortable Conclusion
If Aristotle ran your DX team, he'd probably make everyone uncomfortable.
He'd spend less time shipping tools and more time observing actual practice. He'd care less about adoption metrics and more about whether developers are becoming more capable over time. He'd push back on "best practices" documentation and insist on context-specific guidance. He'd measure formation, not satisfaction.
And he'd remind you, every day, that the developers you have tomorrow are being shaped by the habits your environment trains today.
We become what we repeatedly do.
What are your developers repeatedly doing?
Next in series: "We Become What We Repeatedly Do (And Your CI Pipeline Knows It)"