Hacker News Reader

Comment by hoherd | Hacker News Reader

At a previous company where I had a lot of this "tacit knowledge", I had made a policy for myself. Whenever somebody asked me a question over IM or e-mail, I would look in the wiki. If the answer was not in the wiki, I would write a new wiki article or update an existing article with the answer, and I would respond with a link to the article, and a statement like "if this doesn't answer your question let me know what is missing or could be described better." The reasons for this were for me to dump my tribal knowledge out of my brain into something everybody could search and read, and to promote usage of the wiki as a place where people found answers. Unfortunately it did not appear to have another desired effect of getting everybody to contribute content. I think this was probably because people came to see the wiki as a place to find knowledge, not to put knowledge.

View on HN

How do you keep your wiki from evolving into a kludge of random-ish info?

One example of tacit knowledge is knowing the Dell T420s Tower Servers have very poor cooling for the raid controllers and often, this can cook them over time, requiring replacement or, at least repasting the heatsink.

Now imagine 100s of those little tidbits. Useful, but hard to categorize.

Use an internal Q&A / Quora-style tool with good search. Trying to keep little snippets of info like that under useful MECE categories only ever ends in pain & frequent refactoring.

I don't want to get too much on the ai hype train - but it seems like this would be perfect for machine learning, trained on the wiki-snippets of the company and emails (initiator would have to set a flag saying this is going to be training data).

That would be a good use of LLM AI, imo. Good idea.

> machine learning

This is already kind of skewed by hype. It's not possible to teach a transformer architecture LLM the fact "Dell T420s Tower Servers have very poor cooling for the raid controllers". All that can be done is have a corpus of text where the statistically most likely text associated with a prompts about "raid controller cooling Dell T420" includes the text "Dell T420s Tower Servers have very poor cooling for the raid controllers", or some variant of it. But the model doesn't know that fact, or any other fact, so it's not being taught this knowledge.

Since this is the internet, I'm asking, not arguing...just this time.. ;)

In this context, can we assume AI would be a good internal wiki assistant/Mod?

It could make many data correlations, rapidly, and suggest or act upon migration/collation/etc of information into more useful groupings, with related information automatically indexed and grouped, based on the more commonly searched for terms that match data related, or tagged. This could/would evolve over time, assuming the same AI and a changing team/staff, terms, current in-use hardware, in this case.

A simplified version of what I'm trying to say might be, AI can't know a fact, but it could parse inputs and build relationships between bits of data, based on how the users access that data, and under what headings it's commonly searched for.

An AI, especially the parse/response loop of LLM AIs, seems almost custom built to find that input, and match it with similar/related inputs and store the information in a more effective way, under more commonly searched headings from the users searching the wiki.

Am I missing something?

> AI can't know a fact, but it could parse inputs and build relationships between bits of data, based on how the users access that data, and under what headings it's commonly searched for.

Yes, but so can text analytics tools that are not transformer model LLMs, and they can do it without thousands of swimming pools of water[1] or a gigawatt hour of electricity[2]. Those LLMs are just algorithmic summary generators, and text summarizers have existed for some time.

> find that input, and match it with similar/related inputs and store the information in a more effective way

But that's not how these automation tools work – they don't store information, they generate statistically likely text based on the training corpus.

1. https://www.independent.co.uk/tech/ai-water-energy-artificia...

2. https://spectrum.ieee.org/ai-energy-consumption

Sure. I get that AI doesn't "know" things.

My specific suggestion was about leveraging the parsing and response loop of LLM AIs to analyze free text, parse what's useful and the reply would be collating the data.

Thanks for taking the time to reply!

How can someone do this, concretely? I would love to slowly train an AI to fit the gap between search and one on one assistance, but I don’t know how to do it as a single person running an informative website.

That's what a wiki is good for: collecting snippets of hard to categorize information. If you've got a culture of recording those notes, then you can develop full text search habits.

A kluge of randomish info by people who make occasional attempts to organize and garden... sucks compared to a beautifully manicured knowledge base. But it's fantastic compared to a blank wall and a shrug.

Even this ends up very messy.

The first problem I commonly see is called "Delores Thesaurus". It turns out people find like 50 different ways to say the same damned thing. Maybe with LLM based sentiment search we don't have to be so exact in how people ask the same question?

Also this information getting stale or out of date commonly leads to people not going back and gardening because of the massive amount of work involved, such as adding versioning when you figure out there are 10 different product behaviors over time.

Put it in the runbook for the alarm you got when the server failed, or the maintainance guide that your team runs through every month. Or make heatsink repasting a regular documented process, or something similar.

Basically, as Toyota says, build quality _into_ each part of the product rather than layering it on top by documenting discrete pieces of info that an operator has to discover, understand and act upon

I'm a fan of the toyota approach, but sadly, Dell isn't. lol

I'll review the runbooks. We have a number of them, mostly created by me. :)

Not OP, but you have to regularly review and adjust the ontology regularly as more articles are added.

In short, the categorization and organization is key, and you have to do it when the number of documents is not only increasing, but different enough.

Sometimes, I just write a longer document and once it's ready, it can be broken into smaller ones. Doing this helps save the organization tremendous amounts of time in not having to re-learn things, or dig it up.

Sure, but this then becomes a fulltime role by itself, once the info grows enough.

I maintain it for my teams, but as things grow, it becomes less manageable, since I'm also a T3 and have technical tasks to address, as well management of the teams.

