Second advice. If you want to pretend that quality matters, move to aerospace, finance, or any critical systems.

Third advice. It's not enough to fix bug, everyone MUST know that you fixed that weird bug that customers were complaining about for years and noone could understand the cause.

> If you want to pretend that quality matters, move to aerospace, finance, or any critical systems.

The important word here is pretend. If the system is safety critical you'd think that quality matters. It doesn't. What matters is following the process laid out in ISO 26262 or whatever standard applies to your field. Whether or not that improves quality is not important (it does, but only a little). The important part is that you have reduced/no liability for accidents if you can prove that you did everything by the book.

Yep, part of the quality standard for medical devices is to have processes, and also processes to improve and change the processes. So theoretically there shouldn't be any doubt as what to do in a given circumstance when something fails, and that standards would rise as development matures. But in reality it's just a bunch of paperwork, and as far as the software is concerned, standard practices of unit and integration testing, code reviews, and strict compiler settings are more than adequate already.

Edit: It's all about documenting that those things have been done and signed off on, so keeping track of paperwork.

Testing, review, history of changes... many things that are completely unheard of in the average small development shop.

I'm on the last few pages of this book:

https://en.wikipedia.org/wiki/What_Do_You_Care_What_Other_Pe...

...where he talks about his role and questions regarding the Challenger shuttle disaster; I don't know if things have changed much since then at NASA, but I suspect they haven't, given Columbia and such.

Mmmyes, but the process implies a heavy chain of verifications. So even when there has been an idiot and a lazy guy, at some later stage in the process, it has to go through someone who cares at some point and it gets fixed at that point.

After all, that is the point of those heavy processes: manage to product something fairly reliable despite the acknowledged presence of morons and shitty managers. The process does not try to eradicate those people, it works around them with some kind of redundancy.

Having been one of those 'concerned' people, I must admit it is exhausting. You know that if some work comes from this guy, or that company, it will be 90% shit and you have to explain them again and again what is wrong and how to fix it, or do it yourself when you are really fed up. So basically you do your job + the slackers' job. That is how the system works. As a system, the result is not too bad. As far as individuals are concerned, however...

Exactly. A prime example of this is the “quality” software at financial companies.

They care about loosing money and risking to lose money.

andai.depression++;

And make sure to record it so that at the end of your yearly review cycle, and before the raises are decided, you can remind your upper management of your notable accomplishments.

Either it's easily perceived as bringing value or it won't have any effect.

If you have to remind people of it, it's as good as not existing in the first place.

I disagree. A year is a long time, and a valuable, difficult achievement in February may raise your prestige for a while, but by December that's faded to background levels. I even forget my own achievements from nine months ago, never mind those of a dozen other people on my team.

The question is always:

> What can you do for me or have done for me recently?

Services provided so far in the past that need to be reminded are at best irrelevant and it can actually hurt you to bring them up.

I'm not saying that it is nice, only that humans behave individually and (even more collectively) according to this.

So at my annual review in December I should only be assessed on work in the last quarter? I guess I'd better save my best work for November.

Depending on the attention span of your particular managers (and their managers as well, most likely), this can indeed be a viable strategy.

You might also carefully consider your company's culture when deciding how to split your efforts between new (user-visible) features, preventive maintenance, and bugs affecting end users (especially any VIP end users that have your managers' ears).

For example, a 'Hero' culture rewards last-minute, late night, death march efforts, whether to fix an urgent problem, or to add that one feature that is (supposedly) needed to land a specific high-value customer/sale.