Communications from DMN

by: Milan Davidovic

Recently, a couple of things crossed my path:

• A blog article by Tom Johnson about projects for entry-level tech writers.
• A presentation by Travis Derouin about wikiHow.

This got me thinking about whether contributing to wikis could help novice tech writers get their first gig:

• They can’t really put their contributions into a portfolio (can they?).
• Outside of whatever skills they need to deal with the wiki itself, they probably won’t develop any tool skills (unless it’s a wiki about tools).

Hmmm… One thing that wikis do look useful for, though, is giving novice writers a chance to develop their ability to collaborate effectively on writing projects with a wide range of people, even when they can’t meet those people face-to-face. Having had to do this on my most recent job, I can personally attest to the usefulness of such an ability.

Collaboration: not as straighforward as it seems

But isn’t the ability to collaborate something that most people develop as they grow up? I agree, but also observe that not all people work together equally well, and that our jobs don’t necessarily let us work with whoever we like. Therefore, we need to be able to collaborate even when it’s challenging to do so.

This skill, I believe, is best developed while under fire, and such fire can be found on many wiki articles. For example, see the Wikipedia article for bicycle helmets, and then look at the discussion page behind it. Interesting, yes?

The bicycle helmet article brings something else to mind: awareness of and sensitivity to history. This article goes back to August 2004, and clearly much has been discussed. Should contributors familiarize themselves with the whole history before asking a question or making a change? What are the chances that the question or change has come up before? Should it be raised again? Without knowing the history, how would one know?

Taking history into consideration

Similarly, existing enterprises have histories, but unlike wiki articles these histories can’t be directly read. However, even knowing that the history is there and that it provides a context for the present should make it a bit easier for the new employee to fit in and start contributing.

And just as wiki articles have histories, so too do they have futures. New information may become available about a topic and an article about that topic will require change to remain current. This provides the writer with a chance to help shape the change, much as they will when, say, they work on documentation throughout the lifecycle of a product.

A roadmap for the novice

With that in mind, here’s what the novice tech writer could do to get started on this idea:

• Find a wiki and create an account (I’m starting with wikiHow to research this idea further: http://www.wikihow.com/User:Alt.milan).
• Find resources on collaboration, teamwork, and collaborative writing to see what’s been said by people who study these subjects; their insights may be helpful.
• Pick some articles to contribute to, and read the discussion pages; see who has contributed, what they’ve had to say, and perhaps look at what else they’ve contributed to other articles.
• Start asking questions, writing, and editing – and see how it goes.

Although contributing to a wiki may not offer the novice tech writer much in the way of portfolio material or opportunities to build tool skills, it does let the writer develop skills and gain experience that they can transfer to the workplace.

About the author: Milan Davidovic describes what he does/who he is as ”technical writing; sound/noise composition; middle-aged guy.” He also blogs, tweets, and takes some interesting photos.