I understand the author's frustration, and I don't think it's misplaced, but the "world of tech" is wide, and the description, while veridical, is perhaps a lit

I understand the author's frustration, and I don't think it's misplaced, but the "world of tech" is wide, and the description, while veridical, is perhaps a little narrow-sighted, or confined to too small a portion of this industry. There are fields (we all know what those are) where, indeed, "if you aren’t embarrassed by the first version of your product, you shipped too late." Those fields are recognized for anything but quality, and this attitude is precisely why LinkedIn is the profitable (for a handful of people) but despised piece of shit that it is. If your aim is to get as rich as Reid Hoffman, by all means make that a credo. Otherwise, ignore them and the people who think there's any value in that sort of thinking. In the meantime, there are a lot of other fields in "tech" where if you're embarrassed by the first version of a product, that's usually a sign that it's going to be scrapped because getting it on the market RIGHT NOW is going to get someone killed, literally, and it's in such a bad shape that by the time you patched it up into a state where it doesn't kill people, no one is going to need it anymore. Not that blunders don't happen (eh, Toyota?), not that this always results in beautiful code that would make Knuth himself weep tears of joy. Like with everything man-made, there's a lot of room for imperfection, but perpetually shipping beta-quality software (oh, sorry, I meant continuously deploying and improving software delivered as a service) is not cultivated. There's a lot of "ugly code" in these things as well, but for different reasons. "Beautiful code" isn't pursued for its intrinsic aesthetic qualities, it's a result of the pursuit of quality design, of "proper" engineering. It doesn't happen because programmers have a thorough understanding of beauty, it happens because they're encouraged to understand the problems they're solving from many angles, to come up with solid solutions that are going to work two years from now, too (upper management not having selling the company for a decent price within the next 18 months as their main objective helps a lot here) and so on. Certainly, having time to properly implement code helps as well, but most of the super Agile shops I've seen couldn't produce ten lines of good code even if they had an ice age and a half for it. Not because their programmers wouldn't have time, but because they're constantly battered to ship code whose only virtue is that it can be quickly patched up to The Founders' latest whim. Unsurprisingly, when you optimize for things without technical value, you end up with code that's technically crap. There is a place in tech for people who think that products that sell for their intrinsic quality, not just their smart timing, are both possible and a goal worth pursuing, or for people who want to work on things where quality is a prime concern. There are companies that try to pursue that as well, even though, like everywhere in the Western world, their main objective is to make money. The idea that the two are somehow mutually-exclusive is popular, but not universally revered, and companies that don't adhere to the "move fast and break things" mantra need programmers, too.