/ Programming

The human side of writing good software

A maintainable codebase, the holy grail of every software architect’s dreams. For some engineers, it’s something we obsess over: a harmonious construct of easy-to-modify code, a product that can we can remold to the changing requirements of our customers. Unfortunately, the “business reasons” for investing time into writing good software are less clear and often misunderstood.

Flexibility has always come at an expensive cost: time. We’ve found practical, quantifiable ways to justify a focus on maintainability: reduced hours fixing bugs, faster iteration cycles, quicker on-boarding of new developers. Even still, it can be a hard sell when there’s a looming deadline.

For me, these examples aren’t the reason I reach for better patterns in the first place, it’s happiness. Humans with emotions build software. Enjoying the code we work with is inherent to driving us to build faster. While the logical reasons may be true, they’re self-justification for our true motive.

As software leaders, keeping developers happy is one of our jobs. When changing existing code is harder than it should be, happiness evaporates. This is exactly what good software design can help us avoid.

Building a system with change in mind improves your ability to solve technical problems and the long-term morale of your team. As a manager, yes, your goal is to maximize output of your team. Sometimes you will have to scramble and cut corners. But ignoring the experience of how people feel while building on your team is a mistake. You can’t pay off this emotional debt by hiring fun coworkers or landing sweet office perks. Those are distractions from the real problem: your developers don’t like their actual work. You can fix it investing engineering time into making everyone’s job simpler. Developers are more productive when they fully understand and appreciate the implementation they’re working with. Ignoring this just erodes your team’s output.

Give your team an unfair advantage and take bets on writing good software. Your team (and your boss) will thank you for it.