For some reason, technical aptitude and good interpersonal skills are rarely present in the same individual. There are many brilliant technology professionals with a tomes of knowledge to contribute to the rest of us but--for whatever reasons--they often don't. This was my original motivation for giving a writer's perspective in writing tech articles in two previous articles.

I'd like to continue by focusing this time on how our words can inadvertently say things to our readers that are confusing, irritating, or just plain untrue. Just a few poorly chosen words can cause a reader to hold a grudge against an author or an entire website for a long time. Even worse, the negative comments (on not only your site but the reader's) that may come as a result will discourage other readers from visiting while also discouraging you, the writer.

Avoiding absolutes (but not always)

Special care must be taken any time a writer wants to use words like "always" and "never." When you are writing for a technical audience, there is a fair chance that a large portion of your readers will know more about the subject than you. While they may not be reading your work with the expectation of learning something new, making a definitive statement that isn't true grates at the nerves of an expert like nails to the proverbial chalkboard.

What a lot of writers start doing in an effort to avoid this is completely quit making absolute statements about anything. This will keep you from offending readers, but it won't win you any new ones. It's analogous to the way an aspiring politician will make a lot of substantive statements while an incumbent will ramble at least as long but without saying anything of meaning.

There are ways to make statements that aren't absolute without going completely squishy. In other words, a point can be made in a way that is strong but doesn't force the reader to completely agree with the conclusion. For example, consider the following statement:

All passwords should be at least eight characters in length and should contain letters, numbers, and other symbols.

Now let's suppose this statement is true around 90% of the time. Even if that's the case, there are a few scenarios where it is not. So one way to make that statement more true is to make it wimpy.

You might want to make your passwords long and maybe use many different characters.

Sure, it's more true now but it's about as firm as Jello. A stronger way to word the same idea is:

A good administrator has to consider the use of long passwords containing characters from a large character set.

The third statement expresses the same basic point as the first two but makes it more universal while still being strong. It doesn't assume password lengths, what character sets are involves, or what conclusion the reader should come to but it doesn't wimp out, either.

Definitive statements are kind of like eye contact. Too much of it will make the reader uncomfortable; none at all will make the reader think the writer is uncomfortable. Just be sure to use them with caution and only when they are totally true.

Verifying our own logic

As a writer, few things are as embarrassing as making a reasoned point but finding out your logic was flawed. There is no quicker way to negate an entire article (or more) than to make a logical (or illogical) mistake.

Many times, we assume something is totally true without testing it before putting it to paper. But we are, of course, biased because the reasoning will almost certainly make sense to the brain it sprung from. This is why it's a good idea to double check our thinking.

There is a nice logical trick that can be used to test the truth of something that most tech-heads will enjoy. The validity of any statement can't be determined by the validity of its inverse or converse. However, the validity of a statement and it's contrapositive are always identical. If you can construct a contrapositive statement that you know is true, you can be confident that the original statement is true as well.

I won't go into the details of why this is true or how to come up with a contrapositive statement, but I will give you a couple examples.

All drives have some moving parts. (false)
No drives have only stationary parts. (also false)

No piece of software is completely secure. (true)
All pieces of software are partially insecure. (also true)

In both examples, the initial statement is obviously true. But the contrapositive is less obvious and requires some thought, making it a useful verification.

Countering conventional wisdom

There's nothing wrong with going against the grain. If it wasn't for divergent thinkers, we wouldn't have technological advances in the first place. But if you are going to make a statement that defies conventional wisdom, you need to do a little extra leg work.

The easiest way to attack the status quo is with evidence. With technology, this is the most natural path to take. Be sure to quote, identify, or link to evidence pointing to your conclusions if at all possible. You interpret the evidence, explain why, and that's pretty much all anyone can do.

The more difficult way to attack the status quo is to make a moral or ethical argument. This is no substitute for evidence, but there are times when you won't (or can't possibly) have them. Just don't expect this method to defeat large amounts of evidence that contradict it; even if it should win, it's about as realistic as "paper covers rock."

Identifying your audience early

The nature of Web publishing is such that if you want to attract the most possible readers, you will usually show blurbs rather than full articles on the most important pages or in your syndication feeds. When you have at most a paragraph to grab the reader, it's crucial that you grab all the readers you should grab for a particular article. One simple and efficient way to do this is to identify your audience directly.

