Ripples of Change with R- It's more than just coding (Yvonne Kienast, CIHI)

Transcript#

This transcript was generated automatically and may contain errors.

Good morning, everyone. My presentation is titled Ripples of Change with R- It's more than just coding.

Imagine you drop a pebble into the pond. The ripple just doesn't stay in one place. It spreads in all directions, touching every corner of the pond. That is what happened when we introduced R to my colleagues at the Canadian Institute of Health Information, or short CIHI. Today, I will share how one small act of curiosity and collaboration sparked a ripple effect that transformed our team's approach to data analysis and how and why you can do the same.

Over the past two years, my colleagues and I moved from preparatory software to R. As you can imagine, this journey wasn't always easy. And one thing that became obvious very, very quickly, it wasn't just about learning R. It wasn't just about learning a new coding language. It was about reimagining how we think and how we work.

This story isn't just about learning R. It's about three principles that turned resistance into resilience. First, start with a purpose. Secondly, collaborate. Do not compete. And thirdly, learning by doing.

My name is Yvonne Kynast, and I'm a project lead with the Canadian Institute for Health Information. Unfortunately, I'm not able to be with you in Atlanta today in person. I'm wishing everyone a wonderful PositConf experience. On a regular basis, my colleagues and I work with health care data.

Becoming the R champion

So let me start sharing a personal story with you all. During our transition to R, a team member was stuck on a data extraction problem. As I mentioned before, we work with health care data. And in this case, the problem was large data issue. So my colleague was running out of memory because of the size, the data set my colleague was trying to query.

So what did I do? Instead of forcing them to learn everything from scratch, instead of telling them, I'm sorry, I can't help you. You need to figure this out on your own. I shared a simple R script from a similar problem I was working on. My colleague didn't need to master everything. They didn't even need to understand every single line of code in my script. They just needed to be pointed in the right direction to use the right tool because they were at the beginning of the learning journey. They needed to have an idea of where to start and a person to turn to.

So I became the person. I became the person they could turn to. I became to what I like to refer to as our R champion, and I became the bridge to our transition team within the organization.

My colleagues weren't just struggling with R code. They were frustrated. And I was frustrated by the gap about what I knew, how I knew the R deposit community works and how it was being received by my colleagues. And that is when I realized if I wanted to make R work for my team, if I wanted to spread the idea of collaborative sharing and learning as a community, I couldn't wait for them to catch up. I had to be the one to help them see and learn about the power of R, the power of sharing your open source knowledge and learning as a community. And this is how I became the pebble that started the first ripple.

Today, I want to share with all of you that everyone can be the pebble, that by starting small, sharing your knowledge and learning through projects, you and we all can turn resistance into a ripple of progress.

Today, I want to share with all of you that everyone can be the pebble, that by starting small, sharing your knowledge and learning through projects, you and we all can turn resistance into a ripple of progress.

Principle one: start with a purpose

So we were transitioning from legacy systems to open source tools. And when you as an organization go through such a big transformation, frustration will occur naturally. So when we introduced R to my colleagues, the team found overwhelmed by the endless tutorials and the internal R courses they had to take. And I could see their frustration. But there's one thing. If you learn an open source language, universal struggle is real.

The sheer volume of resources you have to deal with can paralyze you and not empower. But if you don't know what you're trying to solve, the sea of options actually become a swamp.

So where did we even start? Where did our team start this journey? So here's one thing I realized. Learning R isn't about mastering syntax. It's about solving real problems. But when you stare at your blank console, the possibilities overwhelm you.

So what does your team need to do? Well, your team needs to start with a purpose. And in order to start with a purpose, we need to ask two really key questions before diving into any R code. First, what does your team actually need? And secondly, who can guide you through it?

So let's break this starting with a purpose down. There are three components to it. First, the first one is focus on your team needs. Ask the following questions. Are you all new to R? Do you have someone with experience in your team? Or you are bringing in a new open source expert? What tasks do you repeat every day? Are you cleaning data, visualization trends, automating reports? You need to understand what your day-to-day tasks are. What data sets are you working with? How big are they? And what makes them unique?

So the answer isn't learning everything. It's about prioritizing. For the healthcare data set, we didn't need a full R course. We needed a script to handle the memory constraints we were dealing with. A quick fix that saved hours of frustration. So as I said, instead of forcing my colleague to learn R from scratch, I shared a solution tailored to the problem at hand with them.

And that is where the second key comes in. Find your R champion. As I stated at the beginning of this talk, I was the pebble that started the first ripple. And because I had prior R knowledge, I became the go-to person for my colleagues to ask questions, to help them troubleshoot error messages in R. So I became what I like to refer to our R champion. I became the person who helped my colleagues understand the language, explain its nuances, and I also tried to encourage them to shift the mindset and think like an open source coder.

