We like to imagine that you become a better Software Engineer by working exclusively on exemplary projects: testable, modular codebases that faithfully reflect the business domain, surrounded by seasoned mentors. It’s a virtuous circle, and it’s tempting to never want to leave it. Yet the more the years pass and the more projects pile up, the more convinced I am that it’s elsewhere, in the mess of “spaghetti” codebases and “big balls of mud”, that an essential part of technical expertise is truly forged.
The comfort of the virtuous circle
I was fortunate to discover software craftsmanship fairly early in my career, and therefore to surround myself with mentors who were highly experienced in these areas. One thing led to another, and I was naturally drawn to working with people who shared these convictions, and thus to working on projects and codebases of relatively high quality: code that reflects the business domain, that is testable, modular, and that lends itself well to evolution.
It’s a comfortable and formative environment. But the question has to be asked honestly: is it necessarily a good thing to want to operate solely within this virtuous circle? By only ever being around clean code, you eventually stop seeing what good practices were invented to counter. You handle solutions without ever having truly experienced the problems they solve.
Why chaos is a learning ground
It’s precisely when you arrive on a messy codebase that you encounter the greatest learning potential. Two dimensions stand out to me.
The learning potential
It’s there, in contact with bad design, that you become aware of the concrete impact of a poorly thought-out architecture: efficiency and productivity that collapse with every required change, a cost that climbs the moment you touch the code. Until you’ve experienced these problems from the inside, the solutions presented to you don’t really resonate. They remain concepts.
Pain is an irreplaceable teacher here. Until you’ve personally felt the friction caused by excessive coupling, by an absence of tests, or by business logic drowned in technical plumbing, most “good practices” remain theoretical and abstract. And it then becomes impossible to grasp the importance that Craftsmanship and all the associated disciplines hold within our profession.
The potential for collective satisfaction
The other dimension is more human. On this type of project, what you leave behind when you go is, almost by definition, in a better state than what you found when you arrived. You leave behind a codebase that puts the team in a position to succeed and be effective, rather than in a permanent struggle against its own code. And a team in a position to succeed mechanically means more chances of success on the business side. The satisfaction of that collective transformation is hard to match.
Chaos is no excuse to do things badly
There is, however, one non-negotiable condition, and it’s a major one. To sharpen your skills on big topics like refactoring, there’s nothing better than combining a genuine desire to improve with the theoretical and technical background that makes it possible to act on that desire, and being able to apply it to projects that desperately need it.
Without that foundation, chaos trains no one: it reproduces itself. A Software Engineer who lands on a messy codebase without that awareness and without that technical baggage will only contribute to the disaster, piling new layers of complexity on top of the old. Mess is only an opportunity for the person who knows how to read it, name it, and untangle it methodically. Otherwise, it’s just a trap.
The real condition: a continuous-improvement mindset
One last factor remains, and it’s decisive: the human environment. As long as the team’s mindset is aligned with continuous improvement and you can challenge the status quo, these projects turn into tremendous opportunities to continually become a better engineer. It’s that openness that makes all the difference between a refactoring effort and a solitary last stand.
Conversely, the best technical background in the world is worthless in a team that refuses to question its code. Chaos is only an opportunity where there’s a shared willingness to get out of it.
Conclusion
Technical excellence isn’t built solely under shelter, on already-healthy projects. It’s also forged, and perhaps above all, in contact with the mess, provided you arrive armed with convictions, with method, and with a team ready to move forward. As long as those conditions are met, I see these difficult codebases not as a chore to endure, but as an opportunity to grow. Chaos, approached with the right tools, is undoubtedly one of the best teachers this profession can offer.