--- title: The User Doesn't Care - But you should | daily.dev description: A rebuttal to the common software industry cliché that 'users don't care about your tech stack/testing/code quality.' The argument is that while users don't... canonical: https://daily.dev/posts/the-user-doesn-t-care---but-you-should-oecg0geee twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: The User Doesn't Care - But you should | daily.dev og:description: A rebuttal to the common software industry cliché that 'users don't care about your tech stack/testing/code quality.' The argument is that while users don't... og:url: https://daily.dev/posts/the-user-doesn-t-care---but-you-should-oecg0geee og:image: https://api.daily.dev/og/posts/oeCg0GeEe.png og:image:alt: The User Doesn't Care - But you should og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # The User Doesn't Care - But you should **[Lobsters](https://daily.dev/sources/lobsters)** · 3 min read · 0 upvotes · 0 comments ## Summary A rebuttal to the common software industry cliché that 'users don't care about your tech stack/testing/code quality.' The argument is that while users don't directly observe code internals, they absolutely experience the downstream effects: bugs, slow fixes, delayed features, and poor performance. The post draws analogies to other engineering fields (bridges, aviation, construction) to show how ignoring second-order effects is dangerous. It also suggests the cliché persists partly as an ego defence mechanism for developers who aren't skilled at writing good code. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Community take How the wider developer community reacted, aggregated from 2 discussions and 37 comments across lobsters, hackernews (as of 2026-08-07). **TL;DR:** Most commenters agree with the post's core argument that code quality, testing, and maintainability have real downstream effects on users, even if users can't articulate them. A minority push back on the framing, noting the cliché is often misread and that over-engineering is a real counter-risk. **Sentiment:** 60% positive · 30% mixed · 10% skeptical **The case for** - Users do experience the second-order effects of poor code quality — bugs, slow fixes, security breaches — even if they can't name the cause. - Maintainable software pays off because fixing bugs and adding features in a clean codebase is faster and cheaper over any multi-month timescale. - The 'users don't care' line is often deployed in contexts where there are no feedback mechanisms or usage metrics, suggesting the speaker doesn't actually care about users either. - Measuring software cost only by ship date, and ignoring lifetime maintenance, systematically undervalues quality work. **The pushback** - The cliché has a legitimate, charitable reading: focus on outcomes (product works) rather than dogmatic adherence to a specific testing ideology. - Some engineers over-apply quality concerns — optimizing non-bottlenecks or demanding 100% coverage — and the phrase is a useful corrective in those cases. - Accountability structures, not ego, are often the real driver: teams are punished for not shipping, not for technical debt that surfaces months later. - Customers have become habituated to software not working, so market pressure to reward quality is weaker than the post implies. **By community** - lobsters (positive): Strong agreement with the post's thesis, with the most-upvoted comments emphasizing that 'users don't care' is frequently a cover for cutting corners, and that security, performance, and maintainability all eventually surface as user-visible problems. - hackernews (mixed): Commenters broadly accept the argument but push back on the ego-defence framing, preferring an accountability-structure explanation, and note that over-engineering is a real failure mode on the other side. **Hottest debate:** Whether the 'users don't care' cliché is primarily an ego defence mechanism (as the author argues) or simply a shorthand for misaligned accountability structures that reward shipping over long-term quality. **Open questions** - How should teams practically communicate the value of invisible quality work — testing, refactoring, security — to non-technical stakeholders and management? - At what point does advocating for code quality tip into over-engineering or procrastination, and how do you draw that line? - Will the flood of LLM-generated low-quality software eventually train users and businesses to demand and reward reliability? **Highlights** > i think there's a good and a bad way to deliver those sorts of lines (or a good/bad way to read them) like, "Customers don’t care about your testing at all. They care that the product works." testing is one of the ways you ensure your code works. there are useful ways to interpret this line: - if the tests have high coverage, and pass, and the product doesn't work, you've still failed - if you find ways of making your product work other than testing, it's fine - if your testing doesn't follow formal doctrines, but it still catches the bugs, it's fine part of the line is "the product works". you still have to achieve that, to satisfy the customer. the line is not literally saying "ship bugs", it's saying "focus on not shipping bugs, rather than your specific test ideology" then, from the user and business's perspective, "product/feature doesn't exist" is also a bug. i mostly agree that fixing existing bugs takes priority over shipping features, but it's not always a clean separation between bug and (missing) feature then on the other hand, i've heard some of these lines delivered exactly as the author is complaining about, where it meant "cut corners and ship garbage" > — [hc on lobsters · 25 points, 2 comments](https://lobste.rs/s/vufbvv/user_doesn_t_care_you_should#c_rly3mg) > To be honest, people uttering these phrases often strike me as people who don't really care about the user either. As is already pointed out, one of the ways to ensure users get a product that works is to have the things in place in the development process that makes this more likely. [Something I mentioned in a comment a few days ago](https://lobste.rs/c/1bafex). I encounter this sentiment also often in scenarios where conveniently the users have no good ways to give feedback about the product and no real usage metrics are in place either. Then there are a multitude of failure scenarios the user might not see or immediately care about when using the product but do impact them. Security being a prime example, the user doesn't care about your product not being secure at all, until they find their data in a data dump online. Performance might not be perceived as an issue by users until they realize it could be a lot better. > — [creesch on lobsters · 18 points, 1 comments](https://lobste.rs/s/vufbvv/user_doesn_t_care_you_should#c_jtruxq) > I do like this take. While I don't want to go to the other end of the spectrum, over-engineering, I often wish we move away from the "move fast and break things" mindset. In my experience, it is a plague in the web development world. I hope that the inflow of bad quality software LLMs are enabling will encourage the users to reward reliable software. I am slowly turning into the grug brain dev, so it's hard to tell if it's a widespread feeling, but I am exhausted of the "let's add another feature". We often make the mistake of measuring the cost of software by the 'ship date', never including the maintenance costs it will bring over its lifetime. "Shouldn't be hard, less than a week to build!" never state the 2 to 4 weeks a year to maintain, fix, extend, update, integrate, document... > — [aloys on lobsters · 5 points](https://lobste.rs/s/vufbvv/user_doesn_t_care_you_should#c_hrhawd) > > It's profoundly facile to think that only first order effects matter. Yet this is an incredibly popular folk belief in software. Why? > So I think partly it's an ego defence mechanism. I don’t subscribe to the idea that it’s a folk belief, or that it has to do with ego. I don’t think anyone truly believes “the user doesn’t care” is sufficient justification for anything. It’s about accountability. “The user doesn’t care” is shorthand for “On this team, we’re held accountable for not delivering, not for the results of decisions that only materialize a month or two down the road. We don’t pay attention to how we got to where we are, we fight fires as they pop up.” > — [nlawalker on hackernews](https://news.ycombinator.com/item?id=48440011) > *then, from the user and business's perspective, "product/feature doesn't exist" is also a bug* Author here. What I perhaps didn't tackle explicitly is that I completely reject the notion that shitty programming is at all "pragmatic" on any time scale that can be measure in months. Making new features in poorly designed and poorly tested codebases is slow and expensive. > — [LAC-Tech on lobsters · 5 points, 1 comments](https://lobste.rs/s/vufbvv/user_doesn_t_care_you_should#c_ne8xsj) **Source threads** - [lobsters](https://lobste.rs/s/vufbvv/user_doesn_t_care_you_should) · 69 points · 25 comments - [hackernews](https://news.ycombinator.com/item?id=48433973) · 29 points · 12 comments ## Similar posts on daily.dev - [Things Software Developers Think They Don’t Need to Care about, But Can Impact Their Job](https://daily.dev/posts/things-software-developers-think-they-don-t-need-to-care-about-but-can-impact-their-job-0q5n22hvj) · InfoQ · 0 upvotes · 0 comments --- Tags: [#company-culture](https://daily.dev/tags/company-culture), [#technical-debt](https://daily.dev/tags/technical-debt) [View this post on daily.dev](https://daily.dev/posts/the-user-doesn-t-care---but-you-should-oecg0geee) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"The User Doesn't Care - But you should","url":"https://daily.dev/posts/the-user-doesn-t-care---but-you-should-oecg0geee","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/the-user-doesn-t-care---but-you-should-oecg0geee"},"datePublished":"2026-06-07T17:53:12.077Z","dateModified":"2026-08-07T22:26:37.706Z","description":"A rebuttal to the common software industry cliché that 'users don't care about your tech stack/testing/code quality.' The argument is that while users don't...","image":"https://media.daily.dev/image/upload/s--P4t4XyoV--/f_auto/v1722860399/public/Placeholder%2001","thumbnailUrl":"https://media.daily.dev/image/upload/s--P4t4XyoV--/f_auto/v1722860399/public/Placeholder%2001","isAccessibleForFree":true,"articleSection":"Lobsters","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Lobsters","logo":"https://media.daily.dev/image/upload/s--tl8v_Fku--/f_auto,t_logo/v1698841318/logos/lobste.jpg","url":"https://daily.dev/sources/lobsters"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/the-user-doesn-t-care---but-you-should-oecg0geee","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"company-culture,technical-debt","timeRequired":"PT3M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Lobsters","item":"https://daily.dev/sources/lobsters"},{"@type":"ListItem","position":3,"name":"The User Doesn't Care - But you should"}]} ```