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. After a stint in teaching, I transitioned into marketing copywriting, and then turned to technical writing (mainly for financial reasons).
Despite my initial resistance to the idea of technical writing (I thought it would boring), 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 got to play with tools and handle all aspects of content production from designing web styles to configuring publishing workflows.
I worked as a traditional technical writer for a number of years, mostly documenting applications with user interfaces. One day, my organization decided to lay off the tech writing team.
After that, and based on my proclivity for tinkering with tools, 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 the ability to learn something new, across a lot of different domains and products, even if it’s challenging at first. And then to articulate the 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.
You’re in the right place. By the time you finish this course, you’ll have a solid understanding of how to document APIs. You’ll be familiar with the right tools, approaches, and other techniques you need to be successful with developer documentation projects. If you have feedback during any part of the course, feel free to drop me a line or comment on one of the pages.
San Francisco Bay area, California, USA
4/92 pages complete. Only 88 more pages to go...
If you would like to contribute back to say thank you for the API documentation course, click the Donate button below. Alternatively, to contribute content, such as a tutorial or a new section, contact me with your ideas. You can also submit a pull request in the GitHub repo to make your contribution. Even if you want to just fix a typo or add a sentence here and there, it's always welcome.
Get new posts delivered straight to your inbox.
© 2017, Tom Johnson