Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Good ways to capture institutional knowledge?

news.ycombinator.com

Post reply on HN
Print view View original

71–80 of 220 posts

Re: Ask HN: Good ways to capture institutional knowledge?

#71

Post by kevsim »

pyuser583 wrote: post #12
hlieberman wrote: post #9

Mandatory vacation. This is something that the finance industry has used for a long time to guard against fraud -- it's hard to cover up something if someone else has to do your job for two weeks straight at some point -- but it also serves as a mechanism for requiring you to cross-train people. Two weeks of paid vacation where the company isn't allowed to email them or call them for help: I guarantee that documentat…

Some of the most “innovative” times are when someone is on parental leave. And by innovative I mean “we have no idea how anything works - let’s fix it.”

Totally agree. Especially here in Scandinavia where people disappear for 6-12 months at time, their co-workers need to step up.

Re: Ask HN: Good ways to capture institutional knowledge?

#72

Post by bl0b »

umvi wrote: post #43
jrockway wrote: post #34

Earlier quoted context omitted.

I worked in the finance industry and took the mandatory 2 week vacation and dealt with my coworkers taking the mandatory 2 week vacation. We didn't write any documentation or have any internal wiki or anything like that, and everything seemed fine. I also find it pretty questionable that someone couldn't write a computer program that can embezzle unattended for two weeks. You don't use your own credentials, you stick…

Has that ever happened? Seems like the stars would have to align for that kind of white collar crime to happen (financial employee who is also a highly experienced programmer who is also highly unethical)

I mean, 2/3 of those come together par for the course, right?

Re: Ask HN: Good ways to capture institutional knowledge?

#73

Post by qznc »

msaharia wrote: post #69

Could someone please post tool names as well? Everyone is talking processes. But I would love to know more convenient tools as well.

My company division uses Method Park Stages. https://www.methodpark.de/stages.html

I'm in a regulated industry, so this is probably overkill for a web shop.

Re: Ask HN: Good ways to capture institutional knowledge?

#74

Post by herval »

schmichael wrote: post #33

Write write write and keep writing. Then expect to do 10x as much reading. It's exhausting and definitely relies heavily on employees' writing and reading comprehension skills. HashiCorp produces a mind boggling amount of prose (non-code text). Every employee can read every RFC going back to the first sketch of terraform which was completely rewritten in a second revision. Mailing lists are alive and well. PR descrip…

How do/could you quantify the benefits of this culture? I frequently manage groups of “move fast & break things” folks, and RFCs/design docs/etc are a very hard sell (in particular when teams are fully local)

Re: Ask HN: Good ways to capture institutional knowledge?

#75

Post by Thorentis »

ketzo wrote: post #54
Thorentis wrote: post #50

Confluence, or a similar private wiki is a good idea. As you work, write down steps to do things that were essential to doing part of your work, or things that you will need to repeat often. E.g. Create tutorials on setting up a development environment, installing dependencies, compiling modules, running tests, creating new components. Write descriptions at a high level of the system, make diagrams of complex message…

+1. Atlassian tools catch some flack (for good reason), but I worked at a company where anytime someone had a question that their immediate neighbor couldn’t answer, the response was “try checking Confluence, I usually find stuff there”. It made my onboarding SUPER easy because I could basically Wikipedia every internal process/setup/best practice. Awesome feeling.

I think Confluence - so long as it isn't overloaded with plugins - is the best Atlassian tool. Sure, it's basically a WYSIWYG wiki editor, but the page browsing and shortcuts and everything just work really well.

Re: Ask HN: Good ways to capture institutional knowledge?

#78

Post by raz32dust »

dehrmann wrote: post #56
raz32dust wrote: post #52

1. Working in pairs or teams. Avoid solo people working on projects. 2. Common, easily searchable place to put all documentation at. Good search capability is critical. Wiki is ok. 3. A good code & commit search engine. Ability to search code reliably obviates the need for a lot of documentation. 4. Weekly knowledge sharing sessions with the whole team. Both presenters and question askers need to be rewarded to keep…

> Common, easily searchable place to put all documentation at. Good search capability is critical. Wiki is ok. I have mixed feelings around documentation because I can often read the code faster than the docs, and docs are often incomplete, inaccurate, and out-of-date. Docs for truly long-lived things are nice, though. As for good search, that's easier said than done. The heuristics Google used for search don't work…

I didn't mean documentation at the code level - I believe well-written code is always better than docs - it should not be used to hide badly written code. I was talking about documentation like product requirements, meeting notes, decisionf and trade-offs, design etc.

Re: Ask HN: Good ways to capture institutional knowledge?

#79

Post by simonw »

I started an internal blog - using Confluence, because it was already a tool used by the company so I didn't have to convince anyone to install anything new.

My goal was to introduce a culture of internal blogging at the company. I didn't really succeed on that front - I used my blog a bunch and a few people made a post or two - but I like to hope that if I'd kept at it for longer (I left the company) it would have started to catch on.

The reason I like internal blogs is that they release you from a lot of the pressure of writing more formal documentation. If there's a technique that I think is a good idea but that has not been established as an agreed best practice, writing it up in official documentation doesn't feel like the right thing to do. Writing it up on a personal internal blog as "as-of date X my opinion is that we should do Y" is always OK.

Likewise: writing documentation that later goes out of date can cause harm. Writing a blog entry that says "as of February 2020 this particular system worked in this particular way" seems much safer to me.

Re: Ask HN: Good ways to capture institutional knowledge?

#80

Post by simonw »

A trick I've used effectively is to have a "doc of docs" - a document that tells you where all the other documents for a project or team live.

You can do this as a wiki page or a Google Doc. The important thing is that the answer to the question "where's the documentation for X" should ALWAYS be "it's in the doc-of-docs".

Then you can take it a step further: you can say "it's in the doc-of-docs... and if it isn't, when you find it, add it to the doc-of-docs!"

It's a universal truth that documentation for projects and teams ends up scattered in many different places. A doc-of-docs is a lightweight technique that can really help here.

Post reply on HN