The battlefield of software engineering
The world of software engineering is a battlefield divided by a deep philosophical chasm—on one side are “the purists”; on the other, “the practicals”.
“The purists" are obsessed with code itself, meaning they fixate on how a codebase looks and feels. They scrutinize every detail, ensuring everything is typed, tested, and adhering to “best practices”. As such, nothing gets a purist going quite like the "linting wars," where they debate whether tabs should be 2 spaces or 4, or if single quotes are superior to double quotes. The question is not whether the code is functional or achieves business objectives, but rather, "Is the code elegant? Is it as DRY (Don't Repeat Yourself) as it could possibly be? In what ways could it be made even more beautiful?"
Then there are “the practicals”. These are the engineers who see code as a means to an end, who believe code exists for one reason: to “get the job done,” whatever the job may be. Code is not an end in itself; it is subservient to a higher cause. The motto for these engineers is that a working system today is better than a perfect one tomorrow. (Obviously if a perfect system is truly coming tomorrow it’s probably worth the wait! But a perfect system is never coming. That’s the point.) For “the practicals,” the central concern is not the code itself but what the code does and how well it serves its greater purpose.
To reveal my cards (in case you couldn’t tell) I definitely tilt towards the practical side of the spectrum. I have enormous respect for a lovely chunk of code, but at the end of the day, I’m with Gergely Orosz: “The majority of jobs do not hire you to write the highest quality code...They hire you to solve their business problems very efficiently. Sometimes this means high-quality code. Sometimes not at all.”
One caveat: to become the best engineer you can be, I actually think you need to spend a little time in the “ivory tower” thinking about engineering as an end in itself, about code as craft. But if you’re wise you will keep near to mind that you must at some point return to the real world. Your code is in service of a greater thing: the business.
**Customers do not care what the code looks like. They aren’t buying your code; they’re buying what the code *does.***
Your primary objective as an engineer should be to ship:
- functional code
- that does not break other, existing code
- that is consistent with the rest of the project’s formatting
- that will hold up over medium-run
- at the fastest pace you possibly can
This means you must ship code even when it’s not perfect, even if it’s a little ugly in a few places or less DRY than it could be. It’s not that you are taking shortcuts or sacrificing quality for quantity. It’s that you are acutely aware of the trade-off of trying to make your code perfect. It’s that you’ve come to realize code is a means to an end. Little more.