So here's the secret to your R champion. An R champion is your anchor. They don't just teach code, they teach how to think in R. So my recommendation for every team that is trying to start this journey, find your R champion. Someone who can explain the why behind R, not just the how. Your champion doesn't just write code. They help you scope solutions. They will translate how to think in R to help you think in R. And they will act as a translator between your team, your IT team, and any other departments within your organization.

But here's also one thing I learned. Even a champion cannot guide you through this alone. You also need to shift your team's mindset from thinking of R as a tool to solve one problem to seeing it as a way to think differently.

Shifting mindset means embracing open source as a collaborative mindset. It's about seeing code not as a rigid script, but as a modular usable solution. It's about learning from the community. It's about learning how tools like GitLab, Stack Overflow, or the interactive features in RStudio work. It's about iterating, failing, learning new methods, and actually unlearning old habits. This shift isn't about efficiency. It's about fostering a culture where your team isn't just using open source tools, but thinking like an open source coder. That means asking questions, experimenting, failing, relearning, and trusting the community to help you grow.

So here's my call. In order to make a successful transition, don't start with the tool, start with your purpose. Define your team's needs, find someone to guide you through it, and don't forget, shift mindset and let open source thinking become your team's new language. Because when you prioritize real problem over abstract learning and trust the power of collaboration, you turn frustration into progress.

Principle two: collaborate, do not compete

And that brings me to my second principle, collaborate, do not compete. As I mentioned before, we work with healthcare data, and that data often contains information diagnosis codes, and those codes can change over a year. Hence, if you do any trending analysis, you need to account for those coding differences. And it happened that I had to solve a problem like this, and I was asking for the code from another team. Yes, the code was still in the proprietary software language, but I could still use it as a base to figure it out in R. However, I was told, no, we don't share codes.

But I came from an environment where I was used to sharing my codes. I was used to discussing error messages with my colleagues, and I was used to improve my codes to get it. So I was taken back a little bit.

So why do I share this story with you? Because we need to talk about something that feels counterintuitive in a world where individual achievement often is celebrated. We need to talk about collaboration. Open source drives on sharing knowledge, but here's the truth. Most of us have spent years working in silos. We have been taught over and over to guard our codes, to guard our insights, and to not share our mistakes. But what if I told you that the fastest way to solve a coding problem isn't by working alone or by working in silos?

So here is how you shift from fear of sharing to embracing collaboration. So first, we need to teach interdependent thinking. We need to stop seeing knowledge as a resource to hoard and start viewing it as something to build together. Normalize asking questions, build the trust among each other, help each other out when you try to solve a coding problem, be brave. For me, asking for help isn't a weakness, it's a superpower. It's how we turn frustration into growth and build trust.

For me, asking for help isn't a weakness, it's a superpower. It's how we turn frustration into growth and build trust.

But secondly, there's an action component needed. And here's what works. Here's what worked for our team. You need fixed exchanges or fixed learning. So what do I mean with that? Every two weeks, we had a dedicated hour of peer-to-peer learning. During that period, you shouldn't have any other meetings scheduled. Just a space to walk through code, to ask questions, to troubleshoot errors, to brainstorm, for example, better ways how to visualize data. And also a space to rant.

Was this awkward at first? Or really, it was really awkward. And trust was fragile. But when you create a culture where sharing isn't optional, it becomes inevitable. And over time, sharing actually became the new norm for us.

And if you don't believe it, take it from my colleague of mine. To rely on community, the fastest way to solve a coding challenge was to ask for help. Even if you didn't believe it, you should ask for help. And the fastest way to solve a coding challenge was to ask for help. Even if you didn't get a solution, you have pointed to the right direction. And for me, this isn't just wisdom. It's survival and a really great example how our team learned to solve coding problems with time.

But I encourage you to not stop at your team. It's also really, really important to build a company like our community. So encourage managers to set time for the sessions. And let your colleagues know that you're not just coding alone. You're all in this together. That you're all learning and coding together. Open source isn't about individual glory. It's actually about the collective progress. And when you share your knowledge, you're not losing it. You are amplifying it.

So here's my challenge for you. Stop competing for recognition. Stop collaborating to solve problems. Because in open source for me, the only thing we are building is each other.

Principle three: learning by doing

And that leads me to my last principle. Learn. And because a lot of issues you and your colleagues will encounter in your learning journey, it will be actually solving problems on the task at hand for your project. So my last point to successful transition to R is learning by doing. The best way to master R is through projects that matter, not just theory.

