> And since anticipating all outcomes is by definition impossible, Norman's advice is awful.

Yes, that's why I said that I read the advice as saying it should only be followed when you can provide help and insight. You don't have to do it in an all-or-nothing way.

You can have common problems with a helpful flow that tells the user how to fix them. You can have less-common problems which just show an error code. Removing the error without providing help is the problem here, and is the thing that I feel goes against the book's advice.

For the example you gave, as a user, what would you do with "Error: 0xFHJAD1234"?

The best you could do is report it to Apple (or whoever). But, the error alone doesn't achieve anything. You would have been better off with "Something broke, click here to send log to Apple." (which is roughly what the book recommends - replace the error with something actionable).

I have copied-and-pasted the strangest of kernel errors, compiler errors, god-knows-what-obscure-tool errors, etc. over the past 20+ years into search engines and have almost always been delighted and amazed at how somehow someone somewhere at some point in time had not only encountered the same thing but actually wrote a description of possible root causes and potential solutions that often unstuck me right away. The success of a site like stackoverflow is exactly this.

It turns out that if you actually do take the time to report the error, no matter how obscure it is, someone in a dark corner of the internet will spend enough time on it that they'll even see fit to document it for others to help their own selves out. And given that, per my initial post, nobody is smart enough to understand how the computer system/software they're creating is going to work under all circumstances, providing error verbosity is sometimes the most empowering thing you can give to your users.

I call it "Somebody Else Has Had This Problem". It's a heuristic that became useful starting about twenty years ago, eh? Before the internet you had to have (and write) fairly complete manuals for software, now you put the error message into a search engine and, hopefully, amortize the suffering.

However, I suspect this has also made it easier to write and (kinda sorta) maintain larger and more complex systems. Like the phenomenon where you widen a road to ease traffic congestion and it works for a while but then encourages more traffic. The reduced cost of creating and maintaining complexity may have encouraged it overall.

- - - -

As an aside, can I quote you, like, on my blog?

> in my line of work I have to be able to walk engineers I work with from the gate-level silicon all the way up to cloud and AI. Without any false modesty, I think I have a fairly good idea of how modern computer architecture works. Yet, I will be the first to tell you that I have no idea how any of these systems work in full. In fact, no one does. Not the best of kernel developers nor the best of chip designers. To claim that you can somehow inventory every possible problem in a computerized system and then provide a graceful exit from that or useful info is either ignorant or arrogant or both.

That's an interesting take. Thanks for sharing. Sure, I can definitely see the "google this error" effect as having permitted a higher degree of complexity. Or, maybe to be more accurate, lowered the barrier to entry to create more complex systems. There are probably pros/cons to this. It takes less sophistication to build something very complex, thereby democratizing the ability of building sophisticated systems/services, but it also means there are many more complex systems out than there is a community of people who have a more-or-less "good" understanding of what they do and, possibly, whose overall behaviour is likely only partially understood by their own designers. Cue in all sorts of security implications, etc. Food for thought.

I don't mind the quoting, but, just in terms of mental hygiene, I generally dislike posting unequivocal opinions on the internet ... because it's often come back to bite me ;) I'm especially skeptical of my own writing when I use labels such as "ignorant" or "arrogant". So long as you understand that I don't take myself very seriously, I mostly stand by that quote you mention.

No, the best that you can do is paste it into Google.

Giving a user an error ID gives them a partially-if-not-completely unique identifier that they can then use to find other people struggling with the same error and possible solutions.

This is infinitely better than having no error message and having to try to type different permutations of your symptoms into Google in order to try to win search engine bingo.

Sure, if Apple quickly and responsively fixed issues, then you wouldn't need the error code. But, they don't! The problem is that "hide the error message and replace with actionable advice" only works in the idealistic case where the vendor will quickly fix the issue and/or the advice consistently fixes the problem. But, they don't, and it doesn't - the advice doesn't work unless implemented flawlessly - it's not robust.

The robust approach that will actually survive contact with the real world is "include an error message and ID code - even if you have to hide it behind a "more details" button".

Or worse, the fix suggestion being wrong: "Please try again later", when the root cause is a misconfiguration, so it'll never work until the configuration is corrected.

And if it's a program display it in some fashion where it can be selected so you can ^c^v it rather than have to retype it. Such errors are all too often displayed on non-selectable labels.

Bonus points to the mythical developer that includes a google-this button on the error display.

And then what? Is Apple going to receive the error log and dispatch a technician to your house to fix it?

In my experience sending crash data to software companies has never resulted in my satisfaction, nor has using some 'wizard' to diagnose an error. As alluded to above these systems are just not smart enough to actually know what's wrong. If the original programmers could create a fully automated flow to repair all error conditions then why bother notifying the user at all?

Apple doesn't have to lift a finger beyond showing an error message with some kind of identifier. The user isn't expecting an onsite visit anyway. They can go to the local Apple store and explain the issue to an employee there, instead of wasting time trying to reproduce the error.

If they're not tech-savvy (and you would never talk to Apple store employees besides at the checkout counter if you were), they likely won't be able to reproduce the error anyway. They'd fumble around trying to explain what went wrong, and the employee would run through multiple scenarios trying to reproduce it.

Interestingly, sending crash data to open source projects often results in timely fixes.

Sending them to large software companies does not have the same outcome. But then, that's certainly not a flaw with the format.

You are making the same error as the book: assume that every user is non-knowledgeable, helpless and stupid, and that no user has access to a trusted expert to help them (whether for free or for a fee). And by designing for that error, it will become true. And knowledgeable, capable and smart people will resent you for it.