>Instead of talking about quality, let’s talk about goals. We want to see whether customers engage with this new feature. We want to cut down how often our engi

>Instead of talking about quality, let’s talk about goals. We want to see whether customers engage with this new feature. We want to cut down how often our engineers get paged at 3am. We want the main features to be at most 3 clicks away. We want to communicate the value of the product in the first 5 minutes. Let’s talk about how our different goals interact. Maybe there’s a way to do it that gets everyone closer to their goals? Quality, in engineering terms, boils down to setting standards for your work, and then meeting them. You could argue the converse of everything in this article is true, or actually a good thing; in a way, Paul Graham's essay on taste does [1]. There has to be some system for evaluating work as "good" versus "not good". It's effectively writing specs for company operation. It sounds like the author has been a victim of either vague standards or poor prioritization. It's pretty clear how either scenario would thoroughly suck to work for. [1]http://www.paulgraham.com/taste.html http://www.paulgraham.com/taste.html