Having romanticized the possibilities of being a full-time writer as a kid, I've extreme admiration for those who actually are. This is because I've always been super-finicky about the content I produce, even if it isn't for the world to see. To provide some context, this roughly translates to proofreading (and editing) emails, texts, social media posts, blogposts, and even journal entries a gazillion times before I click the Post/Publish/Save button!

Fun Fact: This took exactly 20 minutes to write & 25 days to edit because I couldn't decide an "appropriate" way to start it.

Given that I can barely write content living up to my own expectations, I'm a huge fan of well-written....anything, to be honest. A lot of this unnecessary perfectionism spills over to my work, as well. In a world of shorter release cadence, it is extremely frustrating to work with/learn from documentation that is incomplete, incorrect, or lacks structure. Not only does such documentation significantly slow down learning, but it also contributes to an insane amount of repetition for the support folks. I believe when it comes to technical documentation - whether it be guides, tutorials, or just plain old release notes; brevity, accuracy, & quality are extremely important. 

So of course when I came to know about Google Season of Docs, I was super-pumped about participating! After reading through the guidelines, there were two major challenges that stood out:

a. I wasn't a professional technical writer.

b. My HTML/CSS/JS skills were rusty, at best.

Nevertheless, I approached a couple of organizations to understand their expectations & discuss project ideas that, I felt, I could learn from during the Technical Writer Exploration phase. During this period, I was also lucky to stumble upon Edidiong's post detailing her experience on the premier cohort last year and she, very kindly, took out time to clarify my doubts when I reached out to her on Twitter.

On the Season of Docs website, it does mention that technical writers can submit up to three project proposals. However after multiple deliberations with my mentors Martin Barisits, Mario Lassnig, & Thomas Beerman at CERN-HSF, I decided to submit only one towards modernizing & restructuring the documentation for the data management system powering the ATLAS & CMS experiments on the Large Hadron Collider, Rucio

My video montage of the days in between would not be as epic as the one Elle Woods had in Legally Blonde, so I am not even going to try! But yes, I invested this one month in researching documentation-as-a-service technologies and brushing up my web development basics.

Fast forward to when I received this email on a Monday morning (Aug 17th, to be precise):

So far, I'm elated to report that every single day has been a learning experience - whether it be in terms of collaboration, new documentation-as-a service technologies, documentation standards or even editing! I aim to cover my experiences in-depth for each of the phases in a separate post once I complete the program.


In the meanwhile, I'd like to leave you with some useful resources should you wish to embark on this journey yourself:

- Technical writer guide (Google)

- Edi's blogpost

- Teaching Art of Great Documentation

- freeCodeCamp's JS course

- freeCodeCamp's Responsive Web Design Certification

Happy reading (and learning!). If you have any questions, do feel free to reach out to me on LinkedIn/email/Twitter.

  • LinkedIn
  • Twitter

©2021 by divya-mohan.com.