6 ms·

Get started with technical writing

159 points by billybuckwheat 3y ago

wmidwestranger 3y ago
Way back when I was a young lad, a hiring manager found me because I had an English major and hired me to help maintain a manual for a small bank system. I did a hell of a job but the job was hell. My manager actually put a co-worker in a choke hold at a customer site while they were transitioning their bank to the system. This was way back when, and I put way to much effort into my work; they were dragged along and the whole thing was thankless. That said, I managed to rewrite 800 pages of small bank management documentation into 600 pages of well-formatted, _readable_ manual. I don't know if it was worth it, I was in Lincoln, NE and I didn't have anything better to do. I dropped the readability statistics from freshman in college to freshman in high-school and I'm sure the customer was more the latter than the former. Not to judge, I never met a customer that wasn't worth helping. Am I especially good at writing? Not in my opinion. You'll quickly find it is a target rich environment. The manual I edited could not resist saying, "Put the applicable value into the blah-blah input". Of course, what other value would you put there? Back then, there were some serious efforts in the field to generate multiple deliverables from a single-source. I have no idea if anyone thinks of that anymore. I've been developing ever since and I haven't worked on a product that even thought they needed a manual. That banking software was written for an IBM mainframe and ran in an emulator so it could work in Windows and it didn't even have the worst user interfaces I've seen since. Maybe this is a career? I dunno, the author of "Zen and the Art of Motorcycle Maintenance" was a technical writer, he also spent a stint in a mental institution. Maybe it was the software he was documenting? I can't say. I'd just like to thank the OP for the chance to tell this story.
- tomcam 3y ago
  > Am I especially good at writing? Not in my opinion. You’re an excellent writer.
  - wmidwestranger 3y ago
    Thank you, sir. I'll keep this in mind when I doubt myself. Much appreciated.
  - roydivision 3y ago
    Agreed, you craft a good sentence.
- greenie_beans 3y ago
  > My manager actually put a co-worker in a choke hold at a customer site while they were transitioning their bank to the system. wait what? gotta hear the full story
  - wmidwestranger 3y ago
    Yeah, he was their lead of training. He had worked in small to medium banks and then tried to set up a consulting business but that's hard enough without having the temperament that leads to putting a co-worker in a choke hold. I _can_ imagine worst managers but he was pretty tough for me, since I didn't want to waste my time doing poor work when I could be doing good work. So this system was about as user-friendly as you can imagine any 30+ year old bank management software. They would sent a team to on-board new banks. The team would usually have this manager or his subordinate, a networking guy, senior support staff. This manager happened to be very hard of hearing but was unwilling to get a hearing aid or sort that out. So him and the others were out drinking after the previous day was over and he was trying to hit on a lady that clearly wasn't interested but he couldn't hear her clearly nor read her lips well enough to take a clue. The next day, in the bank, the networking guy who had been there forever and was friends with the President said something about how he couldn't take a hint and my manager lost his cool, put him in a headlock in the middle of the bank, and probably came to his senses a few minutes later. He was sent back early and the story returned with the rest of the team. This was a small / medium business and he was relieved of joining the on-boarding crews but kept his job. Lots of mixed feelings about that place. While it paid terribly, it is the only place I've worked in 20 years where there was an honest to god retirement party for one of their QA staff.
