And So March Begins

I’m teaching my Creating an Online Presence Class this weekend and also going through a madcap rush to update the accompanying book. The class and book are aimed at helping people tame the bewildering timesink of social media, website, pocasts, search engines, and other facets of online existence for writers. One of the things I try to teach how to use online time efficiently, because writing and editing time is precious and time spent doing other things is time you’re not writing or editing. So here’s some things about blogging.

Is A Blog Mandatory?

No. But it’s advisable. You do want readers to be able to find you online and, more importantly, to find your work. You do want a website (and a mailing list, but that’s another post), but your website can be a static presence, something you put up and don’t update very often. In fact, if you have very minimal time to invest or otherwise want to limit your online presence to the bare bones, don’t include a blog. Few things look sadder than a blog with a single entry from five years ago, usually about trying to make oneself blog.

Something You Can Always Blog About

One reason to blog on your website is that it means the website is being updated frequently, which makes the site more likely to turn up on search engine results. So here’s two ways you can generate a weekly post. The first depends on having a social media presence; the second does not.

1. Social Media version: If you’re posting links and observations on social media, you can collect the best of those into a post. They don’t have to be related to writing; you’re allowed to have other interests. Five to ten links with one or two sentence explanations as to why you picked them. There you go. Shazam, you have a post.
2. Non Social Media version: Every week, pick an interesting chunk (I suggest 300-700 words) from what you’ve worked on the past week and post it.

If you want to be thorough with that second approach, you can place it in context for readers. Here’s some possible questions to answer.

• What is the project, the genre, the inspiration?
• Are those the final character/setting names or placeholders?
• What’s the title and how does it relate to the story?
• What’s the setting based on? What are you trying to accomplish in this bit?
• What are you particularly fond of?
• What do you definitely plan to go back and fix in the revision?
• What aren’t you sure about?
• What do you intend to do with the piece when you finish?
• What would you compare the piece to, either in your own work or that of others?
• What do you want readers to get out of the piece?

Certainly there are ways to get the most bang for the effort out of these posts: include an image, have a good tagging system, make the most of keywords. But those are advanced techniques, and unnecessary to this basic effort.

If You Only Hate Writing about Writing

As I mentioned above, you do not have to blog about writing. In fact, the world is full of posts about avoiding adverbs, and you probably do not have anything to say on the subject that has not already been said. So blog about something else.

Blog about your adventures in learning how to pickle vegetables or speak Mandarin. Document some longterm project like your garden remodel or the bookstore your partner is opening. In a pinch, you can always fall back on writing about the books you’re reading. The most interesting and effective blogs out there don’t just show you the writer’s writing, but something about them as a person.

Always Be Closing is NOT a Good Axiom for Writers

While all writers need to think about how to help readers find their work, if they are too pushy about forcing them to it, those readers will balk and go no further. Don’t make your website all about sell sell sell. Don’t make it your social media focus nor what you blog about over and over again. You will be wasting your time and driving away fans.

That’s why showing readers scraps from your writing is effective. You are giving them something that is (hopefully) genuinely interesting here and now. If they like it, they may look for it later on when it comes out. Let your writing and its quality do the work of selling for you and don’t worry about the set of steak knives. Just write.

#sfwapro

This article originally appeared in the now-defunct online magazine Imaginary Realities. It talks about MUD administration, and draws on my experience working with Armageddon MUD, the world of Zalanthas. For those who don’t know what a MUD is, it’s a text-based roleplaying game. Here’s the wikipedia article on MUDs.

One of the sad truths of the mud world is that there are never enough coders. Builders aplenty, brimming with fresh idealism and plans for entire zones, appear (and sometimes disappear) at the drop of a hat. But coders are the unicorns of the mudding world, seldom glimpsed and ardently pursued. We are lucky enough to have three dedicated coders on Armageddon MUD: Morgenes, Tenebrius and Tiernan, as well as a few other staff members willing and able to wade through the bugs file and tinker with things upon occasion. How, then, does an administrator keep these rare beasts happy? The following four steps may help.

1) Communicate: When asking for new code, try to let the coders know exactly what is desired. For example, instead of ‘Let’s make archery more complicated,” a staff member might propose “Let’s put a range on archery, so the farther away the target is, the harder it is to shoot it.” A full description of the the idea, perhaps including examples, such as fake logs showing what the idea will look like when being used, helps make sure the originator of the idea and the coder are on the same track as far as things like syntax and usage are concerned.

The same holds true for bugs. Describing how it’s supposed to work as well to how it’s working right now helps clarify ideas. Coders want to know if the bug is REALLY a bug, or something being reported because it doesn’t work as the reporter feels it should.

With bugs, give the coders as much information as possible, including how to reproduce the bug. Examples by way of logs are great, and if they include some form of error message (or message that they’re getting that shows it’s an error), it often allows the coder to track down what section of the code needs to be worked on.

Make sure people aren’t bumping into each other. On Armageddon, we’ve got a coder’s board, where people post changes as they make them. This alerts fellow team members to what they’re doing and is also helpful if unexpected bugs crop up, enabling people to track exactly what got changed and when. Two people should not be working on the same idea at once unless they know it, and can divvy up the work accordingly.

2) Have a purpose: Will it get used? Is it something players are asking for? This one is a matter of ego, but we’re all human and we all do have egos. Seeing their work getting used, regularly and as envisioned, is a reward beyond any thanks or congratulations other staff members can give a coder. Track player requests, through entries in the bugs/ideas/typos files as well as emails to the account and posts on the general discussion board in order to convince a coder that the players want, and will use, something.

Generally, with new ideas figure out how they are moving towards some goal. A piece of code like a new skill is going to sound more interesting if it fits into some overall purpose, such as a master plan of non-combat related skills for the economy than it would if it is just a random idea. You are also going to end up getting more out of the idea if it is part of a greater whole.

Make it innovative. Some coders like to be trail breakers, to feel that they’re not just playing catch-up with another mud, but are creating ideas and concepts new to the mud community. Some ideas get requested to ‘balance’ things out between groups: guilds, or races, or mount speed. When a coder starts to feel like the code they’re doing that day only works to nullify a change made last week, then they’re going to start wondering what they will be asked to implement tomorrow.

3) Share the work: Do as much of the grunt work as you can for the coders, including helping thoroughly test, providing help files and documentation, and fleshing things out. In testing, give coders information about what is not working and how to recreate the result. Be precise about what needs to be changed: not ‘the plague of locusts spell needs to do more damage’, but ‘it needs to do about twice the damage it is now.’ When something requires a new help file or modification of an existing help file, do not expect the coder to do it, but supply it yourself. If it is something that requires building, provide the items. Teamwork of this kind, when it is working well, is terrific, and will often produce amazingly cool results.

4) Appreciate: Good coders can never be praised sufficiently. We try to make sure that players know who is responsible for new and interesting changes, by posting information about them in the news as well as in our weekly update, which is a mailing our players can subscribe to, which provides information about changes, staff and world news, upcoming recommended playing times, etc. When players write in with compliments or feedback on a code change, make sure that the note gets passed along to the person , as well as that the coder knows how cool or slick you think the ideas they have implemented are as well.

There is a tendency sometimes to regard coders as resources that spit out code at request. But the fact of the matter is that treating coders in that way will frustrate both sides, leading coders to become discouraged and unmotivated to implement new ideas and builders to feel that their coding needs are not being met. These four points may help avoid such frustration.

This article originally appeared in the April 2001 issue of Imaginary Realities.
© 2002 Cat Rambo. All rights reserved.