Hacker News Reader

Comment by munchbunny | Hacker News Reader

I don't think it's that software engineers don't value it. I think we all understand, to some degree, that building resilient, simple software that solves the problem thoroughly requires incredible investment into carefully thinking through the problem and constant upkeep. It's just that we don't want to believe it because getting from 80% to 100% requires boring grind that we'd rather spend building something new and exciting, or because getting from 80% to 100% requires time we could spend building 80% of something else we want to sell.

View on HN

For me it's that 1) most people won't even care and 2) someone is going to ruin it anyway, eventually.

I've observed a cognitive dissonance that I can't quite put my finger on. You'll work with (and for) people who have an extreme admiration for Apple products because of the attention to detail and quality. And yet they are perfectly fine churning out terrible technology products in order to make a buck. Often times just little attention to detail can make a huge difference; you don't need to be a zealot about it.

Loosely related: I've found that I've made the most money while working with bad teams on terrible technology products. And I've made the least money working with great teams on great products. I really hate that.

I suspect a lot of the noticeable difference between Apple products and the normal stuff that most other companies churn out is the zealotry. Steve Jobs was notorious for being zealous about the small details. Tim Cook was notorious for his very high standards for operations, expecting even minor operations problems to be fixed very quickly and very thoroughly. Other companies do pay a little attention to detail, if you're observant you can see small details everywhere [1]. Apple is known for zealously taking it to the next level.

My point is that I think you do need to be kind of a zealot about it to be comparable to Apple. Most companies and employees aren't prepared to be zealots about it, which isn't that surprising to me because it's a lot of pressure and effort. One might admire how efficient Amazon is at retail compared to everyone else without admiring the sweatshop-style labor evidently needed to achieve it.

[1] aside: there's a fun Twitter feed for this kind of stuff https://twitter.com/littlebigdetail?lang=en

By the time you grind to get that 100% perfect solution, the number of requirements the business has put on you in your backlog has extended well beyond what you can keep up with. It's not like software engineers are the only actors in a software system. They are reactive to the needs of product development who are reactive to the needs of customers. You have to balance your limited development resources against a constantly changing set of requirements.

So you make trade-offs.

I was gonna say that!

curl and ffmpeg are definitely commendable "100%" FOSS projects, but they aren't chasing new features. HTTP3 is big, but it's not like curl had to break HTTP 1.1 compatibility to add it. AV1 is big, but it's not like MPEG1 will ever change. Both projects deal in protocols, which means most of their requirements are literally set in stone, or silicon.

Whereas youtube-dl is constantly breaking _only_ because YouTube is constantly breaking, probably on purpose to thwart youtube-dl.

Why spend the other 80% of my time adding armor plating and documentation to a feature that will either be gone or half rewritten next week?

Yeah agreed. There's a big difference between the base layer utilities and the application layer interfaces.

> YouTube is constantly breaking, probably on purpose to thwart youtube-dl.

I don't think they're trying to thwart youtube-dl, because there's so many low-hanging-fruit countermeasures that they don't employ. youtube-dl can download a playlist with hundreds of videos at 1000x playback speed. You can't tell me that's not distinguishable from regular users going through the website.

What's more likely IMO is that the constant changes that ytdl is catching up with are caused by good old CADT (Cascade of Attention-Deficit Teenagers) inside Google, driven by their infamous "build over maintain" culture.

Personally I don't like facing the work to take something from 80-100% - I envision the potential work and I can see it laid before me, extending beyond the horizon. And sometimes that work doesn't even lead to a certain success.

I realize that more often than not it would likely lead to improvements and a better state of the world. But it can feel overwhelming at times. Whereas working on a shinier smaller thing brings feelings of gratification that much easier and faster.

Reply on news.ycombinator.com