I’ve been writing a lot lately, a trend that makes me very happy. I’m writing a fairly large variety of materials, too: poetry, fiction, even some nonfiction.
However, most of it is still under wraps. I have one fiction piece that took a while to write and edit (to be published soon, along with author’s notes), and I have a lot of nascent songs to work through, for which music hasn’t been fully composed; I also have works of poetry (that are, well, songs without music). The nonfiction stuff is probably going to remain private forever (as I’m not satisfied with the research I’ve put into them, such that I’m willing to show others what I’ve done.)
It’s been good, though. It’s been cathartic in some ways, negative in others (I write best when I’m trying to work through stuff, and it shows in what I write), but I’m glad for the creative spark.
I hate interruptions. The funny thing is, though, that I interrupt people, too, so it’s a behavior that I despise while needing to work on it myself.
An interruption is a break in flow: while something is being done or said, hey, a squirrel!
It’s usually done by one person to another, though. (I interrupt myself all the time, and it’s just part of the natural flow of being.)
There are lots of reasons people interrupt each other – some are benign, some are not. They’re all annoying. My thought is: we can all do better, both as the ones being interrupted (sometimes there’s a good reason people interrupt me!) and as the ones doing the interrupting.
Most of the time, people interrupt others because they just don’t care about the person they’re interrupting. The target of the interruption might be working, or playing, or trying to explain something, or just thinking… and the interrupter seems to think, “What you are doing is not relevant to me, but I expect what I want to say or do to be relevant to you.”
If you’re this person, stop. Really. I’m begging you (and myself) to avoid interrupting someone, especially out of narcissism. What’s sad is that most of us interrupt in exactly this mindset, even if it’s not intentional or explicitly spelled out this bluntly in the narrative we tell ourselves.
Sometimes, though, an interruption is more well-meaning, even though it’s nearly impossible to be interrupted without resentment as a result. (Alliterative assault was accidental. Apologies.)
Sometimes the person being interrupted is taking a long time to say something, or do something, and the other person is trying to short-circuit the action for a specific effect.
For example, I record music, just for myself… and I usually intend to take fifteen or thirty minutes at a time to do it. But when I’m recording, time tends to lose meaning and definition, so I’m thinking “I’m ten minutes in,” and it’s actually been an hour and a half.
Then I get “interrupted” – mid-flow, often mid-recording – to find that dinner’s ready, or that I’m late for something. (Dinner, perhaps.)
The interruption is still annoying, honestly, but it’s deserved. My annoyance is misplaced. (And I know it, too; I tend to subvert that annoyance in moments.)
I could avoid the interruption by sticking to my own schedule, or by setting expectations. In conversation, I try to figure out what it is I have to say, and then I say it, directly, without a lot of explanation. The explanation, if necessary, can follow the point, just like an essay – “Here’s what I have to say, full stop. If you want more, I can give it to you.”
That way, even if I am interrupted, my point at least has a chance to be heard. (I usually don’t bother with the explanations anyway.)
It’s less fun to speak or write this way, I suppose; sometimes I like to hear myself talk, too, and sometimes I even like others to hear me, too, because it gives me the warm fuzzies to think that I and my opinion are valued by other people.
With that said: it’s also good practice. I write for public consumption, after all, and people scan rather than read, especially on the Internet – taking a long time to say something means that the “something” doesn’t get read.
On the Internet, you are “one and done” – if your first sentence isn’t enough, the second and third (and seventeenth) won’t matter.
None of this means that interruptions are pleasant, or that they say good things about the one doing the interrupting (or that the one being interrupted deserves it.)
Interruptions are, and will always be, impolite, even if there are circumstances under which they’re somewhat justified. Be aware of them.
(This public service announcement brought to you by Aveeno, which is the first thing I looked at after writing it – hey, a squirrel! Have you ever noticed how bright the color green can be when you measure it by…)
Weasel words are great. And yes, I know, I left out weasel words in making that statement.
Weasel words are words like “some” and “may.” Most clickbait authors – i.e., people on Facebook – are allergic to them, so you get fine headlines like “Conservatives hate the gays!” instead of the less-click-baitish and far-more-accurate “Some conservatives hate gays.”
Yet weasel words – sometimes seen as poor writing – aren’t poor writing at all. (See?) Weasel words allow you to describe things without being absolute about the description. They also allow you to temper a statement – which might even lead to more temperate statements, so instead of “Conservatives hate gays!” you might write “Some conservatives hate gays!” and then the ironically more-inclusive “Some people hate gays.”
Weasel words also create an allowance for error. Saying “Conservatives hate gays” means you’re liable to be countered by some conservative pointing out that he or she demonstratively does not hate homosexuals, which means your entire weasel-free claim is invalidated, since it makes no allowance for exceptions.
“Ah, but exceptions are implied,” you might be saying – but no, they’re not. Not on the internet. If you don’t provide room for the exceptions, the internet – which amplifies everything you write, since there’s nothing to temper a statement like body language or tone – makes it seem that there are no exceptions.
Nearly everyone is doggedly literal on the Internet. Acting like your audience is made entirely of people who are not doggedly literal is ill-advised.
So: Befriend the weasel words, folks. Really. They’ll help create actual dialogue, by allowing nuance.
(Reposted here from a Facebook post of mine, of all things, to preserve it.)
As editor of TheServerSide.com in the past, I had a lot of opportunity to see what worked in online writing and what didn’t. Since it was a core part of my job to be efficient online, I also did a lot of research into various techniques, and while I certainly can’t claim to be an SEO expert of any kind, I can describe some things that can help online writing be more efficient.
This was originally written for TheServerSide.com, and was linked on the post submissions page; since then, they’ve mangled the formatting of old posts so it’s nearly unreadable, although the .Net version of the article is still formatted properly.
Tips on Writing
Writing articles for the web is a lot like writing anything else, with the main differences being that you have fewer limitations, and thus even more chances to lose your audience.
When you write online, it’s being written for posterity. Thus, write it as well as you can. You want to be very clear, and you want to make sure you’re not assuming things on the part of your audience.
Don’t say things in passing. Be specific. Your audience doesn’t have the time or interest to try to figure out what you meant. Trying to be fancy will only make you less effective as a writer. There’s no issue with having a personality or a style in your writing, but if the dominant feature in your writing is your style (and not the content itself) then you’re going to lose your audience.
Losing your audience is a bad thing.
The first sentence in your article is by far the most important. It needs to communicate why a given article should be read. If that one sentence is not effective, your article will start off with a smaller audience, because you will lose readers immediately.
The first sentence in each paragraph is also important. On the web, readers tend to scan more than read. If you put the topic sentence after the first sentence in the paragraph, chances are good that the readers will not reach it. They will have moved on to the next paragraph, or perhaps they will have stopped reading altogether.
It is all right if the subject of a paragraph cannot be completed in one sentence, but the topic sentence should be enough to communicate what the paragraph means. If the reader wants more explanation, the rest of the paragraph exists to provide it.
Short sentences are good. Long sentences are fun to write, and they are often quite natural for authors, but they are not efficient for web readers to scan.
Don’t use emphasis techniques like bold or italics any more than you absolutely need. If you feel that bold is necessary to make your point, then it’s likely that your sentence or paragraph is organized poorly. Highlights like bold or italics draw the eye long after the bold text is read, and the highlights actually lower comprehension.
Code samples are great, and usually required, but make them clear and complete. References to third party sources are all right, but the readers are best served by full code. Boilerplate code, like accessors and mutators, can be ignored with a comment, but it could be more effective if you used properties directly for simplicity … or, instead of including a long list of accessors and mutators, use Lombok. If you’re using Java, that is.
Remember that writing online is still writing. The writing process rarely lends itself to single drafts. It can happen, but it’s rare, and usually not effective.
For efficiency and good writing style, follow a set of simple tips:
Make an outline.
If the first sentence of a given paragraph isn’t enough to understand what the paragraph is about, rewrite the paragraph.
Make sure the article matches your premise! If the subject of the article is “Object Databases and Efficiency,” don’t spend half your text discussing the failures of relational databases. Talk about object databases and efficiency instead.
Make sure your spelling is correct.
If you use a word processor that provides grammar checking, you should allow it to suggest changes. Check your reading level, Flesch-Kincaid scores, and other data you can. The average reader wants to read at a sixth-grade level. If you consistently score much higher, your article will be hard to read. On the web, ‘hard to read’ usually means ‘unread.’ (This document, as originally published, received a Flesch-Kincaid grade level score of 7.8, for example. I haven’t checked the revised version, because I’m afraid to.)
Have people read your draft, and listen to every suggestion they offer. Don’t offer it only to experts; offer it to willing newbies, too. It’s all right to decide not to use suggestions, but your wider audience is going to think of many of the same things your test audience tells you. Constructive criticism is good, especially if it’s received before the article is published.
Avoid parentheticals like the plague (the plague is bad, no matter which plague it is.) If you have to use parentheticals, go ahead, but try hard to not overuse them. (They’re hard to read, and break the flow of text. Plus, they’re annoying.)
What I Do When I Write
I actually mind-map most of the things I write, with Freeplane, an open-source (and free) mind-mapping tool. I then draft a rough map for the article.
My central node is, naturally, the subject. (This article would have “tips on writing.”) Then I create child nodes for the central points that I think I need to make – the things without which I’d decide the article wasn’t worth reading.
This becomes my structure. If I have a child node that isn’t something I have to have, then it’s extraneous to the document, or my subject thesis isn’t correct.
These first vertices are the most important part of writing an article, to me; the rest I can usually figure out as I go, if I have to, because my important points (the second-level nodes of the map) should be clear enough and relevant enough to use as a guide for everything.
I usually fill out another few levels for each of the second level nodes, too, though, because they also should have supporting thoughts associated with them. (Otherwise they’re not supported; they’d better stand on their own, then.)
Then, I draft the article itself. The space each supporting statement should get should be roughly analogous to the size of the corresponding node in the graph; if a node in the graph is very short, yet the text for that node is very long, then perhaps my graph isn’t very complete… or perhaps the section is getting too much emphasis, which is by far the more common case. (Or, alternatively, I’m showing code, which drastically affects the size of a block of text. No way around this, sadly, other than hiding the code or providing a link to an external page, neither of which is effective.)
If it’s stated simply in the mind map, there’s no reason it shouldn’t be stated simply in the final product. (Corollary: state things simply in the mind map.)
Then I reread the article, a lot. I find willing victims as often as I can, and make them read it; usually I get unuseful and generic responses like “it’s good,” which boosts my ego some but, realistically, those responses don’t do much for me or for the article. I’m looking for constructive criticism, questions that come from the reader, things like that.
Remember: it’s a draft. As long as you keep that in mind, barbs thrown at you from readers won’t sting much. If they do, well, sorry – listen to your readers. Maybe you won’t factor in what they say (remember the list of tips earlier in this article?) but there’s usually a reason they think what they think.
Sometimes a point made by a reader emphasizes what you wanted to have happen – maybe you wanted the reader to wonder something, you know? If the comments are in line with what you desired to happen, well, that’s a win. If they’re not, well, that’s why you draft and that’s why you rewrite.
The concept is that a mapped article, if it’s able to be graphed properly, will naturally have a better, more cohesive structure for your readers, reducing signal-to-noise and guiding the author’s efforts. A draft process, detached from your ego, is designed to make sure that you aren’t using your writing as pure ego, which makes it more broadly appealing and useful.
Conclusion
I’ve spent a long time learning how to write well online, with varying results. I, too, am ego-driven, after all. However, I love to read well-written stuff, and as an editor for online and dead tree material, I’ve learned what works and what doesn’t. Hopefully you will find these tips and processes useful; I’d love to hear about alternative processes, too, because there’s more than one way to dig a hole.
