Tips for Effective Documentation

notebooks-072504-1Writing technical documentation is required task for many developers.  Once you start producing documentation you quickly learn good documentation is more than just screen shots. You will be required to write and express complex concepts. Documentation can be very challenging. Especially if you are not comfortable writing for non-technical users. It is a skill like any other. It can only developed through practice and experience. Here are a list of tips and ideas which I have used for writing effective documentation.

Practice Writing

Above all else, the more you practice writing the better you will be. When I left college my writing was not up to par. It did not improve until I started practicing. My writing may not be perfect, but it has shown vast improvement, because I practiced writing.  Many ways exist for you to practicing writing documentation. Here are just a few that I used.

  • Start writing in a blog about technical material you interested in.
  • Document your own work. You can use a personal wiki. TiddlyWiki is one example.
  • Just sit down and write anything. Just write.

Read Other Documentation

Reading documentation is a way to broaden your knowledge of documentation.  The more you read the better writer you will become. Reading other documentation can help you learn a learn from other’s successes and mistakes. Here are some ideas for reading other documentation.

  • The O’Reilly Books great example of technical documentation for Programmers and Administrators.
  • Documentation of technical tasks for non-technical users.
  • Find similar documentation to the technical item you want to document.

Know Your Audience

Before you ever start writing, ask yourself who is my audience? This sets the stage for the tone of the document and how the information should be presented. Here are a set of questions to clarify who your audience is.

  • What technical skills do my users posses?
  • What terms will make your users comfortable or feel uneasy?
  • What reading level are your users?
  • Are they comfortable with technical writing?
  • Do they understand the non-technical aspects of the task?

Be Consistent

Keep your documentation consistent. Consistency reduces the barriers to following a complex idea. It increases readers comprehension of the document. Here are some tips on consistency.

  • Use consistent jargon ex: If you call a link by the term hyperlink, do not use the term link later.
  • If you are adding to a document try to follow the existing writing style.
  • Use a consistent writing style.
  • Use consistent and proper spelling.
  • Use the same font styles consistently.

Write Clearly

There are many ways we can clarify documentation. Technical language is sometimes a necessity, but that does not have to effect the clarity of our writing. Here are some tips for making your documentation slightly more clear.

  • Define jargon and acronyms when they are introduced.
  • Do not skip steps when documenting tasks.
  • Highlight problem areas, potential pitfalls, and common mistakes.
  • Provide concrete examples.
  • Use the simplest words that work.
  • Avoid complex and run on sentences.
  • Use paragraphs to isolate larger concepts.

Efficient For the Reader

The only thing worse than incomplete documentation, is inefficient documentation. Writing an efficient document goes hand and hand with clear documentation. Do not make your users search through loads of documentation. Make the important points stick out.

  • Good headlines and Sub-Headlines will allow your users to effectively scan content.
  • Good section grouping will allow users to find similar concepts quickly.
  • A search function for online documentation is extremely effective. I recommend using a Wiki.

Conclusion

These tips will not make you a better writer over night, but they can help you become more cognizant about what you are writing. Below are a list of tips and resources to help with writing documentation.

Dining Programmers

We as programmers dine upon a plethora of languages. Some of us choose to dine on rich and decadent languages such as Java, and .NET. Others choose the traditional elegance of languages such as C and Assembly. Some choose quick and light scripting languages such as PHP, Python, and Ruby.

The programming languages you dine on is based in the same principals as your culinary choices. These decisions are based in your culture. Many factors which contribute to your technical culture: where you learn, where you work, and where you play. Reading these cultural factors can help us understand why a person or an organization picks the languages they do.

Some of us choose us prefer a buffet of languages, and like to sample a little bit of every language. Some choose to stick with a couple core choices and savor every little piece of a language. On the other hand you have your diet specific programmers, such as you free software-gens, and the script-arians.

Sometimes our jobs require us to use a specific language, or the technology requires it. Utility is largest factor in choosing languages. Secondly what you learned and perfected you programming is a close second to choosing which language to use. Tertiary factors are general community factors, such as what are the current trends, what would you like to learn. All of these factors relate to how we choose food, what’s available to us to buy, what our families have eaten, and what we are recommended.

On a side note. The programming languages you choose to dine are signals to other programmers. Just as you culinary choices are signals to other people. These signs, and signals many times are more rooted in stereo type. So many programmers may learn a specific language to affect their appearance to others, just as some people make dining choices to impress other people.

Finally as I discussed earlier the biggest factor in choosing a programming language is the utility, and what we cut our teeth on. Just as many times primary food choices are based on utility, and then what we learned from our families. Understanding these factors can help us grow as programmer, and understand what programming languages we consume.

Des Moines Twitter Trends V.2

I just published version two of Des Moines twitter trends. The biggest change is the database was moved to MySql instead of SQLite3. Upgrading to MySql database allowed the data to be easily shared with a WordPress site.

The web view of the data has been upgraded to provide more information. The Des Moines Twitter Trends website now provides a clearer view of the data collected. It provides current trends for the past few hours, the past day, and the past week. All of the terms are now links to Twitter Searches.

I added some new information, such as recent links, and current view of the latest Twitter user’s avatars in a grid.

I also created my own theme, and display instead of using a third party Wordpress Theme.

P.S.
Here was the write up for the first version: http://www.dotcodedump.com/2009/07/finding-local-twitter-trends.html

Profile Picture

About Ian Lintner


I am a software developer, mostly web,  in Des Moines, Iowa. I take a very opinionated stand concerning development, you will never regret a simple design or architecture. My education was at Drake University in Biology and Computer Science. Offline I am recently married to my wife Heather. I try my hand at many hobbies currently I am gardening till the snow comes in.



My Current Projects


Des Moines Twitter Trends