Developers Should Use the Software They Write

A great developer isn’t just a coder; they’re a problem-solver with a strong grasp of the business’s needs. They don’t need to rely on a business analyst to convert requirements into rigid rules—they understand the intent behind the requirements. By interacting directly with the software, they develop a deep understanding of what the business wants and make real-time decisions that align with those goals.

A good example of this comes from a project where a developer was tasked with building a product detail page. The spec detailed a scenario where a user could customize a product before adding it to the cart, with specific instructions on what should happen if the user clicked the back button or navigated away mid-customization. But there was one problem: the existing design had no navigation option on the page—no way for the user to actually leave the page without closing the browser. Rather than simply following the spec as written, the developer reached out to the designer and pointed out, “Hey, we need a way for users to close this window. The business clearly wants users to be able to leave mid-customization; that’s why these steps are included in the spec.”

When developers engage with their own software, they’re more likely to catch issues before they ever reach the user. They experience firsthand what users experience, which gives them a unique perspective on areas that need improvement. Slow load times? Bugs? Frustrating navigation? Instead of just tolerating these issues, they’ll be motivated to fix them immediately.

Imagine a developer working on a requirement who notices a lag when switching between screens. Instead of ignoring it, they can improve it right then and there without waiting for it to become a reported issue. This proactive approach leads to faster and smoother software and better user experience.

Get in Touch