Previous Entry Share Next Entry
Binti: Home (Binti, book 2) by Nnedi Okorafor

Binti: Home (Binti, book 2) by Nnedi Okorafor

Also posted at Dreamwidth, where there are comment count unavailable comment(s); comment here or there.

  • 1
"I would love to say shoddy documentation practices are an example of the implausible ideas SF authors use to make their plots work but my phone company uses the same “let the users share their pooled wisdom” approach in Binti: Home. I understand the attraction from the service provider point of view but do not care for it."

'The documentation was lost, hidden, destroyed, incomplete, maliciously altered, untranslatable, mistranslated, failed to cover something because it was outside of spec, or just not there at all' is an Ur-plot, and has only gotten more plausible with time. There is *so* much you can do with it, with a bit of creativity.

It is also likely to be something almost anyone who is reading for pleasure in the first place can personally identify with.

See also "we didn't include that detail because surely it's obvious."

8-) And "no one would ever want to use it *that* way"

One of my colleagues has recently retired. This is a real shame for me, because I ran every instruction document I wrote past her; she had an extraordinary ability to pick up every ambiguity and interpret it the wrong way. I can only hope I've learned to spot them myself now.

I recall reading a story about electronics development in the dark ages: one company's engineers had realized that while they weren't user interface experts, by the same token the girls from the typing pool weren't electronics engineers. (This was so long ago that there was a typing pool and it contained 'girls.') So after building a prototype they'd call in a secretary to use it, thereby discovering what they'd done that was obvious to engineers but not normal humans. Apparently they only got about three gadgets out of any given secretary before she'd catch on and get too skillful at translating Engineer into Human.

We are translating all our documents from Engineereese to Simplified Technical English. It's a structured approach to instructions that forces engineers to write in clear, unambiguous sentences. Unfortunately, it was made necessary after several plane crashes.

Just a few months ago I was trying to help a student get a Java-based project running on a Windows 10 machine. It turns out that Windows 10 causes Java to lag like whoa, throttling it down to 6 fps or so. It overclocks the processor to a degree unprecedented on any other machine, including previous Windows machines. But you'll only discover this if you Google and find complaints by startled Minecraft players, all of whom have shared a) unofficial bootstrap workarounds b) the silence from both Microsoft and Sun.

Presumably both tech companies are following the traditional "if we ignore this problem it doesn't exist and then in ten months we'll quietly roll out the solution so you see we were right it didn't exist after all" model of tech solutions.

(I feel like I should say, this is not an endorsement of Java, which has its own problems.)

... and, curiously, this trope is itself not documented over at TVTropes. ;^)

[I kid: the Entire Internet is recursively iterated over at TVTropes.]


I'm a little surprised to discover there doesn't seem to be a category for tropes about documentation. Although I wasted some time on the RTFM page...

Nooo, I am trapped now ...

Thanks for the link to Kobo!


  • 1

Log in

No account? Create an account