Search is something that (with the advent of Teams) we've been bolstering our investment in. We've updated to the most recent version of elastic (which unblocks us on a lot of improvements) and we have upgraded how we are indexing questions/answers for Teams. and most importantly, we will just be continuing to improve it - since now it's more critical than ever to be successful there. To your point though, it's the first time we've invested in search in...well, I don't know how long.

Stack Overflow has very small experience with reusing the knowledge, aimed primarily at providing fast on-site answers, for questions too localized for reuse. I have doubts in its ability to provide a solid documentation base, given a flop it made of Documentation project. Wikipedia is a way better source of reusable knowledge than Stack Overflow, and for a reason.

I go to StackOverflow maybe 100 times more often, for coding related things, than to Wikipedia. Disagree that Wikipedia would be better — when it comes to softw dev.

I completely agree with this Analysis.

Having said that, my gut feeling is that SO "Teams" product will succeed in enterprise (& small companies). Managers love if their employees take time to create "Summary pages" from the "Slack and other Chat products". But employees "do not have time" for "Summary pages" and there is no formal structure in 'Slack'. I think this Pages product product provide that 'structure' and a way to measure/monitor by manageres.

> SO is torn between essentially ambiguous goals, providing fast on-site answers and being a reusable knowledge base.

> And it's good with the latter only because of Google. Without Google it will be no better than fast on-site answers on Slack.

I thought the primary goal of Stack Overflow was to crush Experts Exchange — that’s what Joel and Jeff said in the podcasts they published while SO was being built. I figured everything else it achieved was gravy.

>> And every single day several kids from elementary school start a new one.

So many StackOverflow posts consist of, "I searched how to do X, I copy and pasted the code from the StackOverflow answer that came up, and it doesn't work for me."

You can usually google a few lines of code and find out where they got it from originally.

Yes, and it makes Stack Overflow more like an imageboard than a documentation project. So I have doubts whether it can be used for the purpose especially with Google removed from the equation.

I think SO and pure documentation would serve two separate purposes. Sometimes documentation is better for something like an internal library API or related information. But on the other hand, sometimes having a an SO-like place where I can go look up a question related to a quick thing I'm trying to do would be useful. Say I don't remember the process to build the latest version of a Java package and upload it to an internal repository or something, it might be quicker to find a related quick Q&A type doc for that rather than digging into dense documentation on a variety of things.

And here comes the question of maintainability. For the code, we are trying to have a single repository to avoid duplicates and to have just a single place to make changes. That's what a wiki is good for. Whereas for such a dispersed knowledge base it would be hard to keep all these atomic questions up to date.

The front page for Teams boasts it's better than your "stale wikis and lost emails" but in reality there are much more stale answers on SO than anywhere else.

Also, in my experience, someone might proactively create a wiki page in the org documentation. But depending on the amount of logorrhea, it can be hard or discouraging for future people to change it.

Meanwhile SO answers are much more granular and easier to update for that reason.

For example, trying to transactionally update a large page on the org database system instead of an SO question about the parameters you need to connect to it. I can see SO winning here because the units of work are much smaller.

> In a wiki, at least I can follow the structure to find relevant pages

Wow! You have much more disciplined coworkers than most of us, then. I've been at my current employer for about 13 years now. We've gone through 3 or 4 different wikis. Right now we're split between Confluence (worst wiki software I've ever used) and an in-house solution. I can't find a god damned thing on either one. They're both awful, and so were the predecessors. Maintaining any kind of documentation takes work and our employer just doesn't give us enough time to do that and our jobs.

Confluence is one of the best designed products I've ever worked with. Makes the web behave like a native editor, awesome semantic macros that let you put in warnings or collapsible sections in a few keystrokes, you can generate page source with scripts.

Specifically regarding structure:

- every page has breadcrumbs letting you navigate up to its parents

- "child view" macro shows all children of this page automatically, so you can easily make a "category" page linking similar issues that is always up to date

- can move pages to new parents/spaces with a few clicks, or en masse with a drag-and-drop tree view

- built-in widget that searches only children of the page you embed it into

- spaces so you can tell a page in the search is owned by a different section of the team

Plus just a way lower barrier to entry than Wikipedia or the other wikis I've contributed to. I love Confluence.

"Confluence is one of the best designed products I've ever worked with" is something I never thought I would hear. Building a wiki is admittedly a very hard problem, but you're the first person I'v seen, that loves Confluence.