Employment and salary outlook for technical writers based on the 2017-2018 STC Salary Database
The 2017-2018 STC Salary Database was recently released, and the employment and salary levels for technical writers are looking really good — especially for some areas. 'San Jose-Sunnyvale-Santa Clara' (a Metropolitan Statistical Area or MSA) had a 34.5% increase in tech writer employment for 2017 and continued to be the highest-paying MSA for the fifth straight year in a row. In this post, I'll share a few highlights from the report.
The absolute worst that can happen in 2019, or, Imagining a dystopian corporatocracy emerge after a permanent government collapse
As we enter into 2019, it's fun to think about what's in store for the upcoming year. I've already written about tech comm trends ad nauseam this year, so I won't repeat the same arguments. (If you missed those posts, I argue for an increased emphasis on subject-matter familiarity as a requirement for tech writers to be competitive, which many would say, duh — of course.) Instead, I'd like to explore another, more entertaining angle: the absolute worst that can happen in 2019. We all love the dystopian imagination, so let's indulge it. Okay, let's go really overboard and think about the absolute worst series of events that could happen to us this year. After all, isn't it better to plan for the worst and hope for the best?
Is Premium Grammarly worth it for identifying style and grammar issues in tech docs?
I recently ran every page of my API doc site through Grammarly to identify and correct style and grammar issues. Grammarly provides a lot of valuable feedback that is worth considering as you edit your writing. However, the issues flagged are more helpful for conceptual and narrative information rather than for technical procedures, in part due to the restricted vocabulary, unique tech terms, and more frequent passive voice in tech docs. Also, data privacy issues probably prevent Grammarly from gaining more traction in the enterprise.
Research on code documentation -- when not to comment on code
In this post, I summarize the findings of an extensive research project about how developers at Google find and use code documentation. The research found that for simple code, sometimes developers prefer to read the code directly. However, for more complex code, developers consult documentation, often by looking in the formal class declarations for information they need; other times they look at comments in the implementation code. Besides the location of docs, the researchers also identify what type of answers and guidance developers want in code documentation.
Top 10 holiday gifts for technical writers
Wondering what to get the precious technical writer in your family or workplace for the holidays? Here are some gift ideas.
My podcast about writing with Ellis Pratt on Cherryleaf
I recently chatted with Ellis Pratt on his Cherryleaf podcast. The episode is called Podcast 49: Should you specialise? Interview with Tom Johnson. We chatted about a whole bunch of topics, not just the should you specialize question in the title. Topics include purposes for writing, the influence of blog and podcasts, long and short forms of content, evidence for trends, what employers are looking for in jobs, unicorn candidates, how to define yourself, and more. If you like podcasts, definitely listen to this one.
Recording for Menlo Park API documentation workshop now available -- and some thoughts on using cardioid versus omnidirectional microphones for recording
The recording for the full-day API workshop that I recently gave in Menlo Park, California, is now available. This recording provides more than 5 hours of instruction about writing API docs -- for free. I also share some thoughts on cardioid versus omnidirectional microphones, and which is better in a workshop setting. The audio narration of this post switches around the microphones so you can hear the difference.
New post in Simplifying Complexity series -- Principle 11: Be both a generalist and specialist at the same time
In my Simplifying Complexity series, I added a new post called, Principle 11: Be both a generalist and specialist at the same time. I also recorded this essay as a narrated podcast.
My upcoming presentation and workshop at the 2019 STC Summit in Denver
I'll be giving an upcoming presentation and workshop at the STC Summit in Denver, Colorado, held May 5-8, 2018. My presentation is on trends and the dilemma between being a specialist or generalist; my workshop is on API documentation.
Upcoming BrightTALK webinar on trends -- January 15, 2019
I'll be giving an upcoming free webinar about trends on BrightTALK on January 15, 2019.
Recap and thoughts on the WTD Australia 2018 conference (Write the Docs podcast episode 18)
In episode 18 of the Write the Docs podcast, we discuss the recent Write the Docs Australia 2018 conference held in Melbourne, Australia. Jared was an emcee at the event and shares his inside perspective about what made the event so successful. We dive deep into the unconference format, how to instill the Write the Docs brand into the conference experience, how super volunteers can avoid burnout, what sessions stood out, and more. Also, Chris confesses that he has attended about 40 conferences this year, and explains a few reasons why.
Bibliography of API documentation articles
If you're doing research on API documentation, Bob Watson's API Bibliography, listing more than 100 articles, can be a great starting point.
How to avoid being a secretary for engineers
If we just see our task as documenting solutions that engineers have solved, it removes the creativity and critical thinking dimension from tech comm. The creative dimension in tech comm comes into play as we identify and solve tech comm challenges, such as devising ways to simplify complexity or otherwise improve the user experience.
I'd Rather Be Writing is now an Alexa Flash Briefing skill