Live data from Hacker News

High-documentation, low-meeting work culture

tremendous.com

201–210 of 524 posts

Re: High-documentation, low-meeting work culture

#201
post #134

I'm convinced that documentation, even for large companies, should just be an Obsidian vault of markdown files maintained via git which is just rendered on the web either using a simple static site generator or using Obsidian Publish. When I brought this up at my last company it got dismissed as being 'too technical'. I know git can be tricky but it cannot be that difficult to teach people from non technical departme…

You talking about 'wiki'?

Re: High-documentation, low-meeting work culture

#202
post #134

I'm convinced that documentation, even for large companies, should just be an Obsidian vault of markdown files maintained via git which is just rendered on the web either using a simple static site generator or using Obsidian Publish. When I brought this up at my last company it got dismissed as being 'too technical'. I know git can be tricky but it cannot be that difficult to teach people from non technical departme…

> I know git can be tricky but it cannot be that difficult to teach people from non technical departments This is far more difficult than you're suggesting. Git still confuses a lot of junior and mid level devs the second anything deviates from their memorized command workflow. If you're expecting non-technical people to have to learn git just to edit the documentation, they're just not going to use it at all. Writin…

> This is far more difficult than you're suggesting. Git still confuses a lot of junior and mid level devs the second anything deviates from their memorized command workflow

Try explaining that they can't push to the repo because they cloned the http URI and need to generate an RSA token and use SSH instead. Better yet, try to figure out that's the problem when they give you a totally unhelpful version of what the problem is.

Re: High-documentation, low-meeting work culture

#203
post #74

Earlier quoted context omitted.

What is an example of that working? Just code that speaks for itself? How would you ever know why something was done?

You ask someone in slack. If that isn't sufficient, set up a small 1 on 1 meeting to discuss. You can't avoid all meetings, but you can keep them few and small.

After you are the 3rd person who contacted me for the same thing, the next one better read the fking documentation that I write.

Re: High-documentation, low-meeting work culture

#204
post #191
post #183

Earlier quoted context omitted.

1. Paste image into assets folder. 2. Write ![imagename](imagename.jpg). It's not that hard really is it.

Have you worked with non-technical teams, ever? Perhaps in teams of very young and gamer-type people this would work, but in any real world team I've been in, this would not in fact be easy unless there's a real time preview and a button you can click that auto-generates that snippet. People would forget the exclamation mark, mixup the brackets with the parenthesis, not know how to reference the right path to the ima…

If someone is confused by markdown syntax it is hard to imagine how they contribute professionally.

Re: High-documentation, low-meeting work culture

#205
post #134

I'm convinced that documentation, even for large companies, should just be an Obsidian vault of markdown files maintained via git which is just rendered on the web either using a simple static site generator or using Obsidian Publish. When I brought this up at my last company it got dismissed as being 'too technical'. I know git can be tricky but it cannot be that difficult to teach people from non technical departme…

You cannot expect non-technical people to use git from the command line. I still like your idea though: the documentation can be based on markdown files in a git repository, but then you have to build or find a web-based WYSIWYG editor with Git support for non-technical folks. If you use GitHub already, it wouldn't actually be so bad to teach the non-technical folks to use the Git UI only to make documentation changes.

Re: High-documentation, low-meeting work culture

#206
post #134

I'm convinced that documentation, even for large companies, should just be an Obsidian vault of markdown files maintained via git which is just rendered on the web either using a simple static site generator or using Obsidian Publish. When I brought this up at my last company it got dismissed as being 'too technical'. I know git can be tricky but it cannot be that difficult to teach people from non technical departme…

Saddling entire companies with having to learn git, even at a basic level, is a hilarious idea.

Re: High-documentation, low-meeting work culture

#207
post #174

Earlier quoted context omitted.

> I know git can be tricky but it cannot be that difficult to teach people from non technical departments This is far more difficult than you're suggesting. Git still confuses a lot of junior and mid level devs the second anything deviates from their memorized command workflow. If you're expecting non-technical people to have to learn git just to edit the documentation, they're just not going to use it at all. Writin…

I do get what you're saying because I struggled with it for ages. There are good GUI tools like Sublime Merge for easy conflict resolution now which would be one solution. I do think a web interface that just automatically commits by just adding your text in addition to the new text along with a warning would probably be the easiest solution and then just have someone edit it after the fact. It's not been my experien…

I think even the idea of merging changes is a step too far for all but the most technical users. Most user's idea of what it should look like start and end at a word-like UI, so having to introduce the idea of merging different copies together and resolving conflicts is too far outside that view. In my opinion this is why Google docs has become popular because it solves that tricky problem of having to think about how your edits interact with someone else's.

Re: High-documentation, low-meeting work culture

#208
post #191
post #183

Earlier quoted context omitted.

1. Paste image into assets folder. 2. Write ![imagename](imagename.jpg). It's not that hard really is it.

Have you worked with non-technical teams, ever? Perhaps in teams of very young and gamer-type people this would work, but in any real world team I've been in, this would not in fact be easy unless there's a real time preview and a button you can click that auto-generates that snippet. People would forget the exclamation mark, mixup the brackets with the parenthesis, not know how to reference the right path to the ima…

Well presumably this would be less of an issue if you had easy to use, easy to search and easy to maintain documentation, you know, maybe in the form of markdown files with a search bar where you could type 'how to paste image into documentation' in case you forgot...

At the end of the day, if you've got someone who can't work out how to drag a file into a folder and then type ![imagename](imagename.jpg) after you've shown them a couple of times, is this really the person you want writing the documentation for your process?

Re: High-documentation, low-meeting work culture

#209

Earlier quoted context omitted.

We use Mark[1] to automatically create Confluence pages from Markdown documents in our git repos. So we can have a review process for documentation changes, the documentation of the code can be in the repo with the code, and yet it can still be accessed without having to give permissions to view the code repo! Helpful with a proprietary monorepo. [1] https://github.com/kovetskiy/mark

So simple an idea, it makes you wonder why it's not already a core feature in Confluence.

Bitbucket wikis basically do this.

Re: High-documentation, low-meeting work culture

#210
post #183

Earlier quoted context omitted.

That is indeed too technical. Try to explain how inserting an image is not just copy paste.

1. Paste image into assets folder. 2. Write ![imagename](imagename.jpg). It's not that hard really is it.

So you're replaced something that's simple as paste in office documents with two separate steps, one outside the app requiring the user to navigate to the assets folder, and the second requiring remembering specific syntax.
Post reply on HN