About the author
In case you’d like to know a little bit about me, I’m currently based in Seattle, Washington, working for Google. (Previously, I was at Amazon and a couple of startups in the Bay area.)
Most people know me through my blog, I’d Rather Be Writing, which has been an active online blog for tech comm for the past decade.
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 Literary Nonfiction, and then started 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 be boring), I found that I actually liked technical writing — a lot more than copywriting. Technical writing combines my love for writing and my fascination with technology. I get to play with tools and handle all aspects of content production, from design to styles to publishing workflows.
I worked as a traditional technical writer for some 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 to 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 didn’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, in-depth 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. The writing process is still just as relevant when writing API docs as other forms of docs.
If you want to read more personal details, see My life story, or reflections on what shaped my life’s career trajectory.
You’re probably taking this course because you want to develop your skills and knowledge to increase your capabilities at work, to enhance your skillset’s marketability, or 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.
By the way, I keep adding to this course in a Winchester Mystery House way, which means I keep adding rooms and extra hallways and doors, etc. If you were to print it out, the course would be more than 500 pages long. Few people get through the whole of it, and by the time they do, I’ve usually added a new section. So jump in and read through the topics you find most relevant and interesting. Don’t feel compelled to get through it all.
If you have a question for me, or just want to drop me a line, you can contact me through my Contact page. However, for most questions, you’ll get a much better response by asking them in the Write the Docs Slack. I’m also on Write the Docs Slack @tomjohnson, so feel free to ask me questions there.
About Tom Johnson
I'm an API technical writer based in the Seattle area. On this blog, I write about topics related to technical writing and communication — such as software documentation, API documentation, AI, information architecture, content strategy, writing processes, plain language, tech comm careers, and more. Check out my API documentation course if you're looking for more info about documenting APIs. Or see my posts on AI and AI course section for more on the latest in AI and tech comm.
If you're a technical writer and want to keep on top of the latest trends in the tech comm, be sure to subscribe to email updates below. You can also learn more about me or contact me. Finally, note that the opinions I express on my blog are my own points of view, not that of my employer.
3/166 pages complete. Only 163 more pages to go.