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.
- False Precision in Modelling
- Position Sizing Based on Conviction or Volatility
- Checking for Seasonality in the S&P 500
- Testing SqueezeMetrics GEX and DIX Indices
- Don’t Do Statistics Before Causality
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.
- What is a BBMD, and Why Do We Need It?
- What is a BACnet Instance Number?
- When and Why Do We Need an End of Line Termination?
- Visual Look at RS-485 Without Termination
- A Case Study on the Importance of RS-485 Grounding
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.