Technical Writing Career Considerations 12/28/2009
I am an active participant in web forums discussing the field of Technical Writing and I enjoy offering advice based on my own experiences and observations. A lot of folks have been impacted with the economic challenges in the past year. In many technical writing forums I'm seeing comments from individuals who are having a hard time getting work as technical writers, especially senior level tech writers. I've made the comments there and others found them so useful, I've decided to compile them and post them here. Location In the current economy, there are less jobs in rural locations emphasizing the need for entrepreneurship for folks living in those environments. For those of us who are living in urban locations, there are usually a few companies doing most of the hiring, and most of that hiring is contract work. What I've seen in job postings and job discussions is that most of these employers want someone who can hit the ground running, not only in terms of writing ability, but in the ability to absorb and comprehend the technology quickly. Diversity in industry is vital to a successful career because it gives you options. If you live in an area that is dependent on one industry (e.g. automotive), and that whole industry is impacted, you might be stuck. Either consider applying your expertise to other fields or consider relocating to an area with more job opportunities. Expertise Having a field of expertise is vital to being a successful technical writer. Consider taking continuing education courses to keep current in your chosen area. Some areas to consider: computer software, computer hardware, computer networking, computer security (this includes Sarbanes-Oxley and other "policy" areas, it doesn't have to be "technical"), biotechnology, "green" technology, health care or health insurance related areas, and financial areas (e.g. economics). I've seen many comments from older technical writers who are particularly challenged in the current economy. The key issue with older technical writers is the concern that they aren't as current and adaptable in the face of new technologies. Traditionally older employees are seen as being more stuck in their ways. Show an interest and skill in recent technological developments; take continuing education and other training courses to keep current. Experience Volunteer your skills for community driven projects to showcase your expertise and your talent. Even if you're steadily employed, these types of projects help you stay current and keep you out of a rut. Adaptability I believe the key challenge to the current economy is adaptation. The US Economy has been evolving steadily over the past 10 years as more manufacturing and service jobs are sent overseas. With less manufacturing work, there is less technical writing work in manufacturing industries. Technical writers with a lot of experience in those areas may have opportunities in the future "green" economy with the Smart Grid and Green manufacturing jobs, but we won't start seeing that boom until 2014. In the current economy, most work for technical writers is on a contract, project-specific basis. The work environment where you work for one company for many years and retire is gone. If you don't have any other source of income (e.g. spouse) you really have to live within your means and count on periods of unemployment. Start your own business so you can take on freelance work in between big gigs. Eventually, maybe when the economy stabilizes or after building a reputation, you'll find a company that needs a full time technical writer on staff. In the meantime, adjust your lifestyle appropriately. Technical Writing is not just about WRITING. It's about Technology as well. I recommend taking continuing education courses to get up to speed on some new technology, maybe even seek out a Continuing Education certification in some area, just to show you are still current and active with regards to your technological skill set. Also consider contributing to open source software projects to avoid resume gaps!! The key to being a successful technical writer is to be more than just a writer. You must possess knowledge of the topics you write about. You must be both Technical and a Writer. Current Open Source Projects 11/26/2009
I am currently working on a few different Open Source projects. Ubuntu Packaging Guide - Document Structure (Information Architecture) I am working with the team to evaluate the best way to reorganize the packaging guide content to be more useful for end users than it is currently. The packaging guide is currently available as a single large document called "The Complete Packaging Guide". This complete guide is in wiki format and is made up of includes of many sections. I have proposed a new structure - an introduction section, an advanced section and individual wiki pages for even more advanced details of tools discussed in the advanced section. - Advanced Section Edit I have started reviewing the Advanced sections of the existing Ubuntu Packaging Guide. I hope to reorganize the sections to be more useful, edit the language to be more user friendly, and, finally, edit the technical content to ensure accuracy (meaning test and verify!). Spaz API Documentation Spaz is a Twitter client built on Adobe AIR that requires API documentation so other developers can get involved with extending and contributing to it. Mozilla XUL Documentation - Introduction to XUL The Introduction to XUL article on the MDC wiki is out of date and needs to be edited for content and technical accuracy. Furthermore, the writing style needs a lot of cleaning up. Interesting Read on Documenting Code 11/21/2009
I found this entertaining article for developers discussing the challenges of documenting code. Reading it really takes me back to a variety of situations I've been in! How many times have I worked with developers, only to be told how "self-documenting" their code is... only, of course, to find out that they just mean comments. And of course, they didn't comment everything. "Oh that's not important, anyone can figure that out by looking at it." Or my favorite response when I stumble up on something particularly interesting, "Gee I don't know why I wrote that." Commenting code and documenting code, while related, are two different things. Comments make documenting easy, but comments can never substitute for good documentation :) Providing good documentation in your code makes the results of automated tools that generate API documentation skeletons more useful. While those tools make API documentation easier, you can't solely rely on them as your only source. Granted it's better than nothing, but if you really want people to learn and develop with your API, there is no better time investment than comprehensive API documentation, including code samples and tutorials. Here is a list of resources I have found to be particularly helpful:
New Website 11/20/2009
I have moved from building my own Flex-based website to Weebly. I have had a lot of fun tinkering with Flex, but Weebly is a lot easier to maintain. The interface is simple to use and I can make updates to my site quickly. Additionally, I can easily host multimedia content (like an online portfolio) by dragging and dropping components. All around, it's less time spent on reinventing the wheel. I'll save the heavy code tinkering for my day job ;) I did a session on IRC for the Ubuntu Documentation Project team regarding the writing process. When it comes to documentation, the writing is the easy part. The most challenging part of documenting anything is determining what and how to document! Here is an outline of what I discussed:
You can read my full presentation here. |
RSS Feed