starkparker 3y ago
> What tools do you use for your writing? > Writers mentioned a number of Open Source options, including Joplin, Asciidoctor and GNU groff. This is a gobsmackingly bizarre list. Joplin is a note-taking app, Asciidoctor is a processing/publishing tool for AsciiDoc, and groff is mostly for publishing CLI docs/man pages. Most technical writers work in either DITA XML, AsciiDoc, reStructured Text, or Markdown. Aside from using oXygen for XML, you're probably in VSCode or some other open-source plain text editor with a plugin to preview the output. That content often lives in a git repo, or alongside code in a monorepo. It goes through a publishing tool like the DITA Open Toolkit, AsciiDoctor, Sphinx, a static site generator, etc. Translation typically involves Gettext/Poedit at some point between a variety of frontends, though scaling that is often how tech writing teams wind up going down the DITA XML rabbit hole. > Lauren Pritchett: "When I was writing more frequently I liked to write in Atom or something like that in Markdown, then put it in a Markdown-to-HTML converter and plop it into Drupal…" No. No! This is nonsense. In technical docs you absolutely have to have a publishing pipeline that doesn't include a manual copy-paste step into a CMS order to scale. In technical blogs you're authoring closer to the CMS. This makes zero sense. > I really enjoyed working with LibreOffice because of the ability to create templates, repeat processes, ebooks and cheat sheets… There are mature and popular open-source tools to do all of those things in AsciiDoc/rST/Markdown that are easier and better at scale than LibreOffice. Even DITA and the DITA-OT can do most of this, though working with XSLTs sucks. Notably, Pritchett's background is primarily in marketing content, whitepapers, blogging, and traditional book publishing, not product docs: https://hilgspritch.github.io/work.html https://hilgspritch.github.io/work.html > ... (git and Markdown is) not intuitive, I much prefer Google Docs If you're doing technical product or dev documentation work, you might be in Google Docs as a bridge with product and marketing, and maybe you legitimately prefer GDocs review tools for editing early drafts of prose. But if you're writing documentation, then writing docs as code in the same tools and processes ships the docs alongside the implementation. If you can't become competent using git, you're going to struggle mightily in non-marketing tech writing roles. If you're documenting software, and even if your team isn't writing docs as code, you still need to be able to understand git and fundamental concepts of it well enough to work with the product you're documenting. Your publishing pipeline is probably using a combination of git, CI, and cloud storage, and if your team doesn't have anyone on it who can understand those things then you aren't shipping docs as fast as you could be. Very few non-marketing technical writers make it these days without being competent in git. - Also, more generally there's no disclaimer that the moderator of the talk spends a chunk of it talking up a blog that his own consulting company runs and prominently sponsors.
blindriver 3y ago
The two most thankless jobs in tech are Project Manager (ie, the person who keeps track of project progress) and Tech writer. Both have been continuously blown off by engineers since the dawn of my career, 30 years ago. Both are powerless to hold engineers accountable and especially Tech Writers don't get any credit even though most customers rely on them completely. Engineers think they're too good and too busy to do technical writing for documentation, but then blow off technical writers who want to do the work for them and just need a few hours to understand features, etc. I had an idea 10 years ago to hire a bunch of English majors as interns for the summer to bootstrap a big technical writing project, but that got shut down almost immediately. No engineer values tech writers, because they envision themselves as large great white sharks, and the tech writers to them are just bottom feeders that exist in their ecosystem.
- wmidwestranger 3y ago
  One of the most hilarious ironies about technical writing is that the writer has to do so much more reasoning about the system as an interconnected and operating system so they can describe how the user interacts with that system. I think you're correct about how PMs and technical writers are regarded and, as sad as it is, the truth is that engineers are usually rewarded through moving tickets from Not Started to Finished instead of building working and reasonable systems. If "finishing" tickets is where the money is, taking the time to reason about how any ticket fits into a coherent and correct system is an expensive process. More often than not, people are not successful because their projects are so good but that the project was good enough, long enough, and they moved on to greener pastures before the mistakes caught up with the system.
- RickJWagner 3y ago
  Tech writers are like the hub in a team-wheel. What they learn, they amplify and share. It's the greatest ROI of all the team positions. Hats off to our under-appreciated friends, the writers. P.S. I once worked at a place where many of the Engineering managers started out in Tech Writing. It made perfect sense, because the writers had to know everything to document it. A good Engineer will master one tiny sliver, plus may have knowledge of a few adjacent parts. The Writer hears/sees/writes it all.
roydivision 3y ago
I've been mulling over the idea of transitioning from Sysadmin/DevOps into technical writing for a while now. To any technical writers listening : - Can one make a living from it? - Typically are you working on a consultant basis, or permanently for a company? - The job seems like an ideal WFH gig, is this the case? - Seems to me you will need a 'portfolio' to get work? I'm guessing starting with Open Source projects would be a good way to build up a body of work? Cheers. (edit - formatting)
- dieselgate 3y ago
  I worked a year as a contract technical writer between undergrad engineering and starting a dev job. It was mainly a lot of manufacturing process documentation and process time studies. Technical writing can vary quite a lot.
- nickfromseattle 3y ago
  I worked with an engineer that transitioned into technical writing. They worked in-house as an FTE and owned the company's knowledge base, and had no prior experience with our industry before his role. It seemed like a lot of: - Developing and enforcing a style guide - Updating and creating new docs - Communicating with PM / dev / support for prioritization & accuracy B2B companies with enterprise customers need good docs to scale support and I'd imagine technical writing for open source projects + a technical CV should be enough to help you land a job.
- nprateem 3y ago
  AI will destroy tech writers.
  - mikeravkine 3y ago
    Where do I get one of these tech writing destroying AIs that will both understand how to use my product and produce clear, concise guides for doing so without burdening the existing team?
    - dv-tw 3y ago
sarupbanskota 3y ago
I was hoping to discover tools, free or paid, that specifically help with editing copy aimed at a technical audience. There's clearly a fact-based, no BS writing style that resonates well with HN for example. Are there tools that help detect such BS in writing? Hemingway Editor comes to mind, what else?
- remoquete 3y ago
  The Vale linter, though it requires some initial decisions. https://passo.uno/posts/first-steps-with-the-vale-prose-linter/ https://passo.uno/posts/first-steps-with-the-vale-prose-lint...
  - sarupbanskota 3y ago
    So cool. Looks like the proselint site is down. For anyone else who wanted to read the approach - https://github.com/amperser/proselint/blob/b5b7536bec5fd461e45cacad87c2aab9ea33ac35/site/_posts/2014-06-10-approach.md https://github.com/amperser/proselint/blob/b5b7536bec5fd461e...
zerojames 3y ago
I am a technical writer and have been for ~4 years. I love the work that I do. I got started because I loved coding and writing. I see my job as taking in as much information as possible and distilling it into what I think the target reader needs to know. Indeed, I am often asked to document projects just before they are out of the door. Taking ownership over that process, and thinking hard about how I should articulate information, is a delight. That reader might be someone who is learning a skill (for whom I am writing a "how to"), or a customer who needs to know how to use a software package (for whom I am writing reference and quickstart documentation). Technical writing has led to some interesting personal stories. An old friend found one of my technical articles while studying for a course; that warmed my heart. As I have written more, I get the occasional email from a student asking about my work. Happy to answer more questions! (but, honestly, I should blog about this!) As for getting started with technical writing, setting up a personal blog is a good idea. Document a project you have made in the past, whether it is a website and how you built it, a software library that you made, etc. Or contribute to existing documentation if you have expertise that you can lend (i.e. add a quickstart to a library you use and love, contribute to MDN if you notice something that could be improved).
- zerojames 3y ago
  I have written a post about this: https://jamesg.blog/2023/11/27/technical-writing/ https://jamesg.blog/2023/11/27/technical-writing/
KineticLensman 3y ago
Something not really discussed here is technical report writing, something I’ve done a lot of while working on govt-funded research tasks, usually in the world of simulation-based training. The aim isn’t to write documentation or user-manuals, but to communicate findings from tech research / de-risking projects to decision makers and other stakeholders, in my case often exploring the question “is this technology ready to use in this context, and if so, what should we do next”. The findings themselves are often generated by tech staff, sometimes involving academics, based on building prototypes and then deploying them in a semi-realistic context with some tame users. I’ve participated in report writing as author, editor and reviewer and over the years learned a lot about writing in general. Key for me was understanding the decision that the reader would make as a result of reading the doc, and then ensuring that the doc did in fact present the necessary evidence and ideally some actionable recommendations. The absolute worst thing was when people started writing and just hoped that the answer would somehow emerge (which I admit is sometimes a useful way of getting your thoughts straight), but then just stopped when they ran out of time / budget. One of my most useful roles as a reviewer, was to conduct a 20% review, near the beginning of the writing, when I would confirm with the authors what sort of message they wanted to get across, and ideally storyboard how they were going to do it. Also, when multiple authors were involved, it was critical to make they sure they used styles etc consistently, and ideally adopted consistent terminology. I also began to appreciate the importance of an executive summary – the bottom-line-up-front, on a single page or less. If the person who commissioned the work was senior enough, sometimes this was the only bit they would read themselves, leaving the gory detail to minions.
linsomniac 3y ago
Over the last couple weeks I wrote some extensive documentation for an Open Source project, and I ended up using mkdocs published to github pages when I commit, via github-actions. That's been a really spectacular experience. About half of the docs are just direct Markdown, and the other half are in python docstrings, pulled by mkdocs automatically. The "mkdocs serve" dev server works amazingly well for visualizing changes. Highly recommended.
- dv-tw 3y ago
  I love working with mkdocs. I just used it for the first time this year, and I found it to be very straightforward. It allows for just the right amount of customization for my needs.

Way back when I was a young lad, a hiring manager found me because I had an English major and hired me to help maintain a manual for a small bank system. I did a hell of a job but the job was hell. My manager actually put a co-worker in a choke hold at a customer site while they were transitioning their bank to the system. This was way back when, and I put way to much effort into my work; they were dragged along and the whole thing was thankless. That said, I managed to rewrite 800 pages of small bank management documentation into 600 pages of well-formatted, _readable_ manual. I don't know if it was worth it, I was in Lincoln, NE and I didn't have anything better to do. I dropped the readability statistics from freshman in college to freshman in high-school and I'm sure the customer was more the latter than the former. Not to judge, I never met a customer that wasn't worth helping. Am I especially good at writing? Not in my opinion. You'll quickly find it is a target rich environment. The manual I edited could not resist saying, "Put the applicable value into the blah-blah input". Of course, what other value would you put there? Back then, there were some serious efforts in the field to generate multiple deliverables from a single-source. I have no idea if anyone thinks of that anymore. I've been developing ever since and I haven't worked on a product that even thought they needed a manual. That banking software was written for an IBM mainframe and ran in an emulator so it could work in Windows and it didn't even have the worst user interfaces I've seen since. Maybe this is a career? I dunno, the author of "Zen and the Art of Motorcycle Maintenance" was a technical writer, he also spent a stint in a mental institution. Maybe it was the software he was documenting? I can't say. I'd just like to thank the OP for the chance to tell this story.

tomcam 3y ago
> Am I especially good at writing? Not in my opinion. You’re an excellent writer.
- wmidwestranger 3y ago
  Thank you, sir. I'll keep this in mind when I doubt myself. Much appreciated.
- roydivision 3y ago
  Agreed, you craft a good sentence.
greenie_beans 3y ago
> My manager actually put a co-worker in a choke hold at a customer site while they were transitioning their bank to the system. wait what? gotta hear the full story
- wmidwestranger 3y ago
  Yeah, he was their lead of training. He had worked in small to medium banks and then tried to set up a consulting business but that's hard enough without having the temperament that leads to putting a co-worker in a choke hold. I _can_ imagine worst managers but he was pretty tough for me, since I didn't want to waste my time doing poor work when I could be doing good work. So this system was about as user-friendly as you can imagine any 30+ year old bank management software. They would sent a team to on-board new banks. The team would usually have this manager or his subordinate, a networking guy, senior support staff. This manager happened to be very hard of hearing but was unwilling to get a hearing aid or sort that out. So him and the others were out drinking after the previous day was over and he was trying to hit on a lady that clearly wasn't interested but he couldn't hear her clearly nor read her lips well enough to take a clue. The next day, in the bank, the networking guy who had been there forever and was friends with the President said something about how he couldn't take a hint and my manager lost his cool, put him in a headlock in the middle of the bank, and probably came to his senses a few minutes later. He was sent back early and the story returned with the rest of the team. This was a small / medium business and he was relieved of joining the on-boarding crews but kept his job. Lots of mixed feelings about that place. While it paid terribly, it is the only place I've worked in 20 years where there was an honest to god retirement party for one of their QA staff.

starkparker 3y ago

