Why users care about how you write code

December 23rd, 2019 — 4 min read

Why users care about how you write code
Why users care about how you write code
No translations available.Add translation

Back in October of 2011 Ryan Dahl wrote a blogpost entitled "I hate almost all software" in which he asserts:

The only thing that matters in software is the experience of the user.

I totally agree with this statement, but I believe that it has broader implications than Ryan's suggesting.

At a previous employer, I was asked to add a single checkbox and label to the contents of a popover. When asked how long this would take, I considered that the logic for that part of the app was in a Backbone view that was over 1,000 lines long and it extended another Backbone view that was over 2,000 lines long. I estimated it would take a week, and the PM was horrified. What's worse is it actually took closer to three weeks. 😱

Why did it take so long? The code was unmaintainable. I was able to add the checkbox easily enough, but getting the data from the checkbox to update the model was a nightmare. If that wasn't enough, the number of bugs I introduced with my hacky example was frightening because (of course) those files had leaky abstractions all over the place and absolutely no tests.

Now, consider if the component had been built with SOLID programming principles (DRY, SRP, etc. etc.). I probably could have finished that feature in a day or less.

So did the way the app code was written impact the end user? You betcha. Did the user care that they had to wait weeks rather than days for the new feature? Yeah, they totally cared.


So yes, it's true. The only thing that matters in software is the experience of the user. We created computers to improve our lives, and if the software we're using doesn't do that then it's failed.

The experience of the user is indirectly, but strongly coupled to how we build software

So the big question: Does it matter to the user that we're using the latest JS framework, build tool, const vs. let, semicolons, tabs, a git merging strategy, or a specific deployment service? Of course not!

Our measure of success should be how well we deliver what the user wants (and no more). Our choice of tools should be based on that fundamental goal.

At the same time, the latest tech and a good UX are not mutually exclusive. The latest and greatest technology can be a great way to accomplish this goal.

So why does this matter?

We waste time endlessly debating minutiae that has little impact — whether we should use semicolons in our JavaScript (no), or how many spaces to use for indentation (two), but we should instead focus on the tech choices that make a significant impact: solid design patterns, linting (only good rules please), testing, continuous integration, delivery, and deployment. These choices are the basis for an app that delivers a quality user experience. A great app is never truly finished. Requirements change, and our choices as developers determine how easily and quickly we are able to deliver new features, while keeping the product as polished as possible.

Optimize for change.

So yes, our users don't really care how we build our application, or what abstractions we use in doing so. Remember that we use JavaScript and the web because, with them, we can deliver an awesome experience to the user who doesn't want to download, install, and regularly update our app. If we found another solution to accomplish that better, we'd all jump ship.

User Experience includes a lot more than just base functionality. How your application is written, built, and deployed can make a big difference.

The real takeaway for you here is that you should be intentional about what you spend your time arguing about. Behind every opinion you hold firm, make sure your opinion is founded upon what's best for the people using your software. If it's not (or if that connection is tenuous), it may not be worthwhile arguing about.

I'll just add this because I have to: Delete eslint-config-react and eslint-config-airbnb and use eslint-config-react-app instead. Also... Use prettier...


Big thanks to the people who helped review and edit this post, especially Kyle Robinson for basically being the article's editor.

Kent C. Dodds
Written by Kent C. Dodds

Kent C. Dodds is a JavaScript software engineer and teacher. Kent's taught hundreds of thousands of people how to make the world a better place with quality software development tools and practices. He lives with his wife and four kids in Utah.

Learn more about Kent

If you found this article helpful.

You will love these ones as well.