My 6 years of experience working with customers taught me to keep it simple when necessary. I learned the value of filtering deep technical information down to key facts when escalating to higher technical powers. Both of these aspects of technical writing have the same goal: translation and compression. Unnecessary complexity is actively harmful to decision makers. Necessary complexity poorly communicated wastes time and confuses the use of that information. A technical writer must be the audience’s advocate.

Public Examples of my Technical Writing

Confirm Signal Newsletter

Intended Audience: General Industry (Trading) I maintained a small newsletter that aimed to test or otherwise dispel some of the exploitative mania in trading that I had seen online. My goal was to use responsible statistics to test claims and challenge those that are not supported by the evidence.

Controls Course

Intended Audience: Technicians in Industry (Building Automation) Between 2011 and 2017 I was a field automation technician for commercial building automation systems. I was frustrated by the lack of information available online; the products and protocols are deeply proprietary and the companies that sell them like it that way. I started Controls Course as a way to share some of the deep knowledge I had obtained in the field.

GitHub

Intended Audience: Creators of Software Packages As a software developer I sometimes participate in public issues on GitHub, often because I have some stake in the outcome. Nearly all of my issues are unfortunately on private repositories.