> What tools do you use for your writing? > Writers mentioned a number of Open Source options, including Joplin, Asciidoctor and GNU groff. This is a gobsmackingly bizarre list. Joplin is a note-taking app, Asciidoctor is a processing/publishing tool for AsciiDoc, and groff is mostly for publishing CLI docs/man pages. Most technical writers work in either DITA XML, AsciiDoc, reStructured Text, or Markdown. Aside from using oXygen for XML, you're probably in VSCode or some other open-source plain text editor with a plugin to preview the output. That content often lives in a git repo, or alongside code in a monorepo. It goes through a publishing tool like the DITA Open Toolkit, AsciiDoctor, Sphinx, a static site generator, etc. Translation typically involves Gettext/Poedit at some point between a variety of frontends, though scaling that is often how tech writing teams wind up going down the DITA XML rabbit hole. > Lauren Pritchett: "When I was writing more frequently I liked to write in Atom or something like that in Markdown, then put it in a Markdown-to-HTML converter and plop it into Drupal…" No. No! This is nonsense. In technical docs you absolutely have to have a publishing pipeline that doesn't include a manual copy-paste step into a CMS order to scale. In technical blogs you're authoring closer to the CMS. This makes zero sense. > I really enjoyed working with LibreOffice because of the ability to create templates, repeat processes, ebooks and cheat sheets… There are mature and popular open-source tools to do all of those things in AsciiDoc/rST/Markdown that are easier and better at scale than LibreOffice. Even DITA and the DITA-OT can do most of this, though working with XSLTs sucks. Notably, Pritchett's background is primarily in marketing content, whitepapers, blogging, and traditional book publishing, not product docs: https://hilgspritch.github.io/work.html https://hilgspritch.github.io/work.html > ... (git and Markdown is) not intuitive, I much prefer Google Docs If you're doing technical product or dev documentation work, you might be in Google Docs as a bridge with product and marketing, and maybe you legitimately prefer GDocs review tools for editing early drafts of prose. But if you're writing documentation, then writing docs as code in the same tools and processes ships the docs alongside the implementation. If you can't become competent using git, you're going to struggle mightily in non-marketing tech writing roles. If you're documenting software, and even if your team isn't writing docs as code, you still need to be able to understand git and fundamental concepts of it well enough to work with the product you're documenting. Your publishing pipeline is probably using a combination of git, CI, and cloud storage, and if your team doesn't have anyone on it who can understand those things then you aren't shipping docs as fast as you could be. Very few non-marketing technical writers make it these days without being competent in git. - Also, more generally there's no disclaimer that the moderator of the talk spends a chunk of it talking up a blog that his own consulting company runs and prominently sponsors.

blindriver 3y ago

The two most thankless jobs in tech are Project Manager (ie, the person who keeps track of project progress) and Tech writer. Both have been continuously blown off by engineers since the dawn of my career, 30 years ago. Both are powerless to hold engineers accountable and especially Tech Writers don't get any credit even though most customers rely on them completely. Engineers think they're too good and too busy to do technical writing for documentation, but then blow off technical writers who want to do the work for them and just need a few hours to understand features, etc. I had an idea 10 years ago to hire a bunch of English majors as interns for the summer to bootstrap a big technical writing project, but that got shut down almost immediately. No engineer values tech writers, because they envision themselves as large great white sharks, and the tech writers to them are just bottom feeders that exist in their ecosystem.

wmidwestranger 3y ago
One of the most hilarious ironies about technical writing is that the writer has to do so much more reasoning about the system as an interconnected and operating system so they can describe how the user interacts with that system. I think you're correct about how PMs and technical writers are regarded and, as sad as it is, the truth is that engineers are usually rewarded through moving tickets from Not Started to Finished instead of building working and reasonable systems. If "finishing" tickets is where the money is, taking the time to reason about how any ticket fits into a coherent and correct system is an expensive process. More often than not, people are not successful because their projects are so good but that the project was good enough, long enough, and they moved on to greener pastures before the mistakes caught up with the system.
RickJWagner 3y ago
Tech writers are like the hub in a team-wheel. What they learn, they amplify and share. It's the greatest ROI of all the team positions. Hats off to our under-appreciated friends, the writers. P.S. I once worked at a place where many of the Engineering managers started out in Tech Writing. It made perfect sense, because the writers had to know everything to document it. A good Engineer will master one tiny sliver, plus may have knowledge of a few adjacent parts. The Writer hears/sees/writes it all.

roydivision 3y ago

I've been mulling over the idea of transitioning from Sysadmin/DevOps into technical writing for a while now. To any technical writers listening : - Can one make a living from it? - Typically are you working on a consultant basis, or permanently for a company? - The job seems like an ideal WFH gig, is this the case? - Seems to me you will need a 'portfolio' to get work? I'm guessing starting with Open Source projects would be a good way to build up a body of work? Cheers. (edit - formatting)

dieselgate 3y ago
I worked a year as a contract technical writer between undergrad engineering and starting a dev job. It was mainly a lot of manufacturing process documentation and process time studies. Technical writing can vary quite a lot.
nickfromseattle 3y ago
I worked with an engineer that transitioned into technical writing. They worked in-house as an FTE and owned the company's knowledge base, and had no prior experience with our industry before his role. It seemed like a lot of: - Developing and enforcing a style guide - Updating and creating new docs - Communicating with PM / dev / support for prioritization & accuracy B2B companies with enterprise customers need good docs to scale support and I'd imagine technical writing for open source projects + a technical CV should be enough to help you land a job.
nprateem 3y ago
AI will destroy tech writers.
- mikeravkine 3y ago
  Where do I get one of these tech writing destroying AIs that will both understand how to use my product and produce clear, concise guides for doing so without burdening the existing team?
  - dv-tw 3y ago

sarupbanskota 3y ago

I was hoping to discover tools, free or paid, that specifically help with editing copy aimed at a technical audience. There's clearly a fact-based, no BS writing style that resonates well with HN for example. Are there tools that help detect such BS in writing? Hemingway Editor comes to mind, what else?

remoquete 3y ago
The Vale linter, though it requires some initial decisions. https://passo.uno/posts/first-steps-with-the-vale-prose-linter/ https://passo.uno/posts/first-steps-with-the-vale-prose-lint...
- sarupbanskota 3y ago
  So cool. Looks like the proselint site is down. For anyone else who wanted to read the approach - https://github.com/amperser/proselint/blob/b5b7536bec5fd461e45cacad87c2aab9ea33ac35/site/_posts/2014-06-10-approach.md https://github.com/amperser/proselint/blob/b5b7536bec5fd461e...

zerojames 3y ago

I am a technical writer and have been for ~4 years. I love the work that I do. I got started because I loved coding and writing. I see my job as taking in as much information as possible and distilling it into what I think the target reader needs to know. Indeed, I am often asked to document projects just before they are out of the door. Taking ownership over that process, and thinking hard about how I should articulate information, is a delight. That reader might be someone who is learning a skill (for whom I am writing a "how to"), or a customer who needs to know how to use a software package (for whom I am writing reference and quickstart documentation). Technical writing has led to some interesting personal stories. An old friend found one of my technical articles while studying for a course; that warmed my heart. As I have written more, I get the occasional email from a student asking about my work. Happy to answer more questions! (but, honestly, I should blog about this!) As for getting started with technical writing, setting up a personal blog is a good idea. Document a project you have made in the past, whether it is a website and how you built it, a software library that you made, etc. Or contribute to existing documentation if you have expertise that you can lend (i.e. add a quickstart to a library you use and love, contribute to MDN if you notice something that could be improved).

zerojames 3y ago
I have written a post about this: https://jamesg.blog/2023/11/27/technical-writing/ https://jamesg.blog/2023/11/27/technical-writing/

KineticLensman 3y ago

Something not really discussed here is technical report writing, something I’ve done a lot of while working on govt-funded research tasks, usually in the world of simulation-based training. The aim isn’t to write documentation or user-manuals, but to communicate findings from tech research / de-risking projects to decision makers and other stakeholders, in my case often exploring the question “is this technology ready to use in this context, and if so, what should we do next”. The findings themselves are often generated by tech staff, sometimes involving academics, based on building prototypes and then deploying them in a semi-realistic context with some tame users. I’ve participated in report writing as author, editor and reviewer and over the years learned a lot about writing in general. Key for me was understanding the decision that the reader would make as a result of reading the doc, and then ensuring that the doc did in fact present the necessary evidence and ideally some actionable recommendations. The absolute worst thing was when people started writing and just hoped that the answer would somehow emerge (which I admit is sometimes a useful way of getting your thoughts straight), but then just stopped when they ran out of time / budget. One of my most useful roles as a reviewer, was to conduct a 20% review, near the beginning of the writing, when I would confirm with the authors what sort of message they wanted to get across, and ideally storyboard how they were going to do it. Also, when multiple authors were involved, it was critical to make they sure they used styles etc consistently, and ideally adopted consistent terminology. I also began to appreciate the importance of an executive summary – the bottom-line-up-front, on a single page or less. If the person who commissioned the work was senior enough, sometimes this was the only bit they would read themselves, leaving the gory detail to minions.

linsomniac 3y ago

Over the last couple weeks I wrote some extensive documentation for an Open Source project, and I ended up using mkdocs published to github pages when I commit, via github-actions. That's been a really spectacular experience. About half of the docs are just direct Markdown, and the other half are in python docstrings, pulled by mkdocs automatically. The "mkdocs serve" dev server works amazingly well for visualizing changes. Highly recommended.

dv-tw 3y ago
I love working with mkdocs. I just used it for the first time this year, and I found it to be very straightforward. It allows for just the right amount of customization for my needs.