But the struggle here is to having to learn R, having to learn a new coding language, while also you have to do all the other work. And often the resistance you and your colleagues will encounter here is putting off the learning. Because there is no time. We had the same challenge. We were fully working on our projects, but we were also expected to finish our R conversion or to finish our R courses. And it would have been helpful if we all had even more time.

So how do you embrace the newly established way of thinking in R to record your projects when time is limited? First, you need to realize you're learning professionally and not academically. Academia teaches theory. The course you take teach you theory. But real world work demands application. When you learn R for a project, you're not just solving code. You're solving a business problem. You're solving a data challenge. And you're creating a workflow that matters. You're creating a workflow that matters and hopefully a workflow that can be reused in the future.

So we talked about shifting the mindset to think like an open source coder. We also need to shift your mindset in terms of learning. You're no longer in a classroom. You're actually in a laboratory. So focus on what your project needs. Learn what you need for your day to day tasks first. No more and no less. Later on, once you're more confident in R coding, go and explore what else is possible.

And that leads me to my second point. Practice by working on projects. Here's a secret. Advanced coding skills come from experience. And experience does not come from taking course after course after course. Every unanticipated error, ever data wrangling hurting, treat it as a lesson because that's what it is. It's a lesson. You won't master R by studying all the packages or every function within a package. You will do it by coding through your projects.

And that leads me to my third point. Allocate fixed time for learning by working on your projects. You need to create time to do this. So how did our team do this? My managers block three hours every Friday for R learning. For about a year and a half. During those times, there were no other meetings and also there shouldn't be any interruptions. And to put this into perspective, that's about 10% of your time during a week. But it was enough to build muscle memory. So if your team, if you're on a team that goes through this journey, push for this. Protect your time because it will help you learn faster, make fewer mistakes and turn projects into progress.

So here's my challenge for you. Next week, block three hours, start the project and stop waiting for the perfect time. Because the only way to master R is to actually use it. But let me be clear. This is not about perfection. It is about progress. Every line of code you write for your team's project is a step towards becoming an R expert. You don't need to master every package or every function. You need to solve the problem at hand.

So here's the trick. Think of it like a training. You can't build muscle by watching others lift weights. You actually have to lift the weights by yourself. So take those three hours, use those three hours to debug a tricky data set, automate a repetitive task or visualize data that once seemed impossible. Let your mistakes be your mentors. And when you finish, celebrate the progress, not the perfection. Because in a world of open source, learning by doing isn't just a strategy. It's a mindset. And if you run into bigger issues, trust your colleagues and ask them for help.

Closing: be the pebble

So let me restate what we covered today. In order to have a successful transition to R, first, you need to learn how to use R. Start with a purpose. Don't let the endless possibilities of R overwhelm you. Focus on your team's need, shift your mindset and find your R champion. And secondly, collaborate. Do not compete. Open source thrives on sharing knowledge and building bridges within your team and beyond. And third, learning by doing. The best way to master R is through projects that matter, not just theory.

At the beginning, I shared with you that I was the person, that I was the pebble that started to advocate for R. As you can see from my story, you don't have to make a giant splash. Just dare to start the ripple and be the first pebble. Maybe your team is standing at the edge of the pond today, unsure what will happen. So be the first pebble, share an idea, invite a colleague to learn together. Watch your single action become something bigger than you ever imagined. Don't wait for someone else to start, be the spark. You can be the pebble that casts the first ripple to start the R journey in your team.

Don't wait for someone else to start, be the spark. You can be the pebble that casts the first ripple to start the R journey in your team.

Thank you very much. At this time, I want to take the opportunity to thank our analytical modernization toolkit team, our transition team, the central team at QIHAT, that made all of this possible. And I want to give a special shout out and thank you to our mentors, Gabriel Muniz Acevedo and Sean Salisbury. Without them, none of this would have been possible. I also want to thank my manager on this project, Jennifer DeSilva, for her continued support. And I want to congratulate all my colleagues on making this transition a noteworthy success, and especially for trusting me.

What you just heard was a team perspective of our transition from preparatory software to R. If you all want to learn more about the organizational perspective, my colleague, Kateryna Gabanienko, will present LEND later on in this session. And if you have any questions, I'm on LEND on Discord. Thank you very much.

Ripples of Change with R- It's more than just coding (Yvonne Kienast, CIHI) | posit::conf(2025)

Transcript#

Becoming the R champion

Principle one: start with a purpose

Principle two: collaborate, do not compete

Principle three: learning by doing

Closing: be the pebble