Docs for Developers: An Engineer’s Field Guide to Technical Writing

> Serious question, if you're going to hire people who are great technical writers, why would you have software developers (who are by definition not going to be as good TWs as the "real" TWs) also do it?

Software engineers are the SMEs whose knowledge TWs are trying to crystallize into documentation; them being disengaged from the documentation effort is the same problem as business SMEs being disengaged from the software development process. And, for much technical documentation, developers of the software are also part of the target audience, as one function the documentation serves is knowledge preservation.

Docs need tech SME and target audience engagement for the same reason software needs business SME and user community engagement.

> You wouldn't expect TWs to dabble in the prod codebase.

I actually think you should expect TWs to dabble in the prod codebase. At least for TWs writing docs for developer products. To write the Chrome DevTools and Lighthouse docs I frequently looked at the implementation to figure out how things actually worked. From time to time someone would file an issue on the docs and we would realize it's really just a flaw in the product that can be relatively easily fixed. I couldn't get engineers to prioritize the work but if I put in a fix myself someone would review/approve it. Rather than jump through hoops to update the docs to reflect this quirk, it was often faster to just put in a fix in the product itself.

> if you're going to hire people who are great technical writers, why would you have software developers (who are by definition not going to be as good TWs as the "real" TWs) also do it

As mentioned in the last paragraph, a difference between our viewpoints is that I do expect TWs to dabble in the codebase, so perhaps it's not a stretch to imagine how your business might improve if you also work in reverse (engineers dabbling in docs). In practice, the real "synergy" happens when engineers get into the doc creation process early and often. For example, a writer might create a very rough draft of a guide and ask the engineer to review for technical accuracy only. (Edit: as dragonwriter mentioned, it's often much more efficient for TWs to go to engineers for technical information, rather than deciphering it out of code, PRDs, etc.)). Or, have engineers write the very rough draft themselves and have the TW turn it into a polished document. Another approach is when the engineer is very motivated to improve their writing, and they take on writing a doc, and the TW works with them step-by-step to polish it into a usable doc. My hunch is that for any given org, you'll only have a minority of engineers who want to improve their writing like this, but when it happens it should be prioritized/rewarded/encouraged. One area where it might make sense for engineers to mostly own the docs is API references. There should be an expectation that any changes to the API should also require a doc update. Another useful expectation would be to have engineers review docs after making a change to the product and make sure the required documentation update is at least logged as an issue somewhere. Over time you tend to see engineers engaging with TWs more substantially ("I was reviewing the doc for change X and noticed that the overall organization of the guide seems a bit off...").

I'm not arguing that engineers should take on all the docs work themselves, just as I'm not arguing that TWs should take on all major software development. But from my experience there's a lot of benefit to having each role systematically take on a bit of ownership of each other's domain.

If you have 1 TW and 50 devs, it will speed things up a lot if the devs can at least churn out the rough drafts and the TW can clean them up and link them together.

Learning to write documentation (which is really just trying to write them over a long period of time) is a skill that improves your overall communication skills. Devs should want to improve those skills (as everyone should), so they should want to write at least some docs.

Because the developers are literally writing the source of truth for the docs. They know the information best, even if they aren't necessarily the best at presenting it or doing all of it. They certainly are the best for forming the rough draft of correct information.

I can see the argument for the "Lead" model, where you have a single technical writer who takes a tech-lead-like responsibility for documentation and writing bit doesn't necessarily do it all themselves.

A Decoy is when you introduce an option in the menu that is "absurdly" or illogically priced, in order to make other options seem like a better deal. Some examples:

- Some restaurant menus will have 1-2 incredibly expensive entrees or appetizers. They know the volume on these items will be low, but they make other items seem less expensive by comparison.

- The most famous example is how the Economist did pricing for their online and print offerings -- The offered Online-only for $60, Print for $125, and Print + Online for $125. Obviously the Print-only option makes no sense, it's just there to make the Print + Online seem like a better deal, and push you away from the cheaper $60 offering. A less pop-up filled explanation is here: https://cxl.com/blog/pricing-experiments-you-might-not-know-...

What an interesting reaction.

The trick with Apple Pay is that supposedly you have already accepted Apple's TOS and they already have your cards so you do not need additional registrations.

In Apple's grand, glorified vision that should be the only one you need.

While that plays a role, it's a bit odd to single out Dutch for that - far from the only European country where that is the case.

Mr. Westerbiek is saying that Dutch people think they're better at English than they generally are.

Or maybe I misunderstood that? I'm Dutch, so who knows...

I think you should look into what Netlify actually does--you seem to be misunderstanding it as a typical hosted compute platform like EC2. With Netlify and similar service it's actually more like AWS lambda but tightly integrated into git/github. You push all your content source to github and setup a webhook that notifies Netlify of any change. Every time you commit Netlify will pull down your content, run your static site generator (docusaurus) in an ephermal container (like a lambda function) and then save the resulting generated content/HTML to their hosting site. At no time are you running or managing or operating an actual server.

Check out Netlify, I think you'd really like its build previews. Basically go through a teeny bit of pain once to set it up and then all you have to do is push updated documentation files to github. Netlify will detect the changed files, rebuild your site using docusaurus, and send you a URL to hit to immediately view the updated docs as a preview. If you like it you click a button and make it live, otherwise you go back and edit and revise. You don't need to janitor or babysit a local install after the initial setup. Check out more info in some of their tutorials: https://www.netlify.com/blog/2016/09/29/a-step-by-step-guide...