Technical Writing

Technical writing is sometimes described as simplifying the complex(techwhirl.com), a goal I also strive for in my code. There’s a saying that explaining something helps you understand it better. And in my experience, writing documentation often deepens my understanding of the codebase.

If code has value, it will eventually be read and modified by others. Documentation that clarifies the code's purpose or structure is helpful, even years later when you or someone else revisits the project.

The same applies to user guides. A well-written guide allows users to work with a tool or library without needing to dig into the source code. For example, in a J2EE project, I was responsible for migrating the build system to Maven. I set up the project structure, including build and deployment processes, and configured an internal Maven repository. Writing user guides not only aided team migration to Maven but also reduced the number of Maven-related questions I had to answer.

Most of my technical writing has been internal and is not publicly available, but some of my work - including content on this site and documentation for open source contributions - is public.

Although technical writing has never been my full-time role, I enjoy the creative process of writing. After completing several academic writing courses at Columbia University, I passed the Level 10 exam.

The tools I use for technical writing include:

reStructuredText, Markdown, Sphinx, wiki.