This is a comprehensive, roughly chronological list of everything I've created as a technical
writer.
Highlights
Facades and backends. I am proud of this because it required deep collaboration
and ability to understand and explain complex concepts. As I was ramping up on
Pigweed I kept hearing how customers were confused about facades and backends. The
team knew we needed a doc on these concepts but just couldn't find the time to
prioritize the work. I got the team lead and a few engineers together to explain
these ideas and brainstorm how to document them. I'm thankful I recorded the
conversation because I referred back to that recording many times while drafting
the doc. Given that the engineers didn't request drastic rewrites during my review
I infer that I grokked the concepts pretty well. A key part of my grokking process is
to build prototypes myself: in this case I built a small embedded app that made use
of facades and backends.
Optimize website speed.
Note that the archived version of this page is a bit buggy.
This tutorial is an example of my ability to do holistic, user-focused thinking.
Chrome DevTools is a complex product with many, many features. In this tutorial I
focused on a real user need (figuring out how to make a website faster) and explained
all the features within DevTools that can help users achieve that goal, tying all the
features together into a holistic workflow. I created a sample app in React so that
users could get hands-on experience with all the tools. I hosted the sample app on a
free and easy-to-use hosting service (Glitch) to ensure that all users could access
the hands-on experience. Last, I made the tutorial fun! See the stuff about Tony the cat
to see what I mean. I also created a video version of the tutorial.
Based on the YouTube comments, the feedback is overwhelmingly positive!
Case study guidelines. I created these guidelines for web.dev contributors back
when I was content lead for that site. Case studies were very important for getting
enterprise partners to adopt new web platform technologies. A lot of Googlers in
partner-interfacing roles wanted to write case studies, but the writing quality was
all across the board. I created these guidelines to set quality expectations and
help potential contributors figure out how to create high-quality case studies. This
is one of many examples of my experience with scaling up docs quality beyond myself.
technicalwriting.tools
My personal blog about the technology of technical writing.
Improving Response Rates. My lightning talk
from Write The Docs 2018 (Portland). I discuss using experimentation and
the scientific method to improve engagement on "was this page helpful?"
widgets.
I helped Corrily with their docs for a little less than 1 month. I worked 21 hours
per week. I also created a sample app for them. Here is how the docs looked
before I worked with the team.
docs-migration-tool.
A tool that I wrote to automate most of the migration from the old
developer.chrome.com site to the new one. The old site used templated HTML,
whereas we wanted Markdown on the new one. I used Puppeteer to scrape the
old site's HTML content and convert it to Markdown. The tool also did
lots of normalization transformations on the content.
chrome-devrel-review-bot.
A GitHub bot that did automated content quality reviews on https://web.dev
pull requests.
Push notifications
Note: I was the sole author on the latest iteration of these documents.
If you see 2 or more authors, it means I based the content off of earlier
work that other people had created.
Quantified Code was a Berlin-based startup. Their main product was an automated code analysis tool for
Python codebases. I wrote over 100 guides for their companion site, The Little Book Of
Python Anti-Patterns. The purpose of the
companion site was to share their knowledge of Python best practices while also driving
traffic to their automated product. E.g. their sales pitch was "rather than trying to remember all
of these best practices, we have an automated tool that can do it for you." Subject matter experts at
Quantified Code gave me a list of topics to write about. If I recall correctly, each topic only had a
one-line description. I researched and drafted each guide myself. The subject matter
experts reviewed my guides.
Figure 1. The review that the Quantified Code people left me.
Note that the list below is not complete. It looks like some of the guides were deleted over time.
See my commit history
for the full list of contributions.
Arrayent was an internet of things startup. I was the sole technical writer in the company.
This was my first full-time technical writing job. I wrote developer documentation for an embedded API
as well as a REST API, in addition to end-user documentation for a couple of web applications.
I even hacked together a custom XSLT stylesheet to convert our Doxygen-generated reference
documentation to more reasonable HTML. I also migrated the company's documentation from Microsoft
Word to a website. I used Sphinx to generate the site and stored the source code on BitBucket. I deployed
the site to Heroku. I don't think I set up an automated deployment system because running the command to deploy to
Heroku was trivial. In addition to managing all of our customer-facing documentation I also
managed our SDKs, which we sent out to prospective customers.