The good news in all of this, is in less than a decade, it'll all be someone else's headache. ;)

Manually, yes.

Using technology not so much.

I have had to live in similar scenarios as you and am solving this problem and have made some headway. Would be happy to listen and learn from your use cases on what did and didn't work for you.

> One example of tacit knowledge is knowing the Dell T420s Tower Servers have very poor cooling for the raid controllers and often, this can cook them over time, requiring replacement or, at least repasting the heatsink.

I don't even think that is tacit knowledge. Tacit knowledge is how do you know when the edge of your chisel is too dull and need re-honing. (It feels off.) Or knowing how much weight transfer you need to safely navigate a given turn with a motorcycle.

Or to grab a more similar example: Tacit knowledge is looking at a computer case you have never seen before and thinking "that doesn't look like enough cooling, we should calculate and check".

This gets muddy real fast.

One could argue that tacit knowledge also applies when it comes to the feel of pulling laptops apart without breaking the tiny little clips. It takes a few before you get the feel for it, because the difference between snapping a tiny little case clip and not snapping it are about 1 psi (borrowing a term) difference..lol

That absolutely sounds like it.

I opened several laptops with spudger tools. Now I can open random items I didn't watch videos for just because I have an idea of how it _might_ be assembled.

> One could argue that tacit knowledge also applies when it comes to the feel of pulling laptops apart without breaking the tiny little clips.

I agree that that is tacit knowledge.

> This gets muddy real fast.

I don't see how your example demonstrates the muddyness?

it kind of blows me away how many people on these forums don't know what tacit knowledge is.

tacit knowledge is being able to ride a bicycle.

You'll never describe it well enough that a child can hop on the bicycle and ride it the first time.

the knowledge that enables someone to successfully ride a bicycle is tacit knowledge.

I've explained bugs and developed exploits just from noticing odd behavior in video games.

I know how a team is organized, I knew the multiplayer feature was tacked on (probably by interns), I know about network code edge cases, bada-bing bada-boom I can trigger a bug and understand why it happens without ever seeing their code.

Or sitting in a theater and just noticing the lighting setup and transitions rather than the performance itself.

I write documentation for a living and refactoring is a significant part of my work. Keeping documentation tidy is a full time job.

That's what I did at my last job, now I mostly feel like that was a mistake. I was the guy contributing 90% of the wiki knowledge, for no real appreciation or incentive. And when something I posted inevitably become out of date and caused a problem for someone, guess who got blamed? I feel like I was enabling the team's bad habits.

At $NEW_JOB I'm just putting everything into my Obsidian repo. It's great because I have complete freedom to refactor my notes however and whenever I want. When someone has a question for me, I just look up the answer in my notes and send it over to them. Then they'll copy it into their OneNote, and everyone is satisfied.

This isn't my ideal world, but this seems to be the state of equilibrium when management doesn't lay down any expectations or incentives.

This is a perfect example of poor organizational incentives.

Interesting story about where blame is placed, and your move to Obsidian. Thanks for sharing.

I've actually done something similar to your Obsidian repo: I put all my notes into markdown and publish them with mkdocs[1]. This gives me the same editorial control and freedom from blame as your notes, but mine are public by default, so I can still simply reply with a link. I just can't post anything that is sensitive, which hasn't been a significant drawback yet. I have considered moving to an Obsidian based system, but have yet to find something compelling enough to make the switch. It looks like an awesome app though and is still on my radar.

1. https://danielhoherd.com/tech-notes/exiftool/

I often create wiki pages to save myself the work of explaining it multiple times to different people. Ultimately, it's win-win. I don't have to put in more effort to explain something, and the requestor has the necessary information.

If other people don't contribute to the wiki then it's likely that there's nothing incentivizing it. It's not like management is handing out bonuses to people contributing to the wiki. Heck, even my contributions are self-serving.

Maintaining wiki requires a lot of time. Even just adding new content is much more work than a reply over IM/email because one needs to find a right place (if stricture is not completely flat), explain the context (which people exchanging messages have but would be missing for someone who would read wiki), organize content so it has some internal structure e. t. c. And there is a bigger problem - wiki to which new pages frequently added typically full of outdated or no longer relevant information. Updating or archiving old wiki pages requires a lot of time too (and this work sometimes can be done only by an author or someone who knows subject equally well).

It is nice to have knowledge documented, but there is a tradeoff between time spend on wiki and time saved thanks to the wiki.

Another nice hack is to record a video as an answer, and put in the wiki doc, and then email a link to the wiki doc.

The explanation by IM/em can be troublesome because it could be out of date.

Helping your organization be creators is the way to go.

I know many people love video, but I personally think this is only slightly better than not recording it anywhere. Video is much harder to search and nearly impossible to skim, so it's difficult to use for anything other than a classroom-style "let's sit down and learn" session.

Most often I'm looking for some particular piece of information. Finding a video that _may_ contain the answer _somewhere_ in the hour (or whatever) of information just means now I have to decide on the likelihood that it'll be worth trying to watch.

Yes, some things are better explained in video format. But not very many, especially in knowledge work.

ETA: Also video is much harder to update as the situation changes. For the most part you just need to re-record the whole thing, which probably isn't going to happen.

These are great and specific scenarios. I'm working on a solution for all of the points noted above, including updating video.

Would be happy to chat to learn any more you may have :)

There are different tools that handle aspects of the valid things you're pointing out.

Reply on news.ycombinator.com