Technical Writing
Technical writing is sometimes defined as simplifying the complex(techwhirl.com), the same goal that I am trying to achieve in my code. There is a saying that explaining helps you better understand what you are doing, and in this sense writing documentation often helps me better understand the code.
If the code has any value people will read and modify it. Any documentation that clarify the code will be helpful, even when reading your own code many years later.
And the same could be said about user guides, which helps the users of a tool or a library and don't force them to read the code in order to use it. One of the examples would be a J2EE project where I was responsible for the project migration to Maven. Part of my job was setting up a project structure, including the project build and deployment; and also setting up an internal Maven repository. Writing the user guides had an extra benefit: members of the team were able to use Maven without asking me a lot of Maven related questions.
Most of my technical writing was part of the internal documentation and isn't in the public domain. What is on this site is in the public domain, as well as my open source contributions that include documentation.
Even as technical writing was a relatively small part of my job and not a full-time occupation, I took several academic writing courses at Columbia University, and passed level 10 exam; my teachers liked my writing and encouraged me. I really enjoy the creative process of writing.
Below are some of the tools that I am using:
reStructuredText, Markdown, Sphinx, wiki.