It's Not Enough To Build Great Software that Solves Problems

It’s always been my personal belief that good software developers are always curious and excellent communicators. Great software developers build on those soft skills by identifying problems and delivering reliable, scalable, performant software that solves those problems. But that’s not enough to truly distinguish yourself. Your solution doesn’t provide value unless people are actively using it to solve real problems.

”If a tree falls in a forest and no one is around to hear it, does it make a sound?”

I recently reread Jason Cohen’s article The Code is your Enemy. The context of the article is directed mostly at developers turned founders. But I think there’s valuable information that applies to all software engineers because engineers should be acting more like business owners. That leads to the two missing pieces of why it’s not enough to build great software that solves problems: the problem needs to be tied to business objectives, and the solutions can’t hide in the shadows.

Tinkering away, constantly innovating and iterating, and making small, tiny changes that compound over time is the dream of software builders everywhere. Engineers can probably identify a task that would provide some type of value: a refactoring for better maintainability, a new test, a new function to help provide more information, and maybe a feature gap in the product they are working on. And boy, oh boy, is sitting down at a computer and cracking away at the code on these issues satisfying. But to what end?

A new test or function could help catch a valuable bug, or you might have enough coverage to be confident already. A refactor could help deliver a new feature faster, or it could be mindlessly moving code around. A new feature could be a great boon to feature adoption, or it could be something that customers don’t care about. So, how can you tell if what you’ve decided to work on makes sense or not? You have to start talking to your customers and stakeholders.

Customers and stakeholders (depending on your role, a project stakeholder might be your customer) might come to you with product ideas or features to work on. However, implementing them blindly is a great way to not understand the value of your work. By talking to the customers/stakeholders, you’ll better learn what the goals of the users are, what the business objectives are, and what the real problems to solve are. Maybe their original ask makes perfect sense. Or maybe you’ll find that what they want can be solved in a better way. Either way, you need to start talking.

Ok, so you’ve spent multiple recurring sessions talking to customers and stakeholders. You understand their wants and needs. You’ve identified the problems they want to be solved. You have an ideal solution for them. You go off and implement this solution. You know that it will be super valuable. It’s perfect…

But then, crickets. No one uses it. No one even notices.

It’s not enough to just build something valuable if no one knows about it or how to use it. You need to actively promote what you’ve built. Developers need to be their own marketers—making sure the value of their work is seen, understood, and used. That might mean writing technical documentation that helps people leverage your solution, creating blog posts that explain why your feature solves a key problem, holding office hours to get direct feedback and answer questions, or even speaking at conferences to further accelerate the reach of your work.

By talking to stakeholders and customers, both existing and new, throughout the lifecycle of the project, you deepen your relationship with them. You build trust. And more importantly, you move beyond shipping new code and towards shipping new value. And at the end of the day, that’s a software engineer’s job—build great software that solves problems and delivers realized value for others.