It's also possible it was "Hey! The foam injection machine isn't working, I've tried everything", "There's this string trick I used once, try that", "Great, that fixed it, we should document that", "Sure, once we get all parts made that have backed up"
Or, maybe I'm reading bad practices in my industry to everywhere else.
I've seen that way too many times. "Why doesn't this link in the internal console work?" "Oh, after you click it and get the error, you have to remove the trailing dash character and refresh." "Weird, I wonder how this slipped by Jared in QA when he tested it. We better let him know." "Don't bother, Jared is the one who showed me how to remove the dash...."
I would be very interested in reading case studies where a company both does documentation well and does not get bogged down in vast amounts of paperwork.
As yes, plenty of fixes for things are not written down anywhere.
Unfortunately, every company that I have been at that has tried to implant the Toyota Way just bolted additional processes onto their legacy ones, adding complexity.
No, the problem is that while you are writing documentation you are not making money for the company. I remember when I and Dave as the senior tech told our boss that we should put the most common repairs into a database so new hires would not have to ask us questions all the time.
He asked how long the job would take, and we answered about a week for all the common stuff. And his answer was, "That is a week you will not be making the company any money.".
We tried to explain the long term savings, but he was not interested.
I think the best way to think of this part of a wiki is as a cache for everybody's help. No need to pre-populate the cache, just start using it, and the most frequently used information will tend to be there.
Or, maybe I'm reading bad practices in my industry to everywhere else.