Developer: "We don't need to write documentation. Users should obviously know what to give as input. "
Users:
Developer: "We don't need to write documentation. Users should obviously know what to give as input. "
Users:
@davidbisset Small correction on your alt text: Band saws don't use sawblades, they use a band hence the name :D
Due too the small size, that's probably a disc for an angle grinder or a really small hand-held circular saw.
Circular saw. If you want to keep your hands, don't ever mount this on an angle grinder.
Carbide tipped heavy metal 🤘
@davidbisset Reminds me of a conversation I had with the makers of the Vivaldi Browser. They allow Markdown formatting in the browsers' Notes facility. I asked if they could pop a wee guide or cheat-sheet in there to get people started, like a lot of text-input-heavy programs do.
"Oh, it's not up to us to describe Markdown."
"Not even the form of Markdown you've chosen to implement?"
"..."
If you aren't going to cater to users don't expect users to use what you're giving them.
;)
Slight variation:
Every time you try to idiot-proof something, they invent a better idiot.
@davidbisset remember to sanitize your users' input, kids!
(Oh and while you're at it, please refactor that SQL database code to use prepared statements. Yes, I know, but it won't get any easier in the future when it's even bigger.)
@davidbisset LOL! That tracks.
Although I would say that ideally writers should write the documentation as part of the development teams...

A friend who worked in tech support once told me he got a call from an irate customer complaining that his computer's CD tray wasn't working.
It turned out that he was using it as a mug holder and he was annoyed that the "hole" wasn't the right size.
From brainstorming to development, finding the ways to make an app as simple and intuitive as possible for a user is probably the most time consuming task.
@davidbisset
Tester: Here, I found another bug.
Dev: That's not a bug! No user would ever do that!
(...)
《Software is released》
User: Hold my 🍺!
@luca @davidbisset eh, it was the 1990s, I don't remember, probably some Power Metal band.
Maybe Primal Fear? the cd I have has that shape *printed* on the CD, and I've found that they did a shaped CD for other albums: scraperecords.com/product/prim…
I remember that limited edition shaped CDs were briefly a fad, but they were also a bit of a hassle and didn't work in all players (especially if they were unbalanced).

@davidbisset 🤔 reminds me:
There's a version of that called poka yoke in Japanese.
https://en.m.wikipedia.org/wiki/Poka-yoke
Colloquially:
mistake-proofing or idiot-proofing.
Ex: it's impossible to put a car's automatic transmission into Reverse while the car is moving forward.
For a poka yoke designed CD player, *only* a CD would be allowed to enter.
All other schemes require instructions!
(Or, sell it so cheaply that we can throw it away when it breaks: dollar store junk)
@davidbisset only as smart as your code, though. Isn't that what you want to test? 🤔
Seems kind of like Dunning-Kruger, but for tests. I don't see evidence, in the anectodal reports I've read, of chatGPT know it's own limitations. Quite the contrary, at times ;->
/cc @GeePawHill @jbrains
@deborahh @davidbisset @GeePawHill One of the most elementary forms of poka yoke in code regards designing statements that must follow another, such as "A must happen before B".
To enforce this constraint, let A produce a result that becomes an input to B. This way, there becomes an obvious way to compose the functions that preserves the required sequence.
Let's do more of that kind of thing.