Eric Berg’s technical writing portfolio#
About me#
After a decade of working in production engineering, I’ve realized that some of my greatest impact comes from my technical documentation. I’m excited to apply to Technical Writer positions as my next career move.
My enthusiasm for technical writing has stretched throughout my career. As an undergrad, getting a double major in English and Computer Science from Tufts University, I was happiest making readmes for my technical projects. This passion for documentation extended into my professional life. As a sysadmin at Tufts, I took on the customer-facing help documentation and FAQs, saving my team valuable time answering tickets. As an SRE at Foursquare, I volunteered to own my team’s playbooks, written for engineers debugging at 2 AM, helping the company maintain a 99.9% uptime. As a software engineer at Harvard Medical School, I made sure to document our infrastructure and security best practices for a cross-functional team, helping maintain the security of a vital genetics platform.
What excites me about technical writing is the impact. Effective technical writing marks the difference between a finished, polished product and a proof-of-concept. The impact I made with a strong technical document, and its ability to cut down debugging time for customers or the team, rivals any impact I made with the code I wrote. As a technical writer, I am a force multiplier, allowing the work of engineers to shine through. I want that effort to be the primary focus of my career from now on.
About this portfolio#
This portfolio demonstrates my ability to create different documentation types for different audiences, from reference guides for engineers to how-to guides for on-call engineers.
I built this site using modern docs-as-code practices: git for version control, Hugo for static site generation, GitHub Actions for CI/CD, and Vale with the Microsoft Style Guide for quality checks. You can view the source of my site at github.com/ebberg/portfolio.
About the samples#
I wrote documentation for open-source projects I know well:
Alertmon: I wrote this alerting tool. My documentation combines my deep product understanding with user empathy.
rpmbuild: I worked extensively with RPM and the rpmbuild tool in production. My documentation utilizes my knowledge of product pain points and real-world usage.
Each sample targets a specific audience, has a specific impact, and demonstrates a different documentation type: reference, how-to guide, and conceptual overview. My samples are: