Hacker News new | ask | show | jobs
by bluedino 2964 days ago
There's nothing like writing up an Evernote or Wiki article on some feature, process, or how/why something works... and then nobody on the team ever reading.

I love writing documentation from time to time. But this helps by getting you to write documentation for only things people are asking about.

5 comments

SO is bad with search, entirely giving it away for Google to find relevant answers. In a wiki, at least I can follow the structure to find relevant pages, but in the heap of badly phrased questions it will be a pain to find anything relevant.

I love writing documentation too, but from years participating on Stack Overflow I found it most unreliable for the purpose. As I once quipped, "Imagine Wikipedia where there are several hundred articles on the New York city. And one that Google links first is copy-pasted from Encyclopedia Britannica, 1913. And every single day several kids from elementary school start a new one."

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.

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.
I think the win would be in making the answers more findable. Confluence is great for writing documents and laying out pages in a hierarchy, but full-text search is still very hit and miss. Especially when you have 50 projects that all have the same keywords and 49 of them are irrelevant.
Or one person calls it "SomeTitle" and someone else only uses "Some Title" and search has no concept those are the same thing.
> Confluence is great for writing documents

Citation needed. I use it almost daily and it's essentially write-only and pretty unusably so at that.

>> Confluence is great for writing documents

>... it's essentially write-only

Seems like there's no disagreement here :)

Anyway, as I see it, as someone who has written quite enough if it, most software documentation is write-only 99% of the time; but it is occasionally very handy to have that documentation written by the original developers when shit really hits the fan.

"Documentation on-demand" seems a great solution indeed!

Although $5/month per user is not cheap. I work at a medium-sized funded startup and I doubt it would be approved for overall use (as it would be nice to include other teams as well, like Marketing, Analytics, Customer Support).

It is the same price of GSuite, that adds a ton more value than SO for Teams could ever add.

SO dev here. Not sure your size, but your first 10 users are much cheaper. On signup, it starts at $10/month and includes the first 10 users. It's $5/user/mo after that.

If you're much larger than 10 - creeping into the 200+ people, it might be better to go with Enterprise: https://stackoverflow.com/enterprise

Thanks for commenting. We are 50 devs and it would be useful to have around more 50~100 in it.

I always have the impression that "Enterprise" plans are more expensive, but probably is just a misconception of mine.

You should maybe talk with your sales team? I work for a 200+ organisation (430ish) and was told we are too small for StackOverflow Enterprise
I’m not sure I would want to work for a company that thinks spending an additional $5 is not worth improving my productivity. How much do you pay an engineer per year? You can’t afford an additional $5x12=$60, really?

This argument would make a lot more sense if it was $500 per month per dev, which some SaaS companies actually do charge per-seat for enterprise licensing plans. A $5 per user per month charge is actually an unusually low price for the enterprise SaaS market. In fact it’s even a low price for the individual developer market. Rarely does anything cost less than $9 per month...

Sorry but that is just a ridiculous criticism.

I think you just assumed a lot from a casual comment with no context.
I just figured this out, but that's $5/month for _active_ users. So if you don't use it, you don't pay for it. Not exactly sure what counts as an "active" user though.
Ah, turns out that's just another word for "users". [1]

https://meta.stackoverflow.com/a/367268/446554

How much does your startup pay for HR functions, Salesforce/CRM, internal webhosting, etc?
This is where the rule of threes is useful for me. The third time I find myself answering the same question for someone, I'll make sure it get put in the wiki. Then next time I get asked, I just give the asker the URL.

Saves time and breath. Also serves as a mini-tutorial on the utility of the wiki.

Even if they read, it gets old really fast usually and who have to update it? You. So now you have two problems :)
It's surprising how long code lives. In most organisations I have worked in, companies talk of rewriting legacy code but very few of these projects replace the existing code. There was a front-page article on Cobol here of HN a couple of days ago. Management tends to be interested in new features and I have noticed there is always a reluctance to change something that is already working.