Do you have experience using Git through the command line and treating docs-as-code?

Yes.

Please tell us about your experience with Git and docs as code. You can enter "NA" if you don't have experience in this area.

I first started working with Git on the command line in 2020 while enrolled in a frontend development and React JS certification (https://github.com/budsimpson). I remember quickly falling in love with the simplicity and immediacy of working on the command line. I was tethered to my computer’s “brains,” and I felt like Matthew Broderick’s character, David Lightman, from the movie War Games. Besides, what 90s kid wouldn’t be snake-charmed by a terminal window chock full of monospace? Since that first experience with Git on the command line, I have built several client websites using plain text editors like VS Code, and regularly push commits to remote repos from the command line for work and for personal projects.

I am also familiar with the docs as code framework. However, I had no idea that it had a name until I read this job posting. It was then that I realized that the framework I have recommended to my colleagues had a name, and was referred to as docs as code. I have advocated for this framework at The Home Depot ever since my interview, and I’m delighted to share that we now have a docs as code pilot and discovery program underway to determine our tooling and Git flow. My team has a massive SharePoint site bursting with static documents, broken links, and outdated material. Part of my responsibility is to rewrite and maintain this documentation and align it to industry standards, like docs as code. I am excited to see the transformational effect that it will have on my team’s ability to find and share critical information.

Can you describe your participation in a major documentation effort?

One of the biggest documentation efforts I’ve participated in is currently underway.

The Personalized Audience Module Unification (PAMU) is a framework for building highly personalized and traceable emails at The Home Depot. The framework is complex, changes constantly, and relies on several tools and applications, each with their own steep learning curve. Developers created the PAMU User Guide—a 76-page Word document—as a training and reference manual for new hires. The manual requires extensive and frequent updates. Knowing this, my team and I opted to transition it to a more scalable and version-controlled format.

The goal is to:

• - Convert the resource to Markdown and group content into 3-4 topic types

• - Use Git tools to create initial commits and track peer review changes in a dedicated branch

• - Push commits to the main branch, automating a publishing job to GitHub Pages or Confluence

Please share one or more writing samples.

My company’s GitHub repo is private, therefore I’ve attached a .MD of the reference topic here. DOWNLOAD WRITING SAMPLE

My team and I recently created this reference topic on QA automation scripts for a few of our email campaigns. These scripts automate time-consuming QA tasks, such as validating links or checking the existence of tracking parameters. All of the scripts referenced here were created and collected by a developer who was reassigned to another department. Therefore, it was critical that we document the scripts, and consolidate them here.

Here’s a gist of our workflow:

The SME for this project is the developer who created the automation scripts. He created a first draft of a Markdown file in PyCharm, which is his text editor of choice. After he completed his first pass, he placed the Markdown file in a README repo in the codebase next to the .py file that houses the automation scripts. The developer then pushed a commit to our team’s main GitHub branch.

After the initial commit, I created a review branch, and completed a pass for clarity, accessibility, and style guide adherence. I also set aside observation time with the developer to see the script in action.

After making my changes, I opened a pull request and invited the QA product manager to review the document. She made a few minor changes, and we updated the pull request.

After we approved the changes, I merged the review branch into the main branch. We used GitHub Pages to house the finished document.

We’re working on several improvements to this workflow, namely publishing and code review automation, as well as integration with an issue tracker.