The author prefers a writing style that is very^0 different from my own, and is presenting it as objectively better. This is another example--again about comments!--of the programmer personality...
The author prefers a writing style that is very^0 different from my own, and is presenting it as objectively better. This is another example--again about comments!--of the programmer personality type trying to simplify something hugely complex--here, the art of writing--into simple, easily-digestible rules. I wonder if it comes from the way programmers abstract the systems they work on to similarly simple rules with the goal of simple, easily-digestible rules, i.e. code. His dislike of conversational comments is fine, as an opinion, but there's something to be said^1 for that style. It puts the writer in the mind of talking to the rubber duck and I've found bugs in my code by writing comments like this. I have a conversation with myself while writing comments, and that internal monologue helps me understand the code better and find bugs. Furthermore, it helps the reader feel like they're having a conversation with the developer, as if they were pair programming.
The author furthermore seems to be an extreme proponent of the "omit needless words" school, specifically Stephen King's "adverbs are bad"^2 subschool. His likening technical writing to business writing belies a greater problem (actually, two). First, business writing isn't technical writing. The audience is different, the purpose is different, the rules are different. Second, Adams was really describing email writing, but called it business writing. The two are different; if you've ever suffered through an email written by an executive, you know what I'm talking about. If you substitute "email" for "business" in his post, all the rules are valid. Well, except the Strunk- and King-esque miserly approach to adjectives and adverbs.
Furthermore, the author's advice has some other mistakes, most critical being not knowing the audience. His anecdote regarding an Irish employer is not justification for avoiding the colorful uses of language that excite and allure; rather, it's more a reflection on his Irish coworkers not knowing their audience and not adjusting accordingly. Most of the "big bag of examples" are just unclear writing, the kind of writing someone creates when they don't fully understand what they're trying to say. There's a difference between unclear thoughts and bad writing. One can have perfectly clear thoughts and still produce terrible writing (I do it all the time!). The "big bag of examples" is largely focused on poorly expressed ideas compared with the author's preferred minimalist style of expression.
This terseness has its own flaws: the biggest is that it lacks detail. Yet this isn't covered in the post, as though omitting needless words will magically help the developer convey all they need to about the complex systems they're building.
Please don't simplify complex real-world topics with absolutes. It never works.^3
^0 See this? I did this deliberately. "different" is not the same as "very different". You can distinguish them in your mind, and I will continue to defend the use of intensifiers--so important and prolific they are a specific, named concept in linguistics--for as long as I'm able to string words together.
^1 note how I used the passive voice there? You know exactly what I mean, and while it's not as short as the active voice is, it's an idiom, a common expression, and thus has similar cognitive load to the active voice.
^2 "For every complex problem there is an answer that is clear, simple, and wrong." - H L Mencken
^3 Deliberate irony is acknowledged and deliberate. (yes, that's a meme, a form of slang, and it, too, was deliberate)
The author prefers a writing style that is very^0 different from my own, and is presenting it as objectively better. This is another example--again about comments!--of the programmer personality type trying to simplify something hugely complex--here, the art of writing--into simple, easily-digestible rules. I wonder if it comes from the way programmers abstract the systems they work on to similarly simple rules with the goal of simple, easily-digestible rules, i.e. code. His dislike of conversational comments is fine, as an opinion, but there's something to be said^1 for that style. It puts the writer in the mind of talking to the rubber duck and I've found bugs in my code by writing comments like this. I have a conversation with myself while writing comments, and that internal monologue helps me understand the code better and find bugs. Furthermore, it helps the reader feel like they're having a conversation with the developer, as if they were pair programming.
The author furthermore seems to be an extreme proponent of the "omit needless words" school, specifically Stephen King's "adverbs are bad"^2 subschool. His likening technical writing to business writing belies a greater problem (actually, two). First, business writing isn't technical writing. The audience is different, the purpose is different, the rules are different. Second, Adams was really describing email writing, but called it business writing. The two are different; if you've ever suffered through an email written by an executive, you know what I'm talking about. If you substitute "email" for "business" in his post, all the rules are valid. Well, except the Strunk- and King-esque miserly approach to adjectives and adverbs.
Furthermore, the author's advice has some other mistakes, most critical being not knowing the audience. His anecdote regarding an Irish employer is not justification for avoiding the colorful uses of language that excite and allure; rather, it's more a reflection on his Irish coworkers not knowing their audience and not adjusting accordingly. Most of the "big bag of examples" are just unclear writing, the kind of writing someone creates when they don't fully understand what they're trying to say. There's a difference between unclear thoughts and bad writing. One can have perfectly clear thoughts and still produce terrible writing (I do it all the time!). The "big bag of examples" is largely focused on poorly expressed ideas compared with the author's preferred minimalist style of expression.
This terseness has its own flaws: the biggest is that it lacks detail. Yet this isn't covered in the post, as though omitting needless words will magically help the developer convey all they need to about the complex systems they're building.
Please don't simplify complex real-world topics with absolutes. It never works.^3
^0 See this? I did this deliberately. "different" is not the same as "very different". You can distinguish them in your mind, and I will continue to defend the use of intensifiers--so important and prolific they are a specific, named concept in linguistics--for as long as I'm able to string words together.
^1 note how I used the passive voice there? You know exactly what I mean, and while it's not as short as the active voice is, it's an idiom, a common expression, and thus has similar cognitive load to the active voice.
^2 "For every complex problem there is an answer that is clear, simple, and wrong." - H L Mencken
^3 Deliberate irony is acknowledged and deliberate. (yes, that's a meme, a form of slang, and it, too, was deliberate)