I'd like to pedantically miss the point.

I love things that work well, and I think that despite the world of computing being criminally suboptimal, we seem to be making progress! Slowly. And I'm grateful for it.

The world is a surprising beast of incredible complexity, and I'm in love with it.

I agree that success is silent, but I don't think that means people don't appreciate things that work well. It's just that expressing that appreciation almost always sounds shallow. Of course it works well, that's obvious. Why bring attention to things we've solved, things we take for granted.

It's easy to notice things that don't work and use that observation as a tool to improve. It's much harder to separate the things that worked well by accident from the truly good designs.

Praise is a much more fraught art than criticism. You will see more of the latter.

A probably apocryphal story which i had heard but has stayed with me;

Thomas Edison is supposed to have made hundreds of failed attempts to get the filament of his light bulb working reliably before his first success.

A smart aleck reporter asks him; "Mr. Edison, don't you think you are more of a failure than a success given the ratio of your failed attempts to successful outcomes?.

Edison replied; "No, because i am the only person in the world who knows hundreds of ways of how NOT to make a light bulb filament"!.

There's a similar Toyota story, where the blueprints for a model of their automatic loom was stolen.

Toyoda was not shaken in the least by that, because in his view, the important information were all the failed attempts that lead to the design, and those weren't in the blueprints. "By the time they've taken their copy of that model to the market, we'll have innovated past that, and they won't be able to keep up because they haven't learned from our mistakes."

This is why it seems so hard to sell higher quality software in some cases. The party paying might not appreciate the invisible robustness, might underestimate the cost of failure or overestimate the ability of an operator.

Maybe there is a way to make those things more visible and clear?

To an extent it's your fault for taking the position and accepting the status-quo, my advise is to get hired where the manager has the same "standards" that you aspire to, if you assume you will be able to "raise the bar", you are not going to have a good time there. It's either already in the DNA of the company, or you will probably have to force it into your standards..

dgb23 makes an astute observation that the market (demand side) seems to undervalue SW robustness => writing robust SW has poor ROI => not a viable strategy, product will be outcompeted => company goes bust => DON'T DO IT.

That's a gross simplification of course. But even simplified thought experiments can be useful.

I'm puzzled by your reply though, about "having a good time" and "get a manager with high standards". How is that relevant to dbg23's point?

My observation is made from experiences, you are suggesting that if something is good for the market then that's where the market will go.. Unfortunately my experience is that decisions are made by individuals who have their own ORG politics to play out.. they don't really care about this "market"..

> I'm puzzled by your reply though, about "having a good time" and "talking to a manager". How is that relevant to dbg23's point?

I believe dbg23's point is coming from frustration of what needs to happen to get to this "success" as a software engineer ("to create higher quality software"), if one side believes it's good enough to have "meh quality software - but good sales team", I was sharing my thought on how to deal with this frustration..

I appreciate your response, above. For me it is less about employers and more about clients, and it is less about frustration and more about an open challenge.

So your advice can maybe translated as "fire your customer".

And I partly agree. There are two sides though. For one, as I'm growing and learning, I see more potential to make things better, more robust, more usable and long lasting. On the other hand we (small team) have a principle that we don't sell things our clients don't need, and we make that very clear and have said "no" in the past to adhere to that principle.

So it is really a balancing act of really understanding and communicating what technical and design quality means vs. understanding how providing it will positively impact our relationships and their goals.

I've been thinking more and more about this issue in recent years, because I realized that I/we cannot compete on quantity or speed, but rather on trust and quality if that makes sense.