Hacker News Reader

Comment by happytoexplain | Hacker News Reader

I think the difference is that the entire software/hardware stack is a world created entirely by humans, untouched by "reality" for the purposes of all these annoyances, so it feels like we should be able to wrangle it better after so many decades. It's entirely our own creation, and we decide every iota of it, and yet it bites us (justifiably or not - turns out thousands of people each creating different layers of a gigantic state machine is hard to perfectly coordinate, but we may have been able to do better by now if we had been more thoughtful and patient throughout).

View on HN

I hear you, but feel like we are biased by what we accepted as normal in our formative years, and that filter doesn’t apply on what we are discovering now that we’re grown up professionals.

For instance books have been with us for centuries, and honestly most of them suck. Paper pages are thin and sometimes cut your finger (how many times did you get cut by an ebook ?), most are weak to liquids yet our world is filled with liquids everywhere, sometimes coming down from the sky. Updates are painful and costly and non scalable. Font sizes can’t be changed, you have to use an external device to deal with it.

Not saying there are perfect alternatives or that the tradeoffs don’t make sense. Just that we learned very early that books have these limitations and we’ll need to live with them to be a member of society. And we can agree all of these aspects could be and sometimes are fixed, but most people are just ok with books ‘sucking’ in those ways.

We’ve also had centuries to improve the technology of books and I think that makes a difference.

Although the weaknesses you cite seem like problems in search of a solution. No one ever expected books to have variable font size ... why would they?

Lastly let’s recall the book five hundred years ago is dramatically different from the book of today. For example your point about liquids is now in many ways resolved by the cheapness and ubiquity of books. 500 years ago, not so much.

While nobody expected books to have variable font sizes, the fact that ebooks do allow it to be adjusted means that people with deteriorating vision may still read them.

A magnifying glass was the original solution to this problem. They never run out of battery.

And you can use any glass with any book!

In the early days of the Gutenberg press when most were illiterate, they would gather together and the one person could read would read to the rest of the group. So, arguably, it was both easier and more inclusive for a blind person to read what there was to read then than now. At least they didn't have to rely on any special accommodations.

Yeah... and once you're no longer paying by the page there's really little upside to using a small font you have to squint at or use margins that are too narrow to easily scan the page. I have no idea how long the books I read are, but I probably read them a few hundred words per screen simply because it's way easier to keep my place. Average for a small paperback exceeds 300.

It's worth noting that it took 75 years after Gutenberg's press before some disgusted printer came up with the idea of page numbers. As the saying goes, all progress depends on the unreasonable man, who eventually becomes disgusted enough to make things change. Quality matters, pride in design and workmanship matters, and it's not at all bigoted to point out that China, which now manufactures most of the stuff in our 21st century world (or at least the components of it), has a culture of designing and producing absolute dung. We should not accept unacceptable quality just for apparently low prices.

On book font size, there actually is a market solution for the issue: if enough sales are expected the same book (same content) will be sold in different formats, pocket size, deluxe paperback, standard edition etc.

Same for translations, with even books with dual languages side by side.

I find fascinating how the arrival of ebook readers made us rethink how we relate to books, and a lot of annoyances got surfaced only now because there was no comparison point before. My favorite is how you cannot ignore the length of a book while reading it: you can’t pretend not realizing there’s only a dozen pages left and the story must come to an end.

Books are also capable of being copied before or when damaged, passed on trivially, and are not prone to sudden existential failure because a server on the other side of the world was deactivated.

They can't be stolen back by the publisher or seller, can be trivially transformed into different formats, can take annotations, can be rebound with wear, and even if paper has it's faults, reading a page of a well maintained page in 1000 years is as easy as as the day it was written, even if significant swathes of technological backslide occur, and is only prone to the challenge created by human cultural evolution as opposed to loss of the processor or software required to decode/convert/display it.

An HDCP protected chunk of media may as well not exist in 1000 years.

> I think the difference is that the entire software/hardware stack is a world created entirely by humans, untouched by "reality" for the purposes of all these annoyances, so it feels like we should be able to wrangle it better after so many decades.

Humans, as the makers of these systems, are part of that reality, which was not created by us. The reality is that we are great apes writing precise machine instructions with our general intelligence that was not purpose built for being that precise but selected for survival. Our cognitive machinery cannot exhaustively predict all the possibilities of failure of what we write, if we are working in teams, we have transfer most of our technical ideas still through natural language, in a combinatorially increasing manner as the team size increases etc. None of this is user hostile, it is just human fallibilities and limitations in play. And since we can't alter our cognitive capacity drastically, we can only make more machines against these (e.g. unittests) with their own limitations. I think the scale of what we have been achieving despite these limitations are just fantastic.

If anything users are becoming too egocentric, expecting the world to conform to their comfort, with a dash of construal level fallacy, underestimating from a mile away how easy it would be to write bug free programs with perfect designs in a real world, by real people, with real budgets etc.

> If anything users are becoming too egocentric, expecting the world to conform to their comfort, with a dash of construal level fallacy, underestimating from a mile away how easy it would be to write bug free programs with perfect designs in a real world, by real people, with real budgets etc.

Selection bias. You only hear from users who want new features. You rarely hear from users who don't want new features and just want software to stop being buggy and acting like a goddamn haunted house.

I was talking about the “users who don't want new features and just want software to stop being buggy and acting like a goddamn haunted house.” so the selection bias is yours.

Most bugs are just annoying, consequences are not catastrophic if your favorite tuner app forgets your settings, your word processor messes up the formatting, your pdf reader crashes. You can recover with some frustration and wasted time. The perception of these being catastrophic failures shows the sense of entitlement users have because they are used to a certain smoothness in their experience and expect everything to go their way. This doesn’t match the underlying realities of the task; it is very easy to construe a sense of a working program in one’s mind but it is exponentially difficult to make the implementation actually bug free, usable and functional the way user wants.

> Most bugs are just annoying, consequences are not catastrophic if your favorite tuner app forgets your settings, your word processor messes up the formatting, your pdf reader crashes.

So what? Users get upset when your crap doesn't work. Stop being flippant and pushing back. Pushing back is not your (our) job. Complaining how hard your job is not your job. Griping and moaning about irate users is also not your job. Delivering a product that does what is says it will do on the tin is actually your job. Believe it or not, you produce something people depend on!

Imagine your power steering goes out on left hand turns going north downhill. You take it into the mechanic and all you get is "That's just annoying, not catastrophic. You can recover with just some wasted time. It's exponentially more difficult to make the implementation actually bug free!"

Users quite rightly spot bullshit excuses. And we have none. Save the settings, fix the formatting, stop the crashing.

> Pushing back is not your (our) job

Please tell me more about my job internet stranger.

You’re making the same arguments without adding substance, just emotional rhetoric and unnecessary personalizing.

> Imagine your power steering goes out on left hand turns going north downhill.

Imagine that steering wheel stopped working depending on the highway you’re driving on (software & hardware platform). Why didn’t they test this on every single highway? Because that would be was combinatorially explosive.

I’m glad you’re making a physical world analogy. Comparable physical world projects have orders of magnitude less moving parts that need to interfit, and assembly gives immediate feedback whether they can fit. They also have orders of magnitude less inputs they are expected to operate on, which makes it easier to exhaustively test their function.

“Shut up and just make it work” might have been popularized by certain tech personas, but unless you have Steve Jobs levels of clout, pulling that stuff in most dev shops will quickly make you very unpopular whether you’re a IC, a manager or a product manager.

> Imagine that steering wheel stopped working depending on the highway you’re driving on (software & hardware platform). Why didn’t they test this on every single highway? Because that would be was combinatorially explosive....

Users guffaw at this point. They do not understand why your stuff is so complicated and broken. They think you suck at your job. Both you in the collective sense (you engineers) and you in the personal sense. They start plotting ways to stop using your stuff because you are so frustrating to deal with.

> They also have orders of magnitude less inputs they are expected to operate on, which makes it easier to exhaustively test their function.

I think you still do not understand my point. Users fundamentally do not care about it. Everything, to them, is a problem of your creation and they'd quite rightly regard your long-winded explanations with complete skepticism. To you it always feels likes it's someone else's fault, but to users it sounds like complete BS. No matter how right you are about it being someone else's fault. Someone else's fault is the very definition of a lame excuse from their perspective. They are still getting nowhere and you are even more useless to them because you still can't fix anything and just confuse them and waste their time.

It's a very user-hostile attitude and makes for terrible customer relations. That attitude is also counter productive and helps no one. No wonder people hate tech.

Reality creeps in from us creating tech-utopia trough "legacy" systems where the internet, cryptography, multi-core architecture and full program isolation didn't exist yet.

Software has a nasty habit of iterating on yesterday's ideas instead of rewriting for tomorrow. Not that there's anything wrong with that, it seems to be the path of least resistance thusfar.

I disagree - by and large, we don't need to "rewrite for tomorrow". Almost every significant problem in Computer Science and Software Engineering was solved (well) decades ago, often in the 1960s. Security is a bigger issue now, but it was largely solved years ago.

The problem is that we do engage in so much "rewriting", instead of leveraging known good, quality code (or at least fully-fleshed out algos, etc.) in our "new, modern, elegant, and trendy" software edifices of crap.

To me, this may be the one really good thing to come of the cloud (as opposed to the re-mainframe-ication of IT): the "OS" of the 21st century, allowing plumbing together proven scalable and reliable cloud/network services to build better software. (Again, not a new idea, this was behind the "Unix Philosophy" of pipes, filters, and making each program do one thing well. Eventually, it will be in fashion to realize this really is a better way...)

We need smaller, better software, not the latest trendy languages, insanely complex platforms that no one understands, and toolchains of staggering complexity that produce crap code so bloated that it requires computers thousands of times faster than the Crays of the 1990s just to do ordinary desktop stuff. (Seriously, folks, the Raspberry Pi 4 on the next table is a rough match for the Cray we had in Houston when I worked for Chevron in the early 90s! Think about that, and then think about how little data you really need to deal with to do the job, vs what you're actually shuffling around.)

You reminded me of this quote.

“Einstein repeatedly argued that there must be simplified explanations of nature, because God is not capricious or arbitrary. No such faith comforts the software engineer.”

We probably could make gas stink less just like we could fix that bug. The ROI just isn’t there.

Gas stinking is a feature, not a bug. It's a safety measure. Particularly when we're talking gas (and not gasoline), which is naturally odorless and made to stink on purpose.

Reply on news.ycombinator.com