Ask most technical writers for writing samples and they cringe. My approach is to share a mix of technical documentation samples I’ve crafted as well as full-blown API documentation UIs I’ve built at the code level. Due to NDA restrictions, I don’t share confidential samples.

Beware: the problem running rampant throughout the software industry is finding writers who can onboard quickly. As in hit the ground running. I’ve had the pleasure of working for many large companies and dev teams working on all types of technology stacks.

Project: Rewrite of API documents categorized by tutorials/reference materials.
Target audience: Savvy API users ready to save money on their shipping.
Assignment details: Revamp outdated help documents and update formatting along with correct request and response code examples.

  1. Delete all live published API reference docs. All of them were wrong. Dead wrong.
  2. Example request and response code examples didn’t work.
  3. Likely for 5 years before James Messinger (formerly of Postman.com) took over their wheelhouse.
  4. We knocked out the entire project in 4 months.
  5. The secret to so much production?
  6. One hour video calls everyday discussing the correct endpoint use cases.
  7. Then test each one in Curl via Terminal. Brute force user experience testing.

Below are some of the documents I wrote for ShipEngine:

Project: API Design Guidelines.
Target audience: Automotive API developers.
Assignment details: Integrate API design standards for a public automotive API platform.

  1. The project consolidates acceptable industry standards designing robust APIs for App end-users.
  2. Automotive API developers are a rare breed. Some of the best developers I know.
  3. Because Fortellis launched many new endpoints simultaneously, documentation drafts were need quickly.
  4. Documents were published in both Apigee SmartDocs and Drupal.
  5. All API documents were designed by use cases for each endpoint.
  6. CDK Global is a fabulous organization and the launch of their new Fortellis brand was a smashing success at NADA 2017.

Project: API UI rebuild and rewrite.
Target audience: Developers.
Assignment details: Rebuild API documentation UI after testing all endpoints.

  1. I coded the three-column format using Ruby | Slate | Markdown.
  2. The design is by Rob Lord.
  3. Rob Lord worked at Tripit and Stripe.
  4. Great guy. We’ve worked together on multiple projects.
  5. Here is the published build UI.
  6. Here are the build files.
  7. Read about Rob Lord talking about how he built it.
  8. The published build file is a static .MD file.
  9. Static . MD files are faster than the Roadrunner escaping Wile E Coyote.
  10. You can host it anywhere. Like on an Amazon bucket for .10 cents a day.
  11. Editing the CSS codes to match the TowerData brand colors were job #1.
  12. Then tweak sidebar widths as you add more topics.
  13. They may not all fit without line breaks.
  14. Update font sizes so developers older than 35 without the best vision can read the docs.
  15. Right column code examples can be intimidating at first.
  16. Taking one code example at a time per programming language works best.
  17. Git push, commit. Rinse, repeat.
  18. I’m pretty passionate about API documentation. Guess who else is?
  19. Stripe.com/docs/api.
  20. Pretty elegant huh?
  21. Their newest flavor for the code examples (unless it changes after this writing) is powered by React modules.

Project: New API documentation UI build.
Target audience: Fintech developers. Because of an NDA, all content is been stricken from the link below.
Assignment details: Design an online API documentation UI for a virtual credit card product. I coded the three-column format using Ruby | Slate | Markdown to support code examples.

Project: API documentation.
Target audience: Developers.
Assignment details: the Stripe projects were a mix of helping developers blend a simplified UI with API code examples. My specific role was to solve the problem bridging the gap between developers and end-users to cut through complex connectivity blockers.

Project: Google Cloud BigQuery.
Target audience: Developers new to BigQuery web UI.
Assignment details: Rewrite Google’s BigQuery web UI Quickstart documentation. Then build the new content within a page using toggles.

Project: Scientific research paper on big data integration.
Target audience: Enterprise data engineers.
Assignment details: Write a review of the problems integrating big data and how SQL solves blockers using Category Theory and CQL.

Project: Craft engaging blog posts on technical topics.
Target audience: API tech writers and project managers.
Assignment details: Write in-depth blog posts related to technical writing, technology and advice streamlining the hiring of technical writers.

Project: Spark Analytics whitepaper.
Target audience: Big data analysts.
Assignment details: Craft a blended white paper balancing technical jargon with definitive reasons data scientists should consider adopting Apache Spark.

Project: Write blog posts for Adobe Vice Presidents.
Target audience: Adobe followers.
Assignment details: Adobe engaged me to write blog posts for their VPs. The assignments were to dovetail creative approaches with Adobe tool solutions. The constraints were taking creative liberties to represent the professional perspectives of the VPs.

Project: Satirical blog posts.
Target audience: Tech followers desperate for something entertaining to read.
Assignment details: The Incipio blog posts bridged the gap between technology-related topics and humor. Because of the freedom to select my topics, I chose to delve into relevant newsworthy stories crafting engaging blog posts.