Hacker News Reader

Comment by banana_giraffe | Hacker News Reader

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.

View on HN

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...."

It makes sense that new employees are trained on the job from actual line workers, rather than by reading documentation.

It is totally possible that the line workers have no idea what the documentation on the tooling says.

Makes sense in the short term, but not the long term, as the entire article makes clear

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.

If you haven't read it, you'd probably enjoy (and anyone interested in process) The Toyota Way by Liker.

Thanks!

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.

Reproducibility.

Have others come in and follow the directions.

It is genuinely impossible to document every lityle nuance that makes everything work.

Every time i am dealing in new hires, i realise how much we just take for granted

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.

Definitely, not perfect readme or documentation but at least that covers 70% of cases.

From the conversation, admittedly 20 years ago. Not documenting was highly intentional, and why I was being informed.

Reply on news.ycombinator.com