Comment by thfuran
1 day ago
>When people say “users don’t care about your tech stack,” what they really mean is that product quality doesn’t matter.
No, it means that product quality is all that matters. The users don't care how you make it work, only that it works how they want it to.
I have never seen it used like that. I have always seen it used like parent said: to justify awful technical choices which hurt the user.
I have written performant high quality products in weird tech stacks where performance can be s bit tricky to get: Ruby, PL/PgSQL, Perl, etc. But it was done by a team who cared a lot about technology and their tech stack. Otherwise it would not have been possible to do.
This is a genuinely fascinating difference in perception to me. I don't remember ever hearing it used in the way you have. I've always heard it used to point out that devs often give more focus on what tools they use than they do on what actually matters to their customers.
There are developers who care about tech and not about product. They build toys.
There are developers who care about product and not about tech. They build things that just barely work.
There are developers who care about both. They build the stuff people remember.
I have often heard it used to create a (false) impression that the choice of tools does not affect things that matter to customers - effectively silencing valid concerns about the consequences of a particular technical choice. It is often framed in the way you suggest, but the actual context and the intended effect of the phrase are very different from that framing.
TFA uses the phase that way.
> What truly makes a difference for users is your attention to the product and their needs.
> Learn to distinguish between tech choices that are interesting to you and those that are genuinely valuable for your product and your users.
Would like to echo this. I've seen this used to justify extracting more value from the user rather than spending time doing things that you can't ship next week with a marketing announcement.
I've also seen it used when discussing solutions that aren't stack pure (for instance, whether to stick with the ORM or write a more performant pure SQL version that uses database-engine specific features)
> I have never seen it used like that.
Then you need to read more, because that's what it means. The tech stack doesn't matter. Only the quality of the product. That quality is defined by the user. Not you. Not your opinion. Not your belief. But the user of the product.
> which hurt the user.
This will self correct.
Horrible tech choices have lead to world class products that people love and cherish. The perfect tech choices have lead to things people laugh at and serve as a reminder that the tech stack doesn't matter, and in fact, may be a red flag.
Look at every single discussion about Electron ;)
"It's a basic tool that sits hidden in my tray 99.9% of the time and it should not use 500MB of memory when it's not doing anything" is part of product quality.
Only 500MB? Now you're being charitable.
Electron adds about 500MB to your memory requirements. If your software uses 2GB like Teams, the rest is on you.
3 replies →
Using 500MB of memory while not doing anything isn’t really a problem. If RAM is scarce then it will get paged out and used by another app that is doing something.
Borg3 slaps foldr with a spinning rust.
And now more seriously ;) Swapping aint fun. Sure, if it needs to happen, its better that out of memory error or crash, but still. Its not excuse to baloon everything..
And here, is my memory stats, while writing reply:
Commit: 288.13M (1%); Free Memory: 15.43G (96%)
9 replies →
I consider it a problem on my system and I will refuse to use your app if you disrespect my resources that way.
Businesses need to learn that, like it or not, code quality and architecture quality is a part of product quality
You can have a super great product that makes a ton of money right now that has such poor build quality that you become too calcified to improve in a reasonable amount of time
This is why startups can outcompete incumbents sometimes
Suddenly there's a market shift and a startup can actually build your entire product and the new competitive edge in less time than it takes you to add just the new competitive edge, because your code and architecture has atrophied to the point it takes longer to update it than it would to rebuild from scratch
Maybe this isn't as common as I think, I don't know. But I am pretty sure it does happen
>You can have a super great product that makes a ton of money right now that has such poor build quality that you become too calcified to improve in a reasonable amount of time
While it's true that that can be partially due to tech debt, there are generally other factors as well. The more years you've had to accrue customers in various domains, the more years of decisions you have to maintain backwards compatibility with, the more regulatory regimes you conduct business under and build process around, the slower you're going to move compared to someone trying to move fast and break things.
> No, it means that product quality is all that matters
But it says that in such a roundabout way that non technical people use it as an argument for MBAs to dictate technical decisions in the name of moving fast and breaking things.
> product quality is all that matters
I don't know what technology was used to build the audio mixer that I got from Temu. I do know that it's a massive pile of garbage because I can hear it when I plug it in. The tech stack IS the product quality.
I don't think that's broadly true. The unfortunate truth about our profession is that there is no floor to how bad code can be while yet generating billions of dollars.
If it's making billions of dollars, somebody somewhere is getting a lot of what they want out of it. But it's possible that those people are actually the purchasing managers or advertisers rather than the users of the software. "Customers" probably would've been the more correct term. Or sometimes "shareholders".
As far as I can tell the article has been misinterpreted causing much lost hours by HN commenters. By saying users don't care about your tech stack, it is saying you should care about your tech stack, i.e it matters, presenting some bullet points on what to keep in mind when caring about your tech stack. Or to summarize, be methodological, not hype-following.
Agree the article is not clearly presented but it's crazy to see the gigantic threads here that seem to be based on a misunderstanding.
If users care so much about product quality why is everyone using the most shitty software ever produced — such as Teams?
For 99% of users, what you describe really isn't something they know or care about.
I might agree that 99% of users don't know what they want, but not that they don't care.
I feel like that's what it should mean, that quality is all that matters. But it's often used to excuse poor quality as well. Basically if you skinner box your app hard enough, you can get away with lower quality.
Yes, this is exactly what the article means.
"Use whatever technologies you know well and enjoy using" != "Use the tech stack that produces the highest quality product".
Well, the alternative and more charitable interpretation would be that you are more likely to build a better product in the stack you know well and enjoy.
I think when you get more concrete about what the statement is talking about, it becomes very hard to assert that they mean something else.
Like if you are skilled with, say, Ruby on Rails, you probably should just use that for your v1.0. The hypothetical better stack is often just a myth we tell ourselves as software engineers because we like to think that tech is everything when it's the product + launching that's everything.
I think the idea is that the use of a particular tech stack isn't a determinant factor in terms of product quality.
Tech stack and product quality are highly correlated in the real world.
1 reply →
!= "Use the tech stack that cheapest developers can work with".
(Yes, for real. I've once witnessed this being said out loud and used to justify specific tech stack choice.)