This is a recording of a presentation called Specialization myopia syndrome and the content journey, which I gave to a company's private tech comm event. With their permission, I'm posting it here. You can watch the recording via YouTube or listen the audio file as a podcast.
In this podcast, I chat with Adam Altman all about Redocly, an authoring/publishing tool for creating API documentation. Topics we discuss include why he started Redocly, the approach to API doc tools, what explains the continued popularity of Redocly, the docs-as-code approach to API tooling, and more.
This tutorial shows you how to build your own balance board with both single and double rollers, intended for standing intermittently at a standing desk. If you browse balance boards online, you'll find they're expensive for how simple they are: a piece of wood on a roller. Buying all the materials yourself will likely equal the cost of pre-built board, but your custom board will probably be better and you can make multiple balance boards (one for work, one for home). Plus, you can create a balance board with a double roller, or innovate in other ways.
After 2.5 years of avoiding it, I finally got Covid, probably Omicron based on the symptoms. I usually don't write about personal illness, but I also figure that my blog would have a void if I never wrote about Covid during the entire pandemic.
In a technology world growing increasingly specialized, technical writers can stay relevant by leveraging their most salient skill: the ability to see the big picture, to look across systems or individual APIs and see the shape of the whole. Technical writers can employ big-picture thinking with docs by emphasizing the following content types: (1) Detailed product overviews, (2) developer journeys, (3) cross-system workflows, (4) integrated API data, (5) and external domain knowledge.
Bobby Kennedy provides various courses on becometechnicalwriter.com to help people transition into technical writing. Previously, he mostly offered eight-week Jump School courses. Starting this spring, he's also offering a new, one-of-a-kind course called the Job-Hunter Support Group, which focuses on helping people find job openings for technical writers, prepare a resume and portfolio, and interview convincingly for the positions. The following is a Q&A with Bobby about the new course. (Note: This is a sponsored post.)
I'm starting a new series called Sitting, standing, and walking. Near the end of my last series on Journey away from smartphones, I described the growing discontent I felt by sitting in front of a screen all day. I longed to be outside, walking, engrossed in a panoramic view of the surrounding sky. Instead, it seemed most of my life, especially working in tech, was spent sitting. This series is all about ways to reduce sitting and avoid a sedentary life in front of the screen.
Jeff Krinock and Matt Hoff's 2016 book, May I Ask a Technical Question? Questions about digital reliability each of us should ask, provides an essential addition to the growing cyber-skeptic genre. The authors don't aim to vilify digital technology, but rather to encourage readers to thoughtfully consider the costs and benefits of each innovation.
Whatever skill you outsource, atrophies. When we outsource tasks to machines to perform, our ability to perform the task ourselves weakens. From driving to writing, automation threatens to reduce key elements of the human experience. In this post, I'll use Matthew Crawford's Why We Drive as a lens through which to interpret ChatGPT. Although Crawford's book is about driving, so many of the arguments could equally apply to writing.
If you haven't already heard about and experimented with ChatGPT, you need to. This generative AI writing tool has the potential to do for writing what art AI tools have already done for graphic content. ChatGPT is pretty mind-blowing. I didn't realize AI writing tools were so advanced.
In my previous post, Pulling readers through long documents, I explained that almost no one will read long documents, in my experience. It seems only task-based information demands enough payoff to make reading worth it to users. In this post, I'll explore a couple of examples where high-level information is essential and used, but in another light. The two examples are Macbeth and Elon Musk.
Long, high-level conceptual docs don't command the same reading attention as task-based docs. How do you pull a reader through a long doc when the payoff isn't a completed task, but merely greater understanding?
One of the most popular tutorials in my API doc course is this getting started tutorial for Stoplight Studio. Stoplight Studio is a tool for creating the OpenAPI specification and generating both reference and tutorial documentation. I recently worked with Stoplight writers to update all the screenshots and other details that have changed over the past year. The tutorial is now fully up to date.
Archbee is a relatively new documentation tool that offers a block-based editor, API publishing capability, content re-use, and more. The initial version of Archbee was released in early 2019. Since then, the product has been steadily ramping up in features and growing its customer base. In this podcast, I chat with Claudiu Dascalescu about Archbee, the features driving its adoption, their target audience, and more.
In this post, I describe an attempt at horizontal writing and what I learned from it. I was surprised to be struck with a kind of reverent awe for the complexity that this horizontal view revealed.