Ideally, a blurb, teaser, or introductory paragraph will get the attention of most readers by sounding interesting or being well-written. But let's be honest here; most of this stuff is never going to be that exciting to most of your readers. When a paragraph isn't going to be eye-grabbing enough for the average reader, you may want to spell out exactly who needs to read your article.

Compare these two examples.

Penetration testing begins with three basic skills that you'll need to know.

Penetration testing begins with three basic skills that any good network administrator needs to know.

Both sentences convey the same basic message. The first one leaves the audience open, not clearly stating whether the readers should be moms, teachers, or dog catchers. For the potential reader who doesn't even know what penetration testing is, you've done nothing to explain whether it is something he or she really needs to know about.

However, the second sentence makes it plain to see: if you are a network administrator (or want to be one someday), you need to read this! If a network administrator reads that blurb and doesn't know what penetration testing is, then he or she will most certainly be urged to find out. Also notice how I threw the word "good" in there. After all, everyone wants to be a good whatever they are, so this adds just a slight tug to the intended readers.

Preemptively defusing your critics

A good chess player is always thinking about his next move. A better chess player is busier thinking about his opponent's next move. But a great chess player has a firm handle on both.

As you look over your articles (or perhaps as you write it or even as you plan it), try to anticipate where your critics will try to attack you. Even when it comes to articles that aren't really opinion pieces or editorials, tech readers can be viciously cutthroat. Since more people will read your article than will ever read your responses to critics, it's essential that you tie up as many loose ends as possible within your published text.

As soon as you make a point that you know will be disputed, try to come up with the most powerful argument against what you are saying. Then, within your own text, respond to it. For example:

Windows, in it's current form, will never be capable of greater security from viruses and other malware than Linux. While Windows advocates will argue that this is a function of the large market share that Microsoft's software holds, there are fundamental, architectural issues that are making Windows more vulnerable.

Not only does this defuse the most likely criticism you would have received, but it reinforces the original statement all the more. It's like the difference between shooting a layup that might miss and stealing the ball from the other team, driving to the other end of the court, and dunking the ball without even getting touched.

Although this is completely off-topic, the best example I've ever seen of this technique in action is in the movie 8 Mile. In the last rap battle, Eminem's character goes first and says everything his opponent is going to say about him, disputes or makes light of each point, and then verbally assaults his opponent directly. When it's his opponent's turn, all of his thunder has been stolen and he completely chokes.

Even if a reader doesn't agree with you, preemptively defusing an attack demonstrates the way you are thinking and how you got there. Both in writing and in anything else, this goes a long way towards earning the respect of those who would otherwise have none for someone trying to make the same point you are trying to make.

Responses and reflection

Feedback on the Web is more instantaneous than in perhaps any other medium. While that certainly has its merits, it can be a tough pill to swallow given the public nature of most of the comments you'll receive.

Try to look at every comment you receive as a gift. I say this knowing quite well that most of them are gifts you'd rather exchange for something nicer, but there is a little good in each of them (one way or another).

Every single time someone writes a response to something you wrote, whether publicly or privately, it's because you said something that they cared enough about to go to the trouble of responding. It may not be positive, but at the very least it provides you with a learning opportunity. Maybe you missed something. Maybe you managed to hit a nerve that needed hit. In any case, any response to your writing is better than none at all.

Be cautious when responding back to criticism. It's usually better to be bold in your original writing and let it stand on its own legs and then to retreat a bit when it comes to defending it. After all, if there is that much doubt left after reading the article, you didn't do a very good job (or at least a complete one). But if you do choose to respond, don't do it too hastily. Many times, the most mundane comment to an article is taken far too personally by the author.

Instead, try to focus on reflecting on the responses you get. If the responder has a valid point, consider it. If he or she doesn't and is merely ranting, ignore it. As one of my favorite sayings goes, "never argue with an idiot because most people won't be able to tell the difference."

Overall, be proud of your work, even when it's not your best. It's much easier to break something down than to build it.

It takes a lot more guts, too.

Conclusion

The whole concept of a talent for writing is far overblown. In regards to writing tech articles, that fact is no less true. A "talented" writer can venture on and on over countless pages, all the while painting a vivid but utterly useless picture with minimal effort. But writing talent or not, the most important factor and the most difficult challenge is finding something worth saying.