High-documentation, low-meeting work culture(tremendous.com) |
High-documentation, low-meeting work culture(tremendous.com) |
I'm in Ukraine and this is disgusting.
I work as a consultant with a lot of outsourced teams who poorly communicate or seem to avoid written responsibility.
really like that thought: "low-meeting culture allows us time to do high-value tasks"
I also am interested in ways to tie source code and documentation together. For example: linking to methods in a way that follows refactoring.
Show HN: CodeLink: create links to blocks of code in your IDE
if not, i don't believe you.
Makes more sense for 100 people to read a doc and get the gist. Rather than interrupting the dev 100 times.
My last job, low documentation, low meeting. Basically every bit as bad as you might expect. Every job you basically have to figure everything out from scratch.
2 jobs ago, low documentation, high meeting. Daily meetings to discuss what I'm working on and how little the rest of the team is doing. Yet nothing changes or improves.
The management really doesn't go in for meetings, especially not all-hands, nor 1:1s for us at the lowest level. We have onboardings and special messages and all those are recorded in case someone misses, it's no big deal.
Documentation: we have a master SOP document that's about a dozen pages, you can read it in an hour and understand it. There's a living spreadsheet that's updated so you have to check it on the regular. I've also helped build an aid for one particular investigative side, but it's optional. There's other documentation but it's all ancillary and optional, the biggest thing to know is SOP.
There's an #important-links channel on Slack and I do try to look through it on the regular, but all you really need to know is a small field.
We're all 100% remote, WFH team. We stretch from San Francisco, to NYC, to South Africa and coworkers in Australia too.
We're starting to branch out in non-English languages, so I'm sharpening my Spanish for the road ahead.
Then again, documentation doesn't necessarily solve that either, because then you have the people at your desk who don't read the documentation and need someone to walk them through it. But at least that way you don't have to go from memory.
Though it's offset by very generous comp as there's not as much bloat to soak up your TC. So YMMV...
I'm not sure how well this would scale past the Dunbar number, or for organizations growing rapidly.
Either way, I'm glad they published this.
https://jondouglas.dev/lets-not-meet/
This company seems to "get it" though. We ought to protect our attention more often.
I'd take documentation over no documentation any day. Even if it's 4 years old and was last updated by a person who left for a competitor.
Then you hire someone and for the first 6 months their life is hell until they clock on to what everyone else is doing and just ignore whatever everyone else is working on and plough their own furrow. Sure, we've now got 17 different poorly documented logging libraries (because no one wanted to invest in adopting anyone elses), but every individual developer is writing plenty of documentation! Oh and god forbid you disturb the author with questions outside of the 1 very short window for meetings in 1 specific time zone. Their careers page says "Join teammates from Hawaii to Brazil to Germany". Their meeting time is 6-9pm in Germany every day and 7am to 10am Hawaii time.
Documentation is hard to create and hard to maintain. It is essentially a simulation of an underlying reality, and that underlying reality *always* changes faster than the documentation can. So the documentation ends up being spotty, except for the parts that you find a way to automate. It's hard to automate all documentation, since so much knowledge is trapped in the analog world, and in peoples' minds.
Companies like storytell.ai are trying to solve the problem of creating documentation and written artifacts automatically out of Zoom recordings, etc. Others, like WeRice, are trying to create it out of videos of maintenance work done on equipment in the wild. I respect both efforts a lot. It's a hard problem to tackle.
And a set of automatically generated reverse links, to documents that referenced the one being viewed.
Both kinds of links help create continuity and context.
Nor do these suggestions solve the problem of doc creation.
What many people ignore in these discussions is the real tradeoff between "time spent in meetings with people who can answer questions" vs "time spent by non-professional writers trying to be clear for strangers".
That probably depends on how you prioritize it. You can dictate that the docs (and the tests) be written before features are added.
1. Promote self-documentation as much as possible—e.g. meeting notes typed straight into Google Doc, discussions typed straight into Slack, issues typed straight into GitHub, comments typed straight into code—so you’re documenting as you go in a way that’s automatically archived and searchable for future reference. There are times when separate out-of-band documentation is appropriate, but that takes extra effort and can get out-of-date more easily.
2. Promote an it’s still okay to ask culture in parallel with the high-documentation culture. Asking questions in Slack can be a shortcut to finding the right document or finding out something is yet undocumented, and should be encouraged especially if the asker has already done a quick search without locating the needed information.
a. you need a person who "curates" the documentation, otherwise it completely loses organization quickly
b. things become out of date fast and it's not clear if you're reading something out-of-date
c. people write too much, meaning - things turn into this huge long form internal article and people get exhausted in just reading through it. Writing is actually quite hard.
I don't have a better solution/approach to recommend (besides having a curator), but the "less meetings / more documentation" train always seemed oversold to what I've experienced first hand.
Marvelous is also about to face a significant stress test with the holiday season, both from retail usage of their product and from vacations of their employees. I wonder how routinely highly-documented the agendas will be when competitors start sniping their biggest clients as their service crashes from overcapacity.
Reversion to the mean is coming — what would be interesting would be to hear successful strategies to resist it.
1. Standard interviews don't assess reading/typing speeds. If you want a high documentation culture this is critical. It took way too long for us to figure this out but many people in the company were significantly slower at reading/typing than us; they found long documents overwhelming and would find excuses to not read them. Slack conversations became a massive sore spot because unknown to us some people felt like they couldn't keep up. They'd try to type a question or response and we'd already posted another two paragraphs before they got a chance to finish their thought. They'd complain to each other that if they asked us a question they got back an essay in response, etc.
2. Documentation requires ownership, otherwise it rapidly becomes useless. Standard corp tooling like wikis doesn't make such workflows easy. They are however optimal from a corp politics perspective (dispersal of responsibility). Maintaining markdown based websites works well as long as you have empowered maintainers who view document quality as a core job function, but you have to force people to submit changes by e.g. rejecting at code review time changes that don't update the docs. People will moan. They will ask you to do it for them. They will submit absolutely min-viable docs changes, they will demand you hire technical writers even if they're easily capable of doing it themselves. And of course the moment you're not using a git-style workflow, just forget it, you have no chance of preserving coherency in any sort of knowledge base.
3. Lots of people aren't just slow but actively HATE reading and writing. They will make things up on the spot, or lie, or just flat out refuse to do the work rather than sit down and read a long document. Jeff Bezos has said about why Amazon uses meeting time to force people to read the memo:
"If we don’t, the executives, like high school kids, will try to bluff their way through a meeting"
You will have to fire people for refusing to read things if you're serious about creating and maintaining such a docs-oriented culture, which in practice is so unpleasant nobody ever does it and so maintaining such a culture is nearly impossible. You will also have to flat-out refuse to meet people in order to force them to read, because otherwise they'll receive a document and just ignore it. I had several cases where one of my most senior engineers would assert that a product we used didn't have feature X, and I had to correct him by pointing out that the user manual discussed feature X in detail. I knew this because I'd actually read the user manual cover to cover. Basically nobody does this and guess what, if you're the one person on the team who reads stuff then you're going to come across as the awkward smart alec who makes people look stupid. Sometimes, ignorance is bliss.
Asking people with poor writing skills to work in the way described here seems like it could lead to problems without a selection process favoring good writers, or at least a training system to get new hires up to speed.
2. Do not expect anyone to do anything you have not trained them to do. If you want your employees to work this way, actually train them on how to do it.
3. Without leadership pushing this culture, it will. not. happen. Don't even suggest a change like this until you have sold at least 3 people in leadership.
You can't avoid all meetings, but you can keep them few and small.
Either the author is some kind of reading savant, or this metric is way off. That's over 400 words a minute for a semi-technical persuasive essay, with multiple graphs.
I know there are marketing analytics out there saying that you must write everything in a 3-7 minute read band to maximize audience reach, but I don't think just telling people a long article is short is a good way to go about that.
ctrl-F "Training" 0 hits. ctrl-F "Hiring"
> But we take great care during the hiring process to choose people that thrive under these conditions.
Is the interview by post? There's a story here, but I don't know what it is.
However, some people are much better at communicating or understanding material if its shown visually, which can be much more time efficient for both parties sometimes. Every format has a place.
Thus they would rather speak at a meeting than type into a form, because they can speak several times faster than they can type.
I don't hire people who don't know how to type properly (or won't commit to learning).
I get questions from people, which can be answered by searching my wiki and just finding the right page. I can see the number of pages visits with the wiki tool I use, so I am led to believe that I'd get a ton more questions if not for my wiki.
So what's the problem? I am just one person in my group. There's a couple hundred of us, and I don't think the next most documentation-heavy engineer is producing half of what I am. (Probably more like a quarter)
Which is a real shame. Part of why I produce so much documentation is that I've created by own tooling and processes which let me generate vast amounts of useful content on the fly, and quickly. I've got 100+ hours of dev work into one tool, and I'm pretty sure I'm the only user of that tool (although I give presentations on it from time to time). Think: A tool which looks up details about an environment, and then aggregates those details in markdown format (including links to dig in further). Copy > Paste > Save page > Done.
First, introduce The Diataxis framework ( https://diataxis.fr/ ) for documentation. It makes people think about documentation in a more structured way, and allows you to be more specific in the types of missing documentation. (High documentation cultures are often good with explanation but not tutorials, for example.)
Second, I would introduct the idea of a Documentation Portfolio. I have a review of Agile Documentation at https://www.ebiester.com/documentation/2020/06/02/agile-docu... and it speaks to another structure for how to build the documentation in a more reliable form and thinking more carefully about your audience for a particular type of documentation.
Not every issue needs to be solved by a butter robot.
Why not employ a technical writer/documenter/whatever job title you like, even as a temp, whose sole job is to sort out the mess of documentation you have and then to write new documentation as you move forward?
Thanks so much for the link, I wish I'd had that chart ten years ago!
Adding a caption here for anyone on a screen-reader, before I give commentary on it:
* X-axis: "serve our study" vs "serve our work"
* Y-axis: "practical steps" vs "theoretical knowledge"
* which gives 4 quadrants: how-to guides, tutorials, explanation, and reference
Also, I wonder if the relative distributions of each one could tell you something about the team's health — or even just the kind of work the team does?
For example, between two teams who are both documentation-heavy, what does it means if one team's docbase is 80% tutorials, whereas the other team's is 80% reference guides? It would be fascinating if anyone's already given thought to relative metrics/heuristics like this.
I see how it applies to documents which describe things as they are, but I'm curious how it would classify forward looking documents like technical designs, strategy and vision documents, roadmaps, and mission statements.
There's your problem. The only use case for Confluence is when you want to hide information, but credibly claim that it's documented.
The primary failure mode I see is when people just throw random documents into Confluence wherever convenient at time of writing and never go back to logically organize anything. One symptom of this is when key information is being recorded in a hundred different people’s “Personal Space”
Taking even half a day to organize the average Confluence makes a huge difference.
It's incumbent upon all users or members of the team to use the common tool along with agreed upon standards. Otherwise even if you wrote documentation in your own hemoglobin, no one would touch it either.
Some manager prob chose _________ as the tool for ticketing, documentation, etc not because it was good at ______, or _______ but because it fulfilled their action plan to have something, anything in place so that if the universe goes supernova, well some stuff was written down.
In my journey it seems that nobody is willing to criticize Edward Teach for the lousy treasure map he left, but rather we make fun of those who're still looking for his stuff.
There have been times I know a page exists and I even know the title/content of the page and yet still I am unable to find it via the search.
That describes Sharepoint more than Confluence.
It is such a stupid idea that it makes me question leadership.
Some things are good to document there, but generally, if you're documenting code, you should do it in the code.
That's it. No mystery.
(BTW, this would also be why company financial records would suck, if management decided to save money on accounting staff and have all employees just kinda do their own accounting for the company. I SAY HIRE A SCRIBE FOR EVERY TECHNICAL TEAM!)
This. Yes, having everything written down and searchable is definitely a good goal. However, in my experience, the people in most companies have very different skills and few are good writers. So it probably takes a lot of time to create an organization that has a good process for creating great documents, let alone to transform an existing organization which can do so.
Duplication can be useful. But the more of it you have, the greater the maintenance burden is. (The main exception is documentation that is not supposed to be kept up to date, like a daily journal or blog posts.) So I think it behooves people to be very careful about adding documentation. Because as you say, it can turn 1 problem into n problems.
The lingua franca of ideas is natural language.
Confluence has been the bane of my attempts in finding any relevant docs. Which one is the source of truth? Which one was a draft written by an overly eager to make a first impression, new employee (who is no longer with the company)? Don't even get me started on saving meeting notes to confluence.
These days, I maintain my own knowledge base on Obsidian. If there's ever any confusion or request for more information within the company, I copy-pasta the relevant note from my obsidian bank to whomever person or whichever confluence page they deem the source of truth.
Design docs for each and every feature has turned out not to scale for my current team. Larger, multi team features demand consolidated documentation, but for internal changes we rely on quick meetings as code reviews. Part of me misses the ceremony of the round table discussions, but the real difficulty is keeping track of why changes happen. Documenting processes and cross cutting concerns is a must have, but keeping track of all changes across quickly moving teams… it’s no surprise so many teams are just rife with tribal knowledge.
I have worked with teams that focus so much time on design docs and insist that everything has to be documented. Pace of work is slow. Documentation and designs became obsolete due to shutting down of services, change in architecture, refactors.
The best form of documentation is code.
Documentation as code might be a good alternative path, using the same tools and processes as software development and embed documentation tasks into engineering workflows. More insights in https://about.gitlab.com/blog/2022/10/12/five-fast-facts-abo... how the GitLab technical writing team collaborates.
Note: GitLab team member here.
> Occasionally if you ask how to actually do a task in Slack someone will yell at you that you should have searched for a specific, obscurely named document in Google Drive, Confluence, or Github.
When I'm the person being asked and know of the doc in question, here's what I try to do instead: I ask where someone searched for it. Then I update that place to refer to the correct document (and do some light refresh on the doc as needed). This works whether or not they tried to look before asking. If they did, well, now the next person who does that will just find it. If they didn't, I'm making them look before getting an answer. Maybe they find it, maybe they don't, either way I'll help them in the end if they're willing to look.
What do you mean it can't find anything?
And if that's ambiguous, then ask how often your company penalizes people for making the common but wrong choice versus the uncommon but wrong choice.
You may still not know how to find anything, but they will.
Like a lot of other things, this has suffered from computerization making it yet another small part of everyone's job (which also increases context switching, the amount of shit you need to know and keep track of, and generally makes jobs more stressful) rather than a specialty that's the main focus of a few workers.
The benefit (get to stop paying some employees) is easy to measure, while the harm is not.
The exception is daily supply chain and accounting, which due to factors like urgency, multiple stakeholders per order, high pace of handover, external system integration, multilingual presentation requirements and nontechnical users we prefer a dedicated web based system with more of a real time focus with event hooks (eg. notification, translation, verification).
Nobody knows how to accomplish this.
Whatever the solution is, if one exists, I'm sure it involves a lot of work keeping documentation up to date.
Out of date doc is worse than no doc, because it makes you feel all warm and fuzzy right until you footgun.
How is this not inevitable if your goal is to always write things down? It seems like the way for document to be accurate is to keep the scope small and if you want everything in scope then it's going to contain a lot of outdated information.
There's no easy answer.
I mean, you're clearly not describing a high documentation culture, you're describing a culture that underinvests in intra-organizational communication.
I run a high documentation, low meeting culture by necessity (we operate in five time zones around world). Meetings vs docs is remarkably similar to the decision between paying for office space vs paying for occasional team retreats. If you run a fully remote company retreats are almost always a better use of your money than leasing office space. But you still need to pay for something.
Similarly with meetings vs. process documentation. If you're heavily remote and spread out I'd say you should cut down on meetings and being high documentation is the better choice. But again you still need to "pay" for something - you save time on meetings but you need to reinvest at least part of that time into writing documents.
Another bonus of documents is that they scale better than meetings. McDonald's doesn't deliver the same big Mac in every corner of the world by holding a lot of meetings. They have a book that goes out to all of their thousands of franchisees. When they want to add another thousand franchisees, they print more books.
If the documents are out of date my answer to my team is always "update them!" Anywhere that we're writing documents there are revision and discussion features so it's not like you can irrevocably screw something up, just improve it and let us know what you did. I do struggle with getting people to actually do it though.
Obviously this doesn't apply to public facing codebases. But trying to keep an internal codebase documented, other than fully finished self contained library level code, is a sisyphean task.
I know git can be tricky but it cannot be that difficult to teach people from non technical departments add, commit and push and then show maybe one person from each department how to solve conflicts. Alternatively, build non technical people a web interface for editing and committing but allow the devs to just use git as standard. Or there's Obsidian's built in sync but I don't know enough about it to know if it scales well in large organisations.
What absolutely is definitely not the solution is Confluence. I have not met anyone who has a positive thing to say about it. The only reason it is being so widely used is because it satisfies whoever is in charge of the finances because it comes bundled with Bitbucket and Jira.
I learned a little later that "summary" exercises are not a thing taught in school here, which surprised me. In France, "le résumé" is an exercise that they constantly drill into students (particularly technical ones), in which you take a 3 page paper and condense it into 100 words. I really hated doing it back in the day, but as an adult I now am very grateful I did and wished other countries made this more prevalent.
However I'd be very curious to see how this evolves as the company grows. Personally, I am skeptical that this is sustainable in the long term. In my experience, most people are a) bad at writing and b) hate reading. And as a company grows, and the number of documents that need to be written and read explodes, this work pattern eventually becomes untenable. More and more meetings get scheduled to cover topics that are not well documented, which causes people to have less time/inclination to create or consume high quality documents, and it becomes a feedback loop.
(Edited to make it clear that I am not against the idea, just curious to see how it evolves)
Meetings are great for communicating with people here and now, but only writing can communicate with people from the future. When you meet with your current colleagues, spare a thought for your future colleagues who haven’t yet joined, and do them a favor by writing things down.
Ability to use written communication is a major differentiator between junior and senior engineer.
Alan leaders also have other strong ethos like "no managers" and "complete transparency".
I really wonder if these companies are exceptions or if this organisationel model could be replicated more widely. I guess it caters to some very specific personality types.
[1] https://blog.alan.com/bien-etre-au-travail/who-we-are-and-ho...
Async communication, full transparency, 90-day retention in slack which forces decisions into documentation if it's important, issues/threads for discussions, and handbook for SOPs [1]
Anyone have experience with this directly that can speak to if this works in practice?
Or is Gitlab just really good at marketing their methodology as a tool to sell more subscriptions?
1 - https://about.gitlab.com/company/culture/all-remote/handbook...
There must be people who sole role in the company is to spend time on each team (in sequence) trying to follow or review their docs and get X running "like the docs say"
This group of enforcers will contain a variety of people from tech, legal, customer service, and other backgrounds who can spot trash (in their area of expertise) when they see it.
My problem is that there are too many pages that may or may not be relevant/and/or up-to-date, I want to know if there is a better way? I can't just read every document the company has on the topic in vain hopes for the answer. For example, I recently started working on my company's mobile app - noone has looked at it in a few months so its an ideal candidate for this kind of knowledge.
Despite that, I didn't go to confluence, because 99% of the stuff on there is half-finished drafts, and stuff aimed at our b2b customers, so I don't hold much hope in finding a solution to something which in principle ought to be very simple, like setting up my dev environment. In this case, the original project lead is no longer with the company, I had to ask a couple people who worked with it in the past, and it turns out they no longer knew how, and the documentation which had been written both didn't include it (it was customer-facing) and was also so out-of-date as to be irrelevant. I have no doubt that whatever developer made the app stopped writing documentation because they felt nobody would read it if they did! it's a self-reinforcing cycle.
I guess the only answer, as some others have mentioned, is a predictable organization system for the documentation, which crucially is actually taught to newcomers.
I can understand it both ways.
Or are you saying it was dwindling, but it surged up due to wfh? Then I guess I agree, though I’m not sure if it’s due to productivity theater, or physical constraints being removed
One can only dream everything had documentation as great as i3wm's as a bare minimum.
But it's better to know than to be ignorant, usually.
Oh god yes! This - a thousand times this !!
Dear Web Devs
Every web browser already does smooth scrolling out of the box. Your JavaScript implementations of it rarely work and only create frustration to users. Even they they DO work, it creates an unexpected behavior, which is frustrating.
*SmoothScroll*$script-documents go out of date, people are usually up to the minute
-documents don't allow you to ask questions people do
-documents never forget, people do (not forgetting seems like a good thing but try working through a 5-10 year old team wiki or OneNote and you'll see why it can be good)
Sadly we adopted Microsoft O365, SharePoint, Teams. How can you organize the org effectively is beyond me, how does MS do it? Are they actually using their own tools they sell others?
In our org, some departments/teams/sites have just a SP, Others have a teamspace with separate SP/document store.
Worse, any meaningful file structure/hierarchy you come up with gets sabotaged when new channels are created as they automatically introduce new folders. You cannot bind a teams channel to a separate folder in a SharePoint. Also, We have private project teams springing up and large fragmentation of information. If you do not know that a certain project space was set up you cannot find or join it.
Going with a "single Teamspace" for the whole org doesn't work either without being able to have nested channels/groups. The org is too large and complex.
I'd love to have a gitlab style handbook to be used in our org to organize knowledge and information, but I do not know if and how it could be set up technically.
That's quite a load-bearing "just" there.
A long provisioning instruction became much shorter as a result of automating it by reducing the need to document.
>In a document, the content is all you have. It forces people to focus on communicating their ideas as clearly as possible.
But I worked for a Japanese corporation, so we had regularly-scheduled meetings. I was able to reduce them, though.
I'm not checking confluence, write it in a ".md" file in the repo if you want me to see it.
I think that high documentation can work BUT the company has to invest in it in the way that Digital Ocean or even Stripe has done outwardly.
1. Investment - You have to hire at least a few technical writers and librarians to provide training & cleanup functions.
2. Management buy-in - You have to budget for it and encourage it through day one communication (ie. New hire training) and consistently rewarding and recognizing people for getting it right.
A lot comes from tribal knowledge/who to talk to/etc.
People need to actually learn how to write and maintain(!) documentation, otherwise it’s just a huge chaos.
Rule 1: less (text) is more.
Would that place be the U.S. Department of Defense by chance?
Are people at the same job telling you to check 3 different sources for internal docs? Maybe that is the main issue. Put knowledge in one place.
More specifically: One place that is not Sharepoint.
Can all your engineers see all your other engineers' code? It's hard enough to get code to do what it says it does; I've very rarely seen documentation that's correct.
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.
Writing and aggregating good documentation needs to be easy and simple. Gating documentation behind git is the opposite of that for non technical people.
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.
Given the number of non-programmers who Really Need the functionality of git, who probably won't be able to hack dealing with it, doesn't this indicate that there's some huge vein of untapped value to be won by whomever cracks the problem? (Version control for business people?)
Another not great but possible solution could be for non technical people to work on something like a Google Doc when stuff is in highly active development and to then copy this to a markdown document later when its solidified.
I do think that as a society we have to start looking at stuff like this as a new essential skill though. We wouldn't expect people to be working without basic literacy, numeracy and computer skills and I think we are going to have to start looking at upgrading our sense of what basic computer skills entails to include stuff like git and teaching it in schools from an early age.
How do you find a happy medium between this and a Confluence-like free-for-all, where anyone can create/edit a page?
We have two repos: Product (to anything relating to product) and Wiki (anything else, ranging from onboarding checklists, brief design documentation of key parts of the code ... to meta documentation)
Although our team is small by many standards (8) everyone likes it.
We spend a ridiculously small amount of time on meetings.
The obvious and great upside is the code/documentation integration which has virtually 0 context loss.
One downside however is indeed the difficulty of git branching to non-developers.
Once in while I find myself debugging a messed up version.
But I'm willing to pay that price.
Just let developers either read the markdown files as-is or set their IDE to render markdown previews by default. I prefer the latter because I don't have to wait for someone who's on vacation half the time to render the latest docs.
When it comes to API documentation, everything should just be inline comments in the doc format of choice for the team. Don't bother rendering this out, because every flipping tool ever invented for converting inline documentation into HTML fails on something simple. Developers can read the inline docs as-is and/or rely on their IDE to provide them hints from those docs.
If you have to deploy your documentation, that's how you know you might as well give up. It's one thing to deploy documentation for 3rd parties, but for documentation being used internally there's few good reasons to turn the documentation into its own website. That's extra work that I've never seen increase productivity or developer happiness. Don't put documentation behind one or two guys with special permissions to press a deploy button. If you do, the documentation will always be out of date as soon as it's rendered.
Remove as many reasons that devs won't write documentation as you possibly can.
The documentation for almost every public Rust library is automatically rendered and hosted on docs.rs and it's incredible to have that consistency.
Just check out this Regex type and the awesome documentation for every method, all taken from inline comments:
Finding the perfect documentation platform becomes a waiting-for-superman game. Everyone loves to complain, but nobody wants to put in the actual work to write clear content, define information structure, consider audience, etc.
The real solution is hiring people who are excellent writers. To do this, leadership must be good at reading and writing themselves (not a given) and be able to recognize top contributors.
2. Write .
It's not that hard really is it.
The fact you need one person technical enough to resolve conflicts is already a deal breaker.
At the place I worked for 22 years ago, we had an SMB fileshare for designers/front-end devs (html templates + templating lang), which would simply commit everything to CVS at night.
At least you will have multiple revisions.
Available PLM/PDMs could be improved a lot yes, but you're not gonna replace them by slapping a GUI on git (I mean, you could do that but it's really just a pretty small part of the problem space).
This, except for normals, sort of exists:
Craft: https://www.craft.do/solutions/businesses
Default is internal only, but you can allow sharing, which creates a web URL that can be privately or publicly shared (and can be on your own custom domain).
It has versioning, it has comments, it has real time multi-editor collaboration. An entire conference room, in person and virtual, can co-edit in true real time without anything blowing up, a feat not to be tried in Word, or even Google Docs.
Most firms should stop looking and just try Craft. Encourage everyone to do everything there, see what happens.
Note bene: it happily imports markdown, also exports Word, PDF, Markdown, and Textbundle, and can feed a static site gen.
They also keep busy: https://www.craft.do/whats-new
// I use Obsidian for myself, but Craft to collaborate with non-engineers. I've also been known to recommend FOAM to engineering teams, coupled with mkdocs and a good theme for static site gen, such as material for mkdocs:
https://foambubble.github.io/foam/
https://github.com/squidfunk/mkdocs-material
For eng teams already living in VS Code, it's hard to beat PKM where you already are.
- the default index on the sidebar doesn't handle sub-directories well (https://gitlab.com/gitlab-org/gitlab/-/issues/17673) - we use a pipeline to refresh an index page, but it's duct-tape and annoying to setup.
- can't edit only a section of a page, so if the page has a few sections, I often lose track of what exactly I wanted to change (maybe the WYSIWYG helps here, have to admit I have not used it much)
Otherwise I like that each project has its wiki, and so instead of one huge messy wiki, it's a few smaller messy wiki, easier to cleanup and have clear owners.
The answer is, of course: no. You just want it because it's familiar to you. Which is fine... if you were the only person using it.
Confluence is actually the best solution, hands down. It has a WYSIWYG. It supports Markdown. It has an API. It versions all content. It has fine-grained access control. It does not require granting a user access to a repo to write to a file. It has much more rich content to better convey information clearly to humans. It has full text search. Page management is simple (rename a page and it auto-redirects). And no other solution does all of this as easily or effectively.
The people who complain about Confluence simply don't care about use cases outside their own, and haven't taken the time to learn it. I am 100x more productive with Confluence than you are with Git and Markdown. And real people will actually be able to use what I've made there without learning complex tools or jumping through hoops.
I had the same concern, internal documentation should be in a portable format... and I managed to mostly successfully get us to change to MD text files in a git repo.
I, and others, were tired of it being locked up in proprietary platforms like google docs - which ironically has terrible search capability and is horribly slow. Some of the devs already wrote documentation in markdown and plain text along side code (Also I hear talking about yourself in the 3rd person is the first sign of madness). So a git backed wiki in text files was what I wanted. But it also needed to generate commits from the front end for the less technical, and preferably needed oauth to delegate access control to some other system.
"Golumn" filled this space first I believe, but doesn't (or didn't at the time) have the commit or oauth capability. So I settled on a fork "Jingo" which does. I'm not completely wedded to Jingo, which is a nodejs app, I haven't dug too deeply into it and so my confidence in it is unknown... but this is effectively data driven design, md text files in git... the code (which is not part of the same repo) is disposable.
I set this up 3 years ago and haven't touched it at all. This has been mostly successful gaining more traction over time. People who have no clue how to use git are generating gits commits on a daily basis through the front end - others are using the repo directly. Google docs still has it's place for arbitrary word type stuff, but most internal internal reference type material now gets put into the wiki as a preference, since it's way more searchable, and orders of magnitude faster to access.
[edit]
To be clear, i'm in a small company where it's easier to change or try things like this.
I also got the same expected pushback, concern over MD being too limited compared to google docs and the solution being too technical. but if you can just convince people to trial it for long enough with an exit plan, they will usually obtain a more balanced view weighing the tangible benefits more highly and weighing the negatives or concerns less after actually experiencing it... in this case most people realise that all the bells and whistles of google docs are not critical, and the benefits of the searchability, speed and portability are huge.
If the two options are confluence and sharepoint I choose confluence every time. Somehow people have decided that because sharepoint can do document store and html it's a kb. and because it comes with O365 exec's love it because its "free".
Nah, that's going to be a crapshoot. You want a few people who know git and do this for a full time job and that's all they do - manage the documentation git repo.
Unless of course there's a good reason for maintaining your docs in markdown files, but all of them?
What's the benefit of your solution? I mean git has excellent history lookup capabilities, but that's the only benefit I see. Maybe another one is that you can update documents without leaving cli..
Second, because it is plain text, search is blisteringly fast using any number of different tools. Following on from that for a third benefit: portability. You're not tied to any one service. You can use any text editor for editing and you can use a multitude of different solutions for publishing. Version control? Use whatever you what.
Another benefit: easy linking of files using [[wikilinks]] and block inclusion. If this is done properly, you can also use the graph view to get an oversight on how your code affects other parts of the codebase at a glance.
We also encourage bullshitting in everyday communications. It drives me nuts.
As someone who dabbled in creative writing before discovering my vocation, I see a lot of problems caused by people not bothering to explain themselves clearly.
As my time in the industry grew I begin to see people who were confused about their own ideas and came to see how many things we don’t even explain to ourselves. Which likely plays a role in how defensive people get about some of their ideas. They hadn’t considered these things and now they feel out of their element.
I'm ashamed that I was completely guilty of this myself.
At some degree of professional development in software, you start to verbalize things, so as to 'explain them to yourself' and it helps clear things up.
This helped me understand that 'writing skills' (in this context) are frankly more matter of being able to organize concepts more than anything else.
A dev who can articulate is literally worth at least 50% more than one who cannot.
And to your point, yes, it's funny and scary when someone can't describe something they ought to be able to.
If someone can't explain something they are actually a risk to the code.
It is not to blame anyone, because what people want in reality is answers and answers now - not searching through 20 pages of text, even if it is well written.
My tasks at work are not "read Anna Karenina and think about it". They are more "given X, Y and Z can you produce G and if yes, do so ASAP please".
Which takes us to the meetings and asking around which quite often is quickest way to get correct answer - even if answer is in a "well written down documentation".
Simple text search is not there yet, any advanced system for "knowledge management" fails really quickly in that regard because it takes effort to learn. It is either that setting up such knowledge management system takes too much time or getting used to it takes too much time.
This is why I cringe when I see knowledge management systems posted here on HN, usually these are cute toys but are not really solving anything unless their founders convince 90% of world population to meticulously fill in data in such system.
True, people are bad at both but I think many people view a 30 minute meeting where they can voice over an idea as a lower lift than sitting down and writing a well structured doc (see also: Loom). Plus, it's easier to enforce attendance than to enforce reading a document. So meetings are the path of least resistance.
Edit: Someone asked for more detail on high meeting culture. There are constant meetings between cross-functional teams, various leadership stakeholders, and ongoing operational planning. That is not including your day to day meetings within your sub team or the follow up meetings from doc reads or the new team launch meetings, etc. Amazon tech is a high meeting culture.
Pun intended?
So I just write crap as well.
Why does everyone else has to pay the insane price for that?
I've seen it a number of times in my career.
Most document management systems have a notification system built-in so that you can automatically email your all-staff mailing list when there is an update. It's very much a solved problem.
My current workplace culture (at least in the HW dept) is much more towards zero-documentation than anything I have experienced before and it has been a nightmare as a relatively new employee.
I waste so much time in reviews because I have done something non-standard despite having checked the standards docs but it turns out the standards have changed and no one bothered to update the docs. We don't even write specifications for products before we start work on them; if I make some architectural changes during the design, there is nowhere to record it. Drives me insane.
IMO there are two things that should be documented about any project: 1. The product itself: at least its interfaces, features and general architecture 2. The process of design: what changes were made vs the original spec, why, and when
If you want to know anything contained in that set of information here, you have to know who worked on the project so you can ask them about it, and then they have to be able to remember. It's not uncommon that changes are suggested and discussed multiple times within a project, or that changes are made but the reasons why are forgotten before the project is even complete.
I often joke that projects here are more "observed" than managed.
Exactly as you say - emails/meetings are ideal tools for discussion and decision making but for lasting records, you need documentation.
Agile taught us working software over comprehensive documentation, but it also made huge generation of people thinking that all documentation was bad, and not just "comprehensive" (or "overblown").
Documentation (words) is how many complex concepts are communicated.
I've built a requirements management system to handle this (https://userdoc.fyi), and it's made many projects I've worked on 200% easier for developers, project managers, and all stockholders.
I think high-Documentation is out of fashion as a reaction to agile, but things are swinging back the other way.
The two essential elements of why this works.
1. Communication (both formal — work related — and informal) is explicitly defined. https://about.gitlab.com/handbook/communication/
2. There's absolute executive sponsorship to work "handbook-first." If it's not in the handbook, it's as if it doesn't exist. The top-down belief in the system enables it to function. https://about.gitlab.com/company/culture/all-remote/handbook...
We recently codified the operating model in a course we're calling TeamOps. It's a first iteration, but anyone is welcome to take the course and provide feedback. https://about.gitlab.com/teamops/
Sharing a personal insight - I'm currently moving flats in the Nuremberg area in Germany which is a little hectic because forced out by the new house flat owner. Async work enables me to take calls and go shopping to organize the move, whilst shifting work hours into the evening or early morning. I am also able to take paid time off (PTO) when needed to prepare the move early December. In my previous office job, I would have needed to reserve a lot of vacation days for this, and ask for permission to start later than 10am, or leave earlier than 4pm. Here at GitLab, I am my own manager [0] and take care about my working hours - it is a personal freedom, and I appreciate these less stressful times a lot. In return, I can take time to focus on private life, and come back refreshed to produce great results (blog posts, talks, helpful replies here and other community channels, etc.).
What I learned in the past 2 years and 9 months at GitLab, is to provide as much context as needed so that someone else in a different timezone can continue async, and is not blocked by anything (low context communication [1]). Also, short toes [2] enable everyone to add their thoughts and opinions, and work with the directly individual responsible (DRI) for the best outcome.
The Slack retention period of 90 days is a great reminder (and also enforcement) to document everything in the handbook. Example from today: I learned that Google docs supports the colon for emoji live-search. Thought of sharing in Slack, but then went with editing the handbook and sending a MR [3] to help everyone find this little efficiency tip in the future - that said, Slack is not a knowledge base. The GitLab handbook is.
Thinking about the past year with a public discussion about speaker diversity at events, I admire our teams to take action to ensure events align with our diversity, inclusion and belonging values. We have updated our event requirements for speakers (MR [4], handbook page [5]), and are working with event organizers and the wider community to help with mentoring and coaching to inspire future speakers.
Last but not least, transparency [6]. Internal and external, I can read and learn async at my own pace. Most of my meetings are optional, and the meeting notes/recording are detailed, with follow-up actions. You'll never recap old meeting notes the next time but reference actioned issues and merge requests. Many issues/epics are public - if you'd like to learn more about my thought leadership strategy for Observability, and all content created and planned, you can follow this epic [7] or my profile activity [8] for example.
I haven't met everyone in-person yet, because of the pandemic, and travel only for some events (KubeCon EU/NA, PromCon EU [9] [10]), but I am looking forward to meet and value these moments. Hard to describe, I feel incredibly connected to my teams albeit living far far away. :-)
Happy to share more thoughts and insights - my role is on the community relations/developer evangelism team, I'm the stable counterpart for the product teams, and collaborate in cross-functional initiatives often. [11] My first [12] and second [13] year blog posts share more experiences too :-)
[0] https://about.gitlab.com/handbook/leadership/#managers-of-on...
[1] https://about.gitlab.com/handbook/communication/#effective-c...
[2] https://about.gitlab.com/handbook/values/#short-toes
[3] https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_request...
[4] https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_request...
[5] https://about.gitlab.com/handbook/marketing/corporate-market...
[6] https://about.gitlab.com/handbook/values/#transparency
[7] https://gitlab.com/groups/gitlab-com/marketing/-/epics/2593
[8] https://gitlab.com/dnsmichi
[9] https://dnsmichi.at/2022/06/13/my-kubecon-eu-experience-firs...
[10] https://opsindev.news/archive/2022-11-23/#promcon-eu
[11] https://about.gitlab.com/handbook/marketing/community-relati...
[12] https://dnsmichi.at/2021/03/02/my-1st-year-all-remote-at-git...
[13] https://dnsmichi.at/2022/03/02/2-years-all-remote-and-2022-v...
I went from working as the annoying guy asking for tests and docs to the manager and we saw a huge improvement in performance, feature release and a reduction in bugs hitting prod. I can attest their way does not work just fine.
Engineering entails a lot of secretarial work that has been "streamlined" by expecting engineers to do it themselves rather than employing professional secretaries to do so. The end result is that it is often left un-done.
The "enforcers" you talk about are basically secretaries, no? Trained individuals with enough understanding of the work at hand to record and file it in a context-aware manner.
Reminds me of the "surgical team" model from The Mythical Man Month [1] wherein there is a suite of people provided to every engineer to minimise their work outside of design and implementation. (At least that's how I remember it, it's a few years since I read it)
I think having advocates or evangelists within the company is important also, people who can interject "good answer, I think it would be valuable to copy this in a document for the next time someone asks"
That is mind boggling. How on earth can MS have an efficient knowledge management with this setup?
How frustrating was it too use for you?
The most sensible way forward seems to me would be just set up a single company SharePoint with a doc store with a predefined data layout. No associated team space around that. Move communication 100% to slack. Link / pin the relevant SP folders to the slack channels.
Just for the dev team this would work as we never moved chat from slack to teams. But we need to
1. interact with the less technical parts of our org (product management, quality & regulatory, BI, V&V, Legal etc)
2. Interact with colleagues from other subsidiaries.
They all use teams, so conversations & especially meetings will happen on teams, people will still store docs and notes there just out of convenience or lazyness.
I do not know how to solve that conundrum.
Easy to use, desktop app, search, and crucially highlights new changes and additions so you can see something is updated
How-tos are an interesting case. I see a lot of informal how-tos in slack. However, how-tos also are the most likely to become stale because if they're needed often enough, they tend to become automated in part or whole. It is by its very nature transitory.
Toplevel: - Work -- Job A: -- Daily notes -- Services -- Auth --- overview --- login flow -- Client -- Logger -- Job B: -- Daily notes -- Architecture -- node -- react -- etc
(edit: sorry about the formatting)
As the scope of your work expands, you add another sub-directory or file where necessary. Once it starts to grow in size, you can start making insightful connections via [[keyword]].
Furthermore, you can pretty much take this knowledge base with you, wherever you go, by uploading the vault file to your google drive and accessing it locally via SMB. Automatic save/backup.
Nicely said. I am getting really stressed out how complex things are becoming. It's already hard to keep up with git, Jira, Bitbucket, AWS, k8s, Helm, JS frameworks, databases and whatsoever. But then add hard to use document management systems and f...ed up processes that are mainly designed for management to get nice reports and not for productivity. Now you are a bad developer and you are a bad document management person because it's simply impossible to be good at all this stuff.
I am constantly preaching to management that we need specialized tech writers and specialized devs that are good at their respective. But I guess it looks cheaper to waste time and energy of engineers on stuff they aren't good at.
It took me quite a few years to realize how dry, boring, and repetitive this makes your writing, and I now choose to write as I talk. Might make for worse documentation, but it's far better for conversing with other people either in real time or in back-and-forths via email.
Say it (at length)
Say what you've said (briefly)
Is how you successfully present things in the US
But according to the network graph on GitHub, Diataxis seems to be more active, although both of them still receive updates.
divio/diataxis-documentation-framework is forked from evildmp/diataxis-documentation-framework, and evildmp is Daniele Procida, the creator of the latter repository and the maintainer of diataxis.fr.
If your documentation doesn't have a search feature, that's the first thing you need to fix.
If you're just bad at searching, well that's a very valuable and learnable skill.
> like setting up my dev environment
> the documentation which had been written both didn't include it (it was customer-facing
The user docs and the dev docs should be different corpses, searchable separately. What you describe sounds very disorganized.
Worst case is that there is detailed documentation but it's all in the comments of twenty different Jira tickets.
I do agree that user docs and dev docs should be separated though, as should specifications and development logs.
Precisely - just as you'd on-board new hires with information about codes of practise for development (code styles, nuances of internal git practice, etc.) you ought to at least have a "Contribution Guidelines" or similar doc that sets out how to structure and record information in the docs.
But yes, the out of date info is a killer.
for me this is the real failure and design documentation being shitty is just a symptom
group design is a really important skill, and people don't even recognize that its a thing
Usually tickets are written, code is changed. Updating existing documentation is an afterthought at best.
Personally I prefer any formal or semi-formal documentation (e.g. Swagger) over a Confluence page any time of the day.
For example, one could structure things where the English documentation is the deliverable. The code merely serves to actualize the document. In this world, we would consider the act of writing documentation of paramout importance, whereas the code is an implementation detail.
I think software as a discipline is distinctly undiscipled about these sorts of concepts.
Documentation is useful when it's job is to help understand why the code is the way it is, what problems are trying to be solved, and what constraints the devs had.
I realized one day that the specs, tests and how-to markdown documentation I wrote all used the same examples.
From that I derived the idea to create a "spec" DSL that could both be run as a test and generate markdown (with screenshots, etc.) to make nice high level how-tos.
Cucumber has the same sort of idea but the DSL really isn't suitable.
Personally, I don't think documents have intent. People have intent. Sometimes they write down some words as an approximate way to communicate their intent in that moment. But if there is a conflict between the written document and the actual intent, it's the human intent that matters.
I also think that drift between written description and actual intent is good and desirable, because it usually means that the humans learned something about what actually needs to happen. So to the extent that documentation acts as leg irons for intent, I'm generally opposed to it. The faster our teams learn, the better the things we make.
Are you saying this person should be hired/paid to store and retrieve the information being sought out?
- Can't find "Technical Specification" in the "<Cool Project>" folder.
- Can't find "Tech Spec" (and vice versa)
- Can't find "<CoolProject>"
Is there some "enable real search functionality" checkbox I've missed, or am I just doing it wrong?
Search is keyword-based, like large-scale search is pretty much anywhere. Expecting "specifications" to match "spec" is expecting too much, same as expecting half your search to match a folder and the other half to match a file the folder is in.
The main thing to keep in mind is that search is content-based, not just filename. So instead, search for key terms you think are in the file, as opposed to focusing on folders/filenames. Start with one or two, then modify or add as necessary to narrow down.
(I currently work at Google, but not in Search or Drive / Docs...)
When I use Google to search the whole web, it DOES match. So how come it doesn't work when I search a small document?
I'm going to take a slightly different interpretation of your comment because I think it's an interesting discussion: are the non-technical people of today less technical than the non-technical people of the MySpace days?
From what I have observed, I would say yes. If you took the bottom 10% of users back then, you might have a hope of teaching them HTML. Today? No chance. In particular I think "willingness to learn anything" has really waned.
If there are more of them now it's probably because computer use expanded 100 fold since then, at least, and the largely self-selected 90s users of the Web, especially, tended to have greater-than-average interest in learning computer crap, so a high proportion of new users were the can't-or-don't-want-to-learn sort. In the 90s a computer still might not be the centerpiece of an office worker or middle manager's desk, and most folks used computers very little at home, if they even had one (data I'm seeing indicates % of households in the US with a computer only hit 50% in 2000).
As much as I hate to admit it, sharepoint works better here.
On the upside for Google docs, commenting and edit suggestions work so well it’s become easier convince people to use Google docs without downloading copies.
And related to this is the state of WYSIWYG markdown editing.
The Basecamp folks created the very polished Trix rich-text drop-in which is a replacement for TinyMce, which while the standard seems to carry issues.
Basecamp explained the issue with most approaches as such:
> Most WYSIWYG editors are wrappers around HTML’s contenteditable and execCommand APIs, designed by Microsoft to support live editing of web pages in Internet Explorer 5.5, and eventually reverse-engineered and copied by other browsers.
> Because these APIs were never fully specified or documented, and because WYSIWYG HTML editors are enormous in scope, each browser’s implementation has its own set of bugs and quirks, and JavaScript developers are left to resolve the inconsistencies.
> Trix sidesteps these inconsistencies by treating contenteditable as an I/O device: when input makes its way to the editor, Trix converts that input into an editing operation on its internal document model, then re-renders that document back into the editor. This gives Trix complete control over what happens after every keystroke, and avoids the need to use execCommand at all.
Unfortunately Trix does not render markdown so can’t be used in a markdown documentation workflow.
Has anyone seen a decent implementation of WYSIWYG for markdown that has the necessary polish to be non-tech friendly?
It's ok to be technical and not enjoy markdown, heh.
In a previous software job, I was participating in a trade show. It was meeting after meeting, with both sales and technical aspects (I was paired with a sales guy). After several days like this, I remember vividly the sales guy saying how this trade show was good, but at the same time complaining how tired he was because all of these meetings. I kept it to myself, but for me, this was nearly like vacations compared to the day to day usual work
However I agree that the extent of it is the key. I think most people actually hate running meetings (it's basically public speaking), but they hate writing documents even more. It's much easier to "voice over" something than to sit and write it out. It's also easier to enforce attendance than to police opening and actually reading documents. So meetings are the path of least resistance/effort.
Confluence and other wiki systems are clearly meant for longer-lived documentation and canonical information. You should link from or attach your working documents (spreadsheets, slide decks etc) to your wiki documentation for people to discover why certain decisions were taken. But if the wiki's discoverability is poor or it's not well-maintained or regularly reviewed, it's basically useless.
Protip: Use wildcards extensively. Differently from Google, Confluence search considers keywords entered to be limited by word delimiters. so foo matches only foo, not barfoo or footer. Use them with some wildcards, foo, and the search results starts to make sense.
It also weights titles incredibly heavy, which combined with the previous part led to me not even noticing it searched the document body for years.
Now you're right it's obviously not that black and white, I'm generalizing. But I think devs often under-estimate how many people in a typical company perceive meeting other internal employees as amongst their primary outputs, as an end in and of itself, not just a means.
A good way to observe this in action is to try and enforce a rule that meetings must have pre-published agendas. Good luck with that! People will just work around it or write useless non-agendas because often a meeting is not to get something specific done, but is used more like a sort of coffee break to split up the day and give people something to look forward to between desk time.
Something else worth remarking on - a lot of people in sales or marketing roles never seem to use word processors. They communicate ideas by sending PowerPoint decks around, often with a density of words in the slides too high to actually project (only readable on hi-dpi screens). Where I last worked there were people whose working hours boiled down to meetings and PowerPoints. They could spend a whole week making a deck, which would only be seen by their colleagues in a meeting. I found it odd but maybe the slide templates help them structure their thoughts.
Interesting - I actually chalk up that to two things: first, people in SWE roles having historically been given a tremendous amount of latitude for behavior that does not conform to "professional" norms. The freedom to dress however they want, work from home, and skip out on meetings they don't want to attend are all of a piece. And second, I think software engineering work is often (generalizing as well) less cross functional than other roles. Gathering requirements and understanding how it fits into a larger company plan is usually tasked out to PMs or tech leads, which is not something I've seen for Finance, HR, Legal, or other functional roles. So the need to schedule their own meetings is also lessened.
I've also noticed the PowerPoint issue: densely packed slides look ridiculous and don't project well. I think a lot of people wind up simply reading off the slides.
It's organized for them, but not for others. This skill is not intuitive to learn, so it shouldn't be shocking.
The real problem is that for those with authority, it seems to pay off that their disorganization affects other people. It makes others artificially reliant on them, which establishes their position even further, and there’s not really any consequences.
Imo, this is cheating at life and the authority someone gets from being disorganized isn’t real success. Real success comes from having true influence and respect from others due to helping them a lot. This is a lot more difficult though.
Oh well. All the people who rule molehills don’t stop anyone else from achieving real success, so they’re only holding themselves back at the end of the day.
One of the advantages of mentoring people is that you can run User Studies whenever you want. Tell them what the code is for and what you want them to do, and then watch them try to figure it out themselves, see how far they can get before you have to stop the experiment (due to them getting frustrated).
You reminded me of a fun idea that I'll probably never do anything with:
Train an AI which is judged on its ability to quickly teach/train _another_ AI how to do the task. So, optimizing for ability to explain.
There isn't a universal note taking application that comes pre-organized for your team's use case. You have to put some work into any tool you use.
Most teams and companies aren't special snowflakes that need individualized organizations, and document hierarchies. There can be such a thing as sensible defaults that you customize or tweak later (no idea if Confluence ships with that - I've only ever seen Confluence installations in their already-screwed-up state). At the same time, an inexperienced user staring at a fresh Confluence install isn't going to get the organization correct right off the bat.
If you have to put in work upfront before the tool is even halfway useful, it better be really damn good after that. Confluence is not.
I personally have never seen it work, but of course I've also only seen a handful of data points.
That's the average wiki. It's a commons and a tragic one. To make docs work you have to treat it more like a codebase: clear ownership, standards, review processes, approvals, up front design, refactoring efforts etc.
Maybe true in large orgs.
But for smaller companies what I've seen is usually paralysis.
e.g. someone notes a problem (maybe just a typo) in the doc. Can they fix it within seconds? If instead they need to raise a ticket then most likely it ain't happening. They move on, and the next person experiences the same problem.
IMO the default should indeed be towards everyone committing at will. Yes that will result in the occasional snafu. Fix that when it happens. (obviously not good practice for the operating manual for a nuclear power plant - but for a <500 person Saas company it is).
Mandating a Jira ticket for simple typo fixes is overkill. But if you make it easy to create a PR directly on the documentation file, without leaving the tab, I don't see an issue. This is already a Github feature.
The default for Confluence is just that, everyone commits at will. There is no structure, tons of duplication, no standards when it comes to naming, formatting, audience, etc. I'm a huge fan of markdown/plain-text solutions, only because linters can be run that force you down one happy path. I don't believe Confluence has linters at all.
It's hard enough to get technical minded people to contribute to a git (or style) based knowledge base.
Pick your poison I guess but I'm quite happy to have testers/BAs/directors/etc able to quickly jot down thoughts roughly than have it disappear into the ether.
A better solution might be that anyone can write the documentation, and there is a maintainer who constantly refactors the wiki to keep it legible. Makes sure the information is not duplicated, adds hyperlinks to things, etc.
It was a directory of files - I think plain text with a few wiki shortcuts, but might have been some sort of early Markdown.
The editing form was basically a text area on top of mercurial.
Similarly things like the edit log were basically dumping the mercurial output into html.
No clue how long it lasted, but it was still in regular use when I left in 2012.
Wrote the whole thing in a few afternoons.
https://discuss.codemirror.net/t/implementing-wysiwyg-markdo...
You would not believe how special some use-cases are, especially when you work with organisations that have highly regulated environments. I've seen anything from markdown files in a git repository being semiautomatically created in a Jenkins run to an organization having built essentially their own wiki software because nothing on the market fulfilled their need at the time (now 5 years later, they realise no-one uses that thing because it is just unintuitive). I have seen organisations that have no content oversight and some who had a whole department of "content czars", whose sole job it was to keep their documentation fresh and updated. I've seen organisations that had strict rules on approving each individual change, with complex approval workflows.
If you have never documented anything, Confluence may be overwhelming, but so will every tool that has "sensible defaults", because before too long, you will start hitting the envelope. Documentation software is not like a MacBook that you just buy and start using, you always need some level of customisation.
So, is Confluence damn good? No - there's a lot that could be improved. But from the mediocre solutions on the market today, it is one of the better choices.
Overall the comments on this page fall into 2 camps, people who've tried it all and found what works is discipline and those who are still trying it all.
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  after you've shown them a couple of times, is this really the person you want writing the documentation for your process?
— The intern I just had to fire last month. She pretended because her generation was born with iPhones, that knowing advanced computer skills like Cmd+V was something that wasn’t a given at 21 years old. It blew my expectations about school - but at least school teaches them to find unexpected arguments.
I think her assessment of the situation is fair.
This makes no sense given that you get the same payoff by using something like Atlassian's wiki. No git, no markdown, none of this nonsense, users can just immediately hit the ground running with advanced formatting support and version history.
I think you're lacking a lot of empathy for nontechnical users. I don't see how you could ever argue that your git + Obsidian stack is "more valuable" than an off-the-shelf wiki solution.
Welcome to the world of non-technical people.
Why do you hire software developers, instead of making software development everyone's responsibility? Is that because most people suck at software development? Well, most people suck at writing documentation, too.
They can’t belong on the side of the world where we make things. She’ll forever belong in the people we’ve designed our apps for, viewing videos, playing games, instagram models, struggling to afford a flat. Maybe we’ll make her rich! Our apps will decide that.
A ticket represents a process (otherwise it has no added value over git commit message) and thus creates much more work than a couple of seconds.
Yep, and that process also involves other people, to review/ approve the fix to the typo.
It then goes from being a few seconds of elapsed time and actual time (to just commit a fix to the typo) to taking hours, days or weeks of elapsed time and hours of actual time and forcing context switching on, and interrupting the workflow of, all of people involved.
Primarily because it's a far, far more complicated job than that and you can't really hire someone off the street to do it effectively. Typically in a tech company a tech writer is going to know almost as much or more (after years of experience diving into every detail) about a given technology or application or API, and so that begs the question why not make twice as much working as a software developer and not have to sort out these types of messes?
Also job security. Anyone doing this work full-time is the first on the chopping block, and developers who are working on documentation tend to be perceived as lower status since they aren't delivering features.
But a different question is, why is no company trying to do this differently? Like, hiring one good tech writer to maintain the company documentation, and paying them as much as they pay the developers.
I once worked at a company - in a different domain - that made a conscious decision to make this kind of hire. It worked incredibly well, and I never understood why more companies didn't do it.
The context in my case was the Australian offices of a management consulting firm (BCG). The Melbourne and Sydney offices hired what were called "editors", brought on at the same grade as the consultants. Not editing as in correcting grammar. But helping the consultants improve the logic of the arguments in their slide decks: so they were logically consistent, easy to understand, and actually addressed the clients' issues. I was a junior consultant back then, and we were constantly pushed by our managers "have you seen Yvonne?" [the Melbourne editor] when preparing for major presentations.
I do like the sibling comment calling for a librarian. I imagine that would pay a ton of dividends if the librarian was motivated and got support.
There are three things that I think are preventing technical writing from being more widely valued:
1. Software companies tend not to distinguish between technical writers who are good at English vs. technical writers who are good at engineering, understand their audience, and can articulate complex ideas to that audience effectively.
2. Technical writers who are good at English make about half as much as technical writers with engineering skills, but they also muddy the hiring waters and drag salaries down for everyone else.
3. Most corporate-people think because they can type up a decent email they can write technical documentation themselves. They're usually wrong on both counts.
He assumes that "full understanding (into every detail) of what is being documented is needed" (as I put it). So, the new hire will never get it right 100%. he will both struggle and annoy others (to forever enlighten him), which is a fair point.
But it is not black or white. Others here have more positive experiences
This comment is absolutely true and many, of not most, companies fail to understand it. I think the problem stems from corporate-people thinking, "Why should I pay a writer when we all speak English (or whatever language) and can write it ourselves." And that's why so many companies have shitty documentation.
> ...so that begs the question why not make twice as much working as a software developer and not have to sort out these types of messes?
I was a software engineer for 30+ years and got completely burned out on it, so I left engineering to do technical writing. So far, I like it much better because I have far more control over my time. In my experience so far, the sorting-out-messes work is about the same in either field. Both jobs are pretty complex. I also make exactly the same as I did while working as an engineer.
I think the secret to not being first on the chopping block is to show you're delivering value to customers and internal teams. At least I attribute that to my survival through multiple layoffs so far.
How did you make this transition? Any credentials/certifications you needed? Did you transition within the same company?
So, to solve the first staleness part, there is only two ways: raise the documenter status, or make it somewhat possible (easier?) for someone else to do at least a part of it. are they both really that hopeless?
PS: to solve the second loss/discovery part, I think we are heading for that AI powered simple "unified search" experience.
1) Link to the documentation in your tools
2) Ensure everyone has edit access to the linked documents
Another idea might be, whenever a new feature is closed out, auto-allocate some percentage of its implementation time to documentation, and schedule an interview with a tech writer.
Library science is a popular area of study but the job market isn’t great and neither is the pay. Lots of people to choose from here even without poaching from existing libraries.
I disagree, I've been apart of a few companies that have done exactly this. I would suggest not presenting this argument as an absolutism.
You partly answered your own question: perhaps you pay the librarian/documentation writer too little? ;-)
Seriously: letting the documentation to be written by such a person won't be as much a cost-reducing measure, but instead mostly an approach to improve the documentation quality.
This isn’t the case for external documentation, that has to be more polished, needs sign offs and images and demos and stuff - tech writers can come in useful here
So even on those rare occasions when they do actually document something, the documentation tends to be pretty bare-bones and not very readable.
Good technical writers are worth their weight in gold.
They're not, actually, as is obvious if you actually read the links. They're human process approaches.
In this sense it was meant that the technological solution - auto documenter tools, etc - they're the butter robots. I was making the point that rather than just shim Yet Another Tool into the stack to do a single but important job (pass the butter / write the docs) perhaps give it to a human who will a) do a much better job and b) reduce the complexity of the stack.
Apologies for the confusion.
I'm surprised how this comment thread took off. Looks like there's plenty of support for AND against. I simply meant to make the point that for some problems humans do better than machines and it can be more efficient in the long term to look away from a tech solution to a human problem.
This is about prioritizing the documentation you write.
Who would supply that person with the information required to write the documentation?
In my opinion, companies should hire subject matter experts who can write rather than just someone with an English degree. I've fixed a lot of terrible documentation written by English majors with no engineering background.
I have empathy for non technical people in that I believe Markdown is far easier to use than Atlassian's interface. Every single developer I've worked with has been tearing their hair out when trying to write documentation on Confluence and documentation never got written as a result. If this is the experience for technical people, what on earth is the experience like for non-technical people?
Nobody cares. Really, they do not. This doesn't help the business, it adds way too much overhead, and requires nontechnical people to understand markdown and git.
I have never heard nontechnical people complain about the Confluence wiki. From their perspective, everything Just Works. Imagine having to tell them all the things that they can't do because of Markdown's limitations, and how much harder it is to do drop-dead simple things like adding tables. Can't you see how that's a 100x higher barrier than anything you can complain about for Atlassian? Anything that you're frustrated at with their editor, you probably can't even do in Markdown. All the markdown stuff is easy.
This is where you lost me and probably many who are following your comments. I have never heard anyone express what you just did about Confluence.
I don't know what accounts for the difference between our experiences, but I work with many nontechnical people, and they have a much different opinion than those who you are listening to. I certainly have never heard anyone say that everything Just Works.
They absolutely care if one day Atlassian decides to hike prices to levels they deem unreasonable and now their entire documentation is locked in a proprietary format or if Atlassian go under, are purchased by a competitor etc.
> I have never heard nontechnical people complain about the Confluence wiki. From their perspective, everything Just Works.
This has not been my experience at all. I've had tons of business analysts join in the Confluence moaning during meetings, both for editing and trying to find stuff. 'Just works' is not how I or anyone I worked with would describe it.
>all the things that they can't do because of Markdown's limitations
what are these things you're so desperate to do in Code Documentation that you can't do in markdown?
> how much harder it is to do drop-dead simple things like adding tables.
This has been a solved problem for a while now. One of the very first Obsidian plugins was the advanced tables plugin which makes it super easy to make and edit tables. There's also other apps like Table Flip. I'm sure there's probably plugins for other editors like VS Code or Table functionality built in to other markdown editors.
The only reasonable point you've got is about git. Like I said in the original post, a WYSIWYG web interface for non-technical folks which just auto commits would be preferable whilst still allowing regular git and markdown for technical folks. There's also nothing stopping anyone from doing an intermediate page if conflicts are detected with a three way conflict resolution page a la Jetbrains Editors with a magic wand auto solve. Maybe the WYSIWYG editor could automatically update if changes are detected a la Google Docs. There are lots of potential ways of solving the 'git hard' issue. There is also the built in Obsidian Sync and Publish which use git behind the scenes and give you access to full version history although I don't know if they scale well or not.
At the end of day, conflicts in documentation are less of an issue when they do happen because they're not going to cause an entire crash of a program, you're just going to have some text that doesn't make sense. In the very worse case scenario non technical people could just copy and paste things back into place from git history. Other than time wasted, it's not the same disaster as if a code conflict is not resolved properly.
Except that like all WYSIWYG editors, Confluence's editor is buggy and unpredictable. You can only use it in a browser. Because it doesn't even have a 'raw' editing mode anymore, you can't work around the WYSIWYG editor when it's broken. Uploading or converting to it from external sources is a PITA, when it's even possible.
If you want technical documentation that developers are going to maintain, it has to be a joy to work with in their own editors.
WYSIWYG isn't actually better. It's a broken paradigm, and that's why every single attempt to move Wikipedia over to a WYSIWYG editor has failed.
Not what we're talking about here though, OP is suggesting it's reasonable to teach business analysts markdown and git for all company documentation.
If I'm working on a library, design docs and commented code is nice though.
Yes, there's a very good reason not to use metadata: it's extra work, and it's not very fun, just like writing docs for software. So people don't want to do it because it isn't "sexy" (and there aren't very good incentives to overcome people's reluctance to do that work).
Because of this, just like any job that people don't really want to do, you have to "bully and cajole" them into doing it.
If you don't include the right metadata, google won't rank you highly. If you include the right metadata, your content will get higher rankings and the snazzy preview cards on different social media platforms.
Metadata is good! There are structural incentives to be mediocre though.
Second, the whole point of AI NLP search (i.e., 2nd part = loss) is that it does not need metadata (which was the basis of the now mostly abandoned semantic web approach to KM).
Clearly they don't. You already said that you tried to pitch your solution, and you weren't able to prove its value. Atlassian is seen as reliable, and those fears are just not worth the hassle of managing your own infrastructure.
> what are these things you're so desperate to do in Code Documentation that you can't do in markdown?
1. We're talking about using Obsidian to replace a company's entire knowledge base, not just code. Code documentation is managed by technical people.
2. What are these things that are so difficult to do in Confluence that are easier in Markdown? It's a superset!
These are table stakes features that everyone expects to work out of the box. If you don't give them a WSIWYG editor that does all of this for you automatically, it's DOA.
Would love to see how that conversation goes.
Your claim that I was responding to is that "everything Just Works" in Confluence, not that Markdown is easier. I have commented on neither Markdown nor their relative ease.
> The typical gripes are around search and organization, not editing.
That would seem to contradict both that everything Just Works and that you have never heard nenontechnical people complain about it.
Unfortunately, you've inserted yourself into a conversation where this is what we're talking about. If you want to talk about something else, maybe start your own thread.
The point of contention here is that Atlassian's wiki is far easier for nontechnical people to deal with than pure markdown and git. And yes, from their perspective, it Just Works. They never wrangle with syntax, there's a massive plugin ecosystem for custom features, and version history works out of the box.
You have lost your own plot then. This is not about Markdown:
> I have never heard nontechnical people complain about the Confluence wiki. From their perspective, everything Just Works.