Many junior to mid-level engineers have misconceptions about what “good code” truly mean. Unfortunately, these misunderstandings are often reinforced by flawed hiring practices. LeetCode problems, parroting SOLID principles, or memorizing framework features might showcase technical knowledge, but they don’t inherently make someone a good Software Engineer.
Mess is Everywhere
Throughout my career, I’ve encountered my fair share of messy codebases. An example would be functions/methods that stretched over a thousand lines of business logic—an unmaintainable monstrosity. Such code is a hallmark of inexperienced teams and often plagues poorly managed software outsourcing projects. I’ve probably written my share of such code when younger too.
Seasoned engineers would say that this is “common.” Even at tech giants like Google or Microsoft, codebases aren’t pristine. Messes are inevitable, and documentation can also be inconsistent.
Still, there’s a difference between an unavoidable mess and a completely avoidable disaster.
If It Ain’t Broke, Don’t Touch It?
A few years ago, I was troubleshooting a particularly stubborn issue with another team. The tech lead said that adding more code to an already bloated, thousand-line controller method was risky. He wasn’t wrong—it could take days to figure out where to make even minor changes, and the risk of breaking something was high. To add to the problem, the codebase did not have unit tests.
But what happened next left me speechless.
The Undocumented, Untraceable Code
The tech lead decided to “solve” the issue by writing a standalone PHP script, completely outside the Laravel framework we were using. His justification? Frameworks were “too slow” and “too complicated.”
His script lived in some random folder on the server, undocumented and untracked. Hours of debugging later, we stumbled upon it by sheer luck. And it wasn’t a one-off—we later found there were several such scripts scattered across the server, mostly undocumented and introducing untraceable logic into production.
At that point, nobody cared about the quality of his algorithms (they were terrible, by the way) or whether his code followed SOLID principles (it didn’t). The real issue was far worse: he prioritized personal convenience over team collaboration. His decisions created a codebase that was not only a nightmare to maintain but also actively sabotaged the team’s ability to function effectively.
Coding Beyond Yourself
As software engineers, we don’t work in silos. Writing code that you alone can understand is easy. Writing code that a hundred others can maintain? That’s the real challenge.
The example above is a cautionary tale of what not to do. Good engineering isn’t about showing off your technical prowess; it’s about making thoughtful decisions that benefit the team, ensure long-term maintainability, and foster a culture of collaboration.
