 Hi, my name is Malcolm Barrett. I'm an R developer and a clinical research data scientist at Teladoc Health. We're a telemedicine company and as you can imagine, we've grown considerably over the pandemic. As we've done so, we've bumped into the question of how do we grow our code base and the skills of our developers as we work within this growing space. In his keynote talk a few years ago at USAR, Hadley Wickham said that in developing the tidyverse, he was trying to create a pit of success. This is a metaphor from some strains of computer science where basically you want to make it as easy as possible to succeed. You should fall right into the pit of success. There should be nothing blocking away. Whereas it should be hard to fail. It should be a hill of failure to go along with the pit of success. This has been a guiding principle on our team on the clinical research analytics department. Where we have tried to take our code, make it really robust and cultivate best practices in coding that work well for us and other people at our organization. In doing so, we've had to adjust the way that we're thinking about it from a pit of success to a canyon of success. How do we take what we're doing and scale it across our teams and within our growing team as people on board? How do we take these techniques, make them robust and help make it easy for people to succeed? The main techniques that I'll be talking about in this talk are using consistent robust code via our packages and embedding scalable best practices in those packages that are self-defining, self-documenting and easy to use. Developing consistent robust code is a challenge. As people code together, within teams and across teams can often be a little bit like children whispering to each other in a game of telephone. We use a bit of code here, we share it with somebody, they use a bit here, they make some changes, then somebody else uses it somewhere else. Code is shared and grows organically over time. However, in this free form, it becomes very easy for this code to become fragile, out of date or just not reproducible. In R, Hadley Wickham once said, the fundamental unit of shareable code is the package. R has this great system for sharing code in the R package. And so we have developed a whole set of R packages to support our workflows. Our main tool is called Lavango, which is the legacy organization that I was a part of prior to our merger with Teladoc Health. One of our main functions here is to create a package that meets our standards. This is based on the use this package, one of my favorite packages. It helps us do some of our structured setup for what needs to be done for any type of R package, but additionally it helps us do important standardized tools like specific ways of testing, specific ways of licensing our code, and making sure that we have Git repo setup right away. We even have ways of working with our, you know, very unique way that we have to work with our IT and tech ops teams to connect with and use GitHub. When we develop packages at Teladoc, we focus on making sure that it's easy for people to use for a wide variety of situations. Lavango package in particular has helped us scale best practices. We've really focused on what are our workflows, what are our values in what we're trying to do, both for research environments and for internal business environments. The core ideas in this package are that when we create a project, it should be independent from other projects that we should be using version control and that we should have complete reproducibility. In practice, what this means is that every project is in our studio project. Every project is also a Git repository, and every repository has an Rn environment to manage package versions. We also use targets to manage our code workflows. So when we use create Lavango project, one of our main functions in the Lavango package, it sets up a lot of this for us. It initializes in our environment, it creates in our studio project, it initializes a Git repository, and it helps us do some other setup. These tools also support automated code style that matches our team style. Team code styles are really important, and we want to make it as easy as possible for people to be able to use them. Similarly, version control and collaboration through Git and GitHub workflows are exceptionally important for the way that we work together. To make sure that people are doing this, doing it well, and doing it often, we've made it easy via extensions for the use this package to connect to our GitHub repositories and to work with Git code and code reviews in the way that we expect. It also helps us set up code pipelines via targets and a few other opinionated approaches to how projects should be done. Developing your own internal R packages is an exceptionally profoundly powerful way of taking what you want your team and other teams to be doing and making it easy for people to do that. Using R packages at Teladoc has helped us scale best practices within our team and across other teams as we've grown. I'm Malcolm Barrett, you can find me on Twitter, on my website, or on GitHub. Thank you.