My alternative to doing technical writing would be to do web design. I'd also like to use my creative talents to finish an API documentation course, among other efforts.
Although API documentation seems to be a rising trend, not many sessions at tech comm conferences focus on API documentation. This puzzles me and makes me wonder whether API doc is a sub-specialization of tech comm only popular in the Bay area.
Although you can't earn much direct revenue from blogging, writing a professional blog can be brand you as an expert in a specific field. This can open doors for you professionally.
I'm developing an online course for documenting REST APIs. I'm not quite done, and I'm trying to figure out the best freemium delivery model.
I'm publishing my documentation through Jekyll, delivering the content on internal servers for internal customers, and delivering it on Salesforce.com for external customers. I wish I had a better delivery mechanism externally other than Salesforce, but authentication solutions are either complicated or costly.
It's difficult to tell what platform someone is using for docs, but static site generators are pretty common. Other branding is sometimes easy to recognize.
I'm going to focus on writing more pages than posts. Given how few people use RSS, the distinction between pages and posts is becoming trivial. It makes more sense to focus my efforts on a more substantial format.
I added a section to my API documentation course on native library API documentation. For technical writers, this is one of the most difficult areas to excel in without a programming background.
I'll be available September 17 for an AMA session where you can ask me any questions you want, and I'll try to answer them.
I updated the Swagger tutorial in my API doc course. If you'd like to learn more about Swagger, you can follow along here for step-by-step instruction.
A grad student in tech comm needs your response to a short survey that examines responses to skill requirements in job postings. You can post your responses in comments.
Identifying and preventing broken links in single sourcing scenarios is a challenge with almost every tool and platform in tech comm. It is especially challenging with static site generators. I'm trying to implement some validity checkers with my Jekyll project to make sure I don't end up with dead or orphan links.
Pull requests are requests to merge edits from a branch back into the master. This workflow facilitates review of technical content on Github, but implementing it has some challenges. Namely, the reviewer would need to be familiar with code syntax, locations, and branching.
In a presentation to the STC Suncoast chapter, Mark Lewis compares object-oriented design to content re-use. It's an apt comparison that helps illustrate the parallels between programming and single sourcing.
Some common forms of authentication and authorization with APIs include Basic Auth, HMAC, and OAuth 2.0. In this post, I explain how these methods work. This material comes from other content I'm preparing about REST APIs.
