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"
There are plenty of engineers that say stuff like "you can never have too many unit tests", or who spend days optimizing code that's not even a bottleneck. Your interpretations are very relevant in such cases.
It's good for devs to be mindful of spending time where it adds value. And management should ideally understand why we do things. Lack of understanding but also incentive structures tend to lead to things like "cut corners and ship garbage"
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.
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.
This type of topic is difficult to articulate to a general audience. I don't think you can single out a factor and optimize on it with good results, like with any improvement process, but it's often the only way to stimulate progress in a discussion.
I think it helps to calibrate discussion with things like you mentioned, feeding pathways to actually get at what is visibly needing attention.
But, I think what posts like this are trying to do is to promote the ideation of the mutually exclusive visibility into factors that impact the success of a software project. I think it is a worthwhile exercise to articulate and advocate for what only those with the technical penchant are aware of. Unfortunately I believe most people with that technical penchant aren't able to balance the invisible work or advocate for it effectively. It's at least something I've been working on.
hc | 8 hours ago
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:
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"
bartz | 6 hours ago
There are plenty of engineers that say stuff like "you can never have too many unit tests", or who spend days optimizing code that's not even a bottleneck. Your interpretations are very relevant in such cases. It's good for devs to be mindful of spending time where it adds value. And management should ideally understand why we do things. Lack of understanding but also incentive structures tend to lead to things like "cut corners and ship garbage"
creesch | 7 hours ago
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.
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.
banna | 7 hours ago
This type of topic is difficult to articulate to a general audience. I don't think you can single out a factor and optimize on it with good results, like with any improvement process, but it's often the only way to stimulate progress in a discussion.
I think it helps to calibrate discussion with things like you mentioned, feeding pathways to actually get at what is visibly needing attention.
But, I think what posts like this are trying to do is to promote the ideation of the mutually exclusive visibility into factors that impact the success of a software project. I think it is a worthwhile exercise to articulate and advocate for what only those with the technical penchant are aware of. Unfortunately I believe most people with that technical penchant aren't able to balance the invisible work or advocate for it effectively. It's at least something I've been working on.
aag | 7 hours ago
This is such a good point! Taking care with the internals is important, and does, in fact, benefit the user.
diktomat | 5 hours ago
Just suggested adding „vibecoding“…