Business value first, tooling second
Many software developers will list their exceptionally written code as a feature or benefit of their practice. They fawn over their functions, as a poet does his words.
Not me. My code f****** works.
Beautiful code is a luxury of the rich.
Companies that ride aloft the wings of venture capital or private equity can afford to spend time concerned about their Big O notation. (Yes, that’s a real thing.) They brag about how their microservice architecture allows tens of teams to work on the exact same file at the same time.
But you don’t have that luxury. Nor do I.
Mere mortals, like ourselves, must focus on reducing the amount of time that Beth spends on quarterly reports. We toil to make sure Timmy isn’t able to double-enter critical data. If that involves code, excellent. If we can avoid it, even better. We must achieve the mission with the fewest lines of code possible; no more and no less.
Code is a tool. It isn’t artwork. It isn’t a marvel to be admired or a philosophy to be sought. It is a tool to be understood, grasped, and improved for the sake of the business. It is an exceptional tool—one whose flexibility and power rival any other tool ever created. In the end, however, it is still a tool.
A plumber does not rave about how sturdy their wrenches are.
Nor does a carpenter brag about the sharpness of their saw.
You expect a professional to solve your problem, and you expect them to use the correct tool when needed.
You should also expect a software studio to solve your business problem, regardless of the tool or technique required to do so.
🔑 Key Takeaways
Software developers who brag about clean code are like carpenters who brag about sharp saws. It’s table stakes. It shows they may not be thinking about the real problem they’re solving.
Business value first, always. Then, if necessary, code.