[stavros]

I'd add "don't use demonstratives, like 'this' and 'that', repeat the clause". Sometimes, "that" is ambiguous, leading to unclear writing.

E.g. "The foo program is running on the bar server. Who is in charge of that?" vs "The foo program is running on the bar server. Who is in charge of the bar server?"

[BossingAround]

Some times, the writers don't want to repeat themselves because they were taught that it's "poor writing." And I'd agree, maybe, in (some) prose.

But in tech docs, please, repeat yourself instead of using "this", "that", "those", etc., even when perfectly non-ambiguous.

This should be preferred "The service is now ready. To check the service's status, ..." over this "The service is now ready. To check its status, ..."

[KineticLensman]

> the writers don't want to repeat themselves because they were taught that it's "poor writing."

Yes! As you say, it massively depends on whether you are writing fiction or non-fiction. In any sort of formal document, especially technical reports, etc, the reader should never have to spend time working out what the author means. I used to be a doc reviewer in a previous life, and lost count of the number of times docs used different terms to mean the same thing, especially where multiple authors were involved, or a single author was writing different sections at different times.

General plea: If you value your readers, please, please get someone else to check a doc to look for these sorts of problems. If multiple authors are involved, always get someone on the team (a lead author?) to do this check even before submitting it for formal review.

[esquivalience]

I found your last paragraph entirely unambiguous at all three levels, which led me to disgree with your overall point. Before that I was with you!

[langcss]

The benefit of "The service is now ready. To check the service's status, ..."

Is when someone needs to amend this sentence later, e.g. inserting another point:

"The service is now ready. This means you can query the health endpoint. To check the service's status, ..."

It makes the writing less likely to become ambiguous.

Most documents I see in work will constantly have sentences added/removed as things change.

[karmakaze]

Many 'rules' including this one can be broken if you know the tradeoffs and can make the case-by-case choices correctly. But that was a poor example for motivating a behaviour.

[andirk]

We should write with *pointers.

[KineticLensman]

Yes, 'this' can be really problematic.

There are two problems with using ‘this’: Firstly, there may be ambiguity in what ‘this’ refers to. If a paragraph starts with ‘this means…’ or similar, it is impossible to understand the paragraph without looking back through the text – which of course makes it hard to dip into a text (e.g. especially in non-fiction, where readers may dip in to find some specific fact). Furthermore, any unit of text starting with ‘this’ cannot be copied and pasted somewhere else (e.g. from the main body of a report into the conclusions), where the meaning of ‘this’ is completely lost.

I think the problem sometimes happens because the author is writing in a flow state (they are ‘in the zone’) and is creating text that relates to their current mental model of something. This mental state is of course not accessible to a reader, or perhaps not even to the same author at a later date.

Solutions include getting an independent review by someone who isn’t also involved in the writing process, or if this is impossible, reviewing the text yourself after leaving it alone for a while. The ‘this at the start of a text unit’ problem is analogous to a linting check and doesn’t need to be done by a domain expert.

[latexr]

Repeating the clause can be useful, but I don’t think it should be used as a general rule. Avoiding ambiguity does not mean forcing repetition and making dull prose. Example:

> The foo program is running on the bar server. Who is in charge of the latter?

Though in general that¹ is still weak. Depending on the surrounding context (which isn’t present in your comment) and the main idea, a possibly better example:

> Who is in charge of the bar server running the foo program?

Without a real use case, we could spend days discussing what is “better”.

Though yes, removing “that” can improve the text, thought that² doesn’t mean you need to replace it with anything. Let’s take the first paragraph in the article:

> Writing a technical document is surprisingly hard. That is not because of the skill to tell a story. It’s because writing forces a level of clarity that is easy to gloss over while thinking through a topic.

An alternative without any “that”:

> Writing a technical document is surprisingly hard. Not because of the skill required to tell a story, but because writing forces a level of clarity otherwise easy to gloss over while thinking through a topic.

¹ I don’t think there’s any ambiguity the “that” is referring to the previous sentence.

² I don’t think there’s any ambiguity the “that” is referring to improving the text.

[nvader]

I want you to know that¹ I enjoyed reading this comment, more than just an upvote could convey.

¹ ;)

[neuralRiot]

Another thing worth pointing out is that technical texts are rarely read entirely as a literary piece, so repeating things is a welcome thing. As someone who spends great part of the day reading datasheets it is specially annoying having to scan through the entire piece to see what something means like for example acronyms:

“The setting of these bits is only valid if the BCST bit in FBCSTAT is 1, while the FRDY bit in FSTATR is 1.”