For posterity, I didn't want to change anything about the actual game itself but knew beforehand that the commands were difficult to figure out organically. To try and help modern players, I added an introductory heading when you start playing informing the player that this was a text adventure game and that "help" would give them a basic list of commands.
Watching people attempt to play it in the logs, it became painfully obvious no one read the heading, at all. Almost no one ever typed "help". They'd just type tens of invalid commands, get frustrated and quit.
Is that like the "players" who send HTTP requests to my mail server?
I'm not refuting the fact that people seldom read, but this seems like an interesting additional vector to explore.
'Thanks for the doc, let's set a meeting' (implied: so you can read the doc aloud to us ) is the bane of my existence.
Most people have an adversarial relationship with software: it is just the pile of broken glass they have to crawl through on the way to getting their task done. This understanding is reinforced and becomes more entrenched with each next paper cut.
Nowadays everyone can generate a 20-page RFC/ADR and even though you can tell if they are LLM generated, you cannot easily reject them based on that factor only. So here we are spending hours reading something the author spent 5 min. to generate (and barely knows what’s about).
Same goes for documentation, PRs, PRs comments…
"What you have done this week is remind the people of Earth that wonder is worth chasing. That curiosity is the most human thing we have. You didn't just test a spacecraft -- you tested mankind's potential...”
What we are doing is probably not in training data, maybe that’s why.
Mini-article is from 2007.
At the time, more reports were generated than humans could read. People weren't reading them for good reason.
I suspect author is more annoyed about people being (grossly) negligent in reading important things.
[0]: https://www.joelonsoftware.com/2000/04/26/designing-for-peop...
But also, I have a somewhat mentally ill (as in he takes medication for it) coworker that sends rambling extra-long emails, often all one paragraph. If I can't figure out what he's asking by reading the first couple and last couple of sentences I ask him to summarize it with bullet pouts and it actually works. Lol.
This principle applies to the following:
- User documentation
- Specifications
- Code comments
- Any text on a user interface
- Any email longer than one line
Not blog posts or comments. IronicSo if the read of the Miller principle is interpreted as read+understanding (it should) an interesting deeper discussion can happen.
It can be invoked with a way more dramatic "None understands anything"
Good documentation is hard.
I'm a one-man-band so if I write code comments, I write them for future me because up to this point he has been very grateful. Creating API documentation is also easy if you can generate it based on the comments in your code.
Maybe rename it the Filler principle. Nobody reads mindless comments that are 'filler'.
I used to read a lot more in the past, not the case anymore..
I've heard this sentiment: "If you didn't even bother to write it, why should I bother to read it?"
But often there is real value there, and I sometimes force myself to cringe my way through the GPT-isms, to find the gems buried within.
Anyway, this is just projection. The Miller principle really should be "Miller doesn't read anything". I read plenty.
it's in there