Ignoring Users is Killing Software Development
It sometimes feels that software developers are caught in an echo chamber of their own creation.
The insistence of software developers that they are a breed apart isn’t helpful when considering user feedback. It can turn software engineers into “us” and users into “them”, and this is deconstructive when feedback is crucial to solving user problems.
Here’s a deep dive into this cultural problem in software development and why it’s putting tech companies at risk.
The Disconnect
I’ve felt divides between developers and product, developers and HR, developers and users.
Developers can be isolated in tech-driven cultures where they are seen as at the top of the hierarchy, creating the value in the organization. This has led to curious situations, like the idea that only software developers can interview software developers (really? For behavioral interviews?).
This disconnect is wide between developers and users. Remember the Steve Jobs “you’re holding it wrong” debacle?
The war against users only got more intense from there. Software Engineers sometimes see users as little more than support tickets waiting to happen.
This is a bad attitude. The real end-users (not “the business” who dog food software before release) are paying for the ping-pong tables at work. If the users aren’t happy it doesn’t matter how cool the tech stack is. Someone needs to pay the bills, and that only happens when we respect the people who pay for all the tech coolness.
The Cost of Ignoring Customers
Imagine going to a clothing store, and you’re told, “No refunds, no exchanges, no trying on clothes.” Chances are, you’d walk out. Yet, that’s exactly how many developers treat their users: with an “all sales final” mentality, and who cares if you need support later.
The problem is that the companies who ignore the customer ultimately pay the price, and it’s not just in lost sales — it’s in trust, reputation, and brand loyalty.
You don’t get software developers who care about the product and the end user by hiring based on ability to solve algorithmic challenges, and who are penalized for showing any weaknesses. Obviously. Then you bear the cost of doing so.
Inside the Developer Bubble
There’s a joke in tech circles that software interviews aren’t much more than high-stakes timed LeetCode challenges. There is something to that, and then once they are hired engineers are pampered and treated like show ponies. Within companies, software developers are routinely judgemental and cruel to each other — get access control wrong in a pull request and you’ll experience “radical honesty”.
With these people in this insulated environment, it’s easy to start viewing users as annoying problems rather than as essential partners.
As software developers we are set up to treat work as a technical challenge and not necessarily a service to real people. Think about that when you’re getting your next coffee at work.
Why Developers Should Listen to Users
Good software development is more than just writing efficient code (shock). It’s about solving real problems for people — for users.
Yet because of the way developers work they are incentivized to blame the user rather than deal with feedback. Developers fight the feedback that users will give for free, and prevent the improvements that their products could see, if only developers listened.
So, imagine a world where developers could take user feedback to heart and act on it. Bugs and crashes could be seen not as annoyances but as feedback from the field, a chance to improve the product. If the industry embraced a culture of learning from users rather than dismissing them, imagine the impact on software quality and customer satisfaction (and the $$$ that would follow).
A Culture Shift Is Long Overdue
The reality is that the software development culture needs a shake-up. It’s time to recognize that software is ultimately about serving users, not just flexing technical muscles. When you’re logging a frontend crash, ask yourself: Am I blaming the user, the device, or the previous developer? Or am I looking for how this issue affects the end-user experience?
The way forward for developers is to approach their craft as problem solvers who work with users, not as technicians who work in isolation. Reviews and bug reports aren’t there to make developers feel good — they’re there to show us how the product performs in the real world and where it can improve.
Conclusion
The software development culture has become toxic due to the blame-first culture that has grown up in big tech.
Circling the wagons and blaming users, the industry needs to build a culture of openness, where developers respect users as co-creators, not as obstacles.
After all, isn’t that what this is supposed to be about? Delivering value to the user?