Over the past several months I have been working with Jenny Bryan on the googledrive package. I wanted to share a bit about the process and some things I learned along the way. While brainstorming this post, I went back through my GitHub commits to remind myself of the journey - it turns out they do a rather good job of showing the scope of this!
Day to day
The googledrive 📦 looked measurably different on this first day. I think this gives some really good insight into the iterative process of package design as well as how much I absorbed from Jenny along the way. In these early days, I was beavering away, building some small wrappers for Drive endpoints, spending most of my time getting to know the Drive documentation and celebrating small victories.
Small victory 1: The ability to upload files to Drive.
Small victory 2: The ability to delete files on Drive.
My day to day back in April seems so foreign to the workflow Jenny and I have now established, but those first few weeks were incredibly useful for getting me steeped in all things Google Drive. Our process eventually converged to:
👩🏻💻👩🏼💻 Video chatting once a week to set priorities / discuss design decisions.
✍️🙊 Documenting all problems as GitHub issues to resolve.
👷♀️👀 Submitting all changes via PRs for review.
The PR review process was quite new to me, but SO integral to the success of this package. Here is an example of what this can look like. Our first PR with review consisted of 49 commits and 66 comments 😱. The GitHub review process allowed Jenny to comment line by line on my code, gently pushing me towards better coding conventions and style. This process really helped me to absorb all things “tidyverse” in a systematic way.
Absorbing all things “tidyverse”
🌞 musing: learning a new coding style is like putting on freshly washed jeans; a struggle, but once I get it I'm like that looks GOOD 💃 pic.twitter.com/5QcEwEcI23
— Lucy 🌻 (@LucyStats) June 10, 2017
The tidyverse has an R Style Guide. My first pass at incorporating the style was switching my roxygen documentation to markdown (this can be enabled by adding Roxygen: list(markdown = TRUE) to the DESCRIPTION file, or if you already have documentation and you’d like to convert it to markdown automagically ✨, check out the roxygen2md 📦). This is an example of something I didn’t even know existed prior to this project. Other pieces I absorbed include:
Absorption example 1: Recommendations for continuous integration.
Absorption example 2: Learning sensible ways to test.
Absorption example 3: Cleaning up my code.
I made GREAT use of lintr 🛀 until the coding conventions became second nature to me. Even still, I cannot overstate the immense utility of coding alongside Jenny. I found myself slowly adapting her excellent coding principles and style simply from seeing her suggestions and reviewing her commits. She gently nudged me towards much prettier & more useful code!
Flexing my programming muscles
Finally, this experience allowed me to dive into 🏊 things I otherwise may not have been exposed to. Some things that were new to me include:
🙃 Writing S3 methods.
🙆🏻 Writing tests for an API-calling package.
💅 Working with / writing in an established coding style.
I am so grateful for the opportunity to learn these concepts in such a welcoming environment, and am certainly committed to passing any knowledge I have gained from this experience to anyone and everyone!
An ode to Jenny Bryan
I’d like to wrap up by expressing my immense gratitude to Jenny 👯. This experience was SO excellent due to her rockstar coding abilities, impeccable teaching skills, and of course her unwavering patience. And so I’d like to end with a haiku:
Thank you, tidyverse.
You’ve given me a leg up!
Checkout googledrive!