1. apidoc
2. documenting APIs
3. Introduction to REST APIs

About the author

In case you’d like to know a little bit about me, I’m currently based in the metro Seoul area (North Gyeonggido province) working as a freelancer. I mainly write documentation of prototyping game apps using the most current technology and gadgets.

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.

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.

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.