In case you’d like to know a little bit about me, I’m currently based in the San Francisco Bay area of California. I work at Amazon Lab126, which builds the devices for many of Amazon’s products (such as the Kindle, Echo, Fire TV, and more).
Like most technical writers, I stumbled into technical writing after working in other fields. I first earned a BA in English and an MFA in nonfiction creative writing, and then started out my career as a writing teacher. Realizing that teaching wasn’t my calling, I transitioned into marketing copywriting, and then turned to technical writing to survive financially.
Despite my initial resistance to the idea of technical writing, I found that I actually liked technical writing — a lot more than copywriting. Technical writing combined my love for writing with my fascination for technology.
I worked as a traditional technical writer for a number of years, mostly documenting applications with user interfaces until one day, my organization laid off the tech writing team.
After that, I decided to steer my career into a tech writing market that was more in demand: developer documentation, particularly API documentation. I also moved into Silicon Valley to be at the center of tech.
I started documenting my first API at a gamification startup, and then transitioned to another semi-startup to continue with more API documentation. I was no longer working with applications that had user interfaces, and the audiences for my docs were primarily developers. Developer doc was a new landscape to navigate, with different tools, expectations, goals, and deliverables.
Although I don’t have a programming background, I’ve always been somewhat technical. As a teacher I created my own interactive website. As a traditional technical writer, I often set up or hacked the authoring tools and outputs. I like learning and experimenting with new technologies. The developer documentation landscape suits me well, and I enjoy it.
Still, I’m by no means a programmer. As a technical writer, deep technical knowledge is helpful but not always essential, as it tends to be too specialized and comes at the expense of other skills and knowledge. What matters most is your ability to learn something new, across a lot of different domains and products, even if it’s challenging at first. And then to articulate your knowledge in easy-to-consume ways.
That’s probably why you’re taking this course — because you want to develop your skills and knowledge to increase your capabilities at work, enhance your skillset’s marketability, and maybe figure out how to document the new API your company is rolling out.
Also, I love to write. I’m a content creator by nature, and I love nothing more than filling a blank page with new thoughts and ideas. If you have a question for me, or just want to drop me a line, send your feedback to the e-mail address below.
San Francisco Bay area, California, USA
Get new posts delivered straight to your inbox.
© 2017, Tom Johnson