Data Science Hangout | Ryan Garnett, Green Shield Canada | Getting People Excited about Open Roles

Welcome, everybody, to the Data Science Hangout. For anyone joining for the first time, this is an open space for the whole data science community, really to connect and chat about data science leadership, what's going on in the world of data science, and all the questions that you're facing. So we want this to be a space where everybody can participate and we can hear from everyone. So there's multiple ways to ask questions. All the questions are audience-led, so you could jump in live, put questions in the chat, or we also have a Slido link that Tyler will share in the chat in just a moment. But with Slido, you can ask questions anonymously, too. And just a quick note that it will be recorded and shared up to YouTube for anybody who missed it as well.

But I also just want to say thank you so much to everyone here for building the Data Science Hangout with us this year. I can't believe that this is the last one for 2021. It's somehow five months have flown by so quickly. But I'm so excited to be joined by my co-host for today, Ryan Garnett. Ryan's a Manager of Data Management Insights and Analytics at Greenshield Canada. And Ryan, I'd love to just kind of start things off by having you introduce yourself and share a bit about your team and the work you do.

Totally. Yeah, thank you. Well, first, let me say thank you for the opportunity. You know, I secretly have been following you along online, like many other people, I'm sure, that follow along with a lot of the great stuff that you're doing. And shout out to everyone here, like RStudio and our community itself is just fantastic. And I'm privileged to be part of that.

A little bit about me. I'm a bit of a weirdo. I'm not your stereotypical data sciencey type of person. I actually come from a recreation background. So when I was a kid, I wanted to be Yogi the Bear. I wanted to work in a national park and do all that kind of stuff. So I went to school for outdoor recreation, parks and tourism, and geography. That was kind of my thing. And Northwestern Ontario, shout out to Lakehead University, above Duluth for you Americans. So real, real north, even above Minneapolis. So that's where I really got introduced to kind of data and analytics and stuff like that. But from the geographic standpoint, using GIS for those of you who are facial people. So that kind of led me down my path. And then I did remote sensing, which is using satellite imagery. And I jumped into the world of data and analytics that way, not your data science 2010, 2012, kind of like famously quoted position.

And if I may, I think we were doing data science really early in the geospatial world, you know, big, bigger, not big, but big data, like satellite imagery and analysis. And we're doing like a lot of people kind of things there. So that really led me into it. And then as I went through grad school and stuff like that, I wanted to transition out of being just a geo type of person. And I wanted to get more into analytics and building it that way and going that approach. And that happened when I was at the City of Toronto. I started the data science kind of team and practice, City of Toronto, it was still early days, 2015, 2016. And that's where I was like, okay, I got to do this myself. Like I need to start taking on those kinds of personas and characteristics and with the open data team. And that's when I started my R journey in 2018. That's when I started to program and script and what's a function like all those pieces.

So I'm totally not your stereotypical person. I don't come from that computer science, statistics, background, commerce, or sorry, commerce, econ kind of piece. But I think as we start seeing data science evolve from that famous quote is the sexiest job of the 21st century, you know, in that area, we're starting to see that data science is migrating a little bit from a tech discipline that comes out of engineering, computer science, like statistics, into an objective approach to solve problems. And how do you solve problems, we need that domain knowledge. And that's where we're starting to see that real big shift in companies like RStudio, because I'm always going to do a plug, because I just think you guys are awesome. I really helped democratizing that so that people can jump in at different levels, right? You don't have to have a PhD in machine learning or data science from Stanford University to start solving these problems objectively through a code based approach and using best practices or standardizations of things like it really is being put in the hands of people. And that really excites me. So, Rachel, as we spoke before, I can talk a lot. So I'm going to pause.

Building the analytics environment at Greenshield Canada

No, that's awesome. Thank you for the intro. In talking with you a few weeks ago, too, I was so impressed by the like process your team has gone through to start to build up the analytics environment. And I think as we wait for a few questions to come in from everyone, that might be great to touch upon.

Sure. Yeah, thank you for putting me back on track. I'll appreciate you to be my North Star. So I joined Greenshield. And for those of you who may or may not know, Greenshield is a health care benefit provider in Canada, and we're actually a not for profit. So we're a social entrepreneur, like social kind of company, and we want to improve the health and life of Canadians. And we do a lot of social impact. And that really drew me to the organization.

So I came in and we were a fresh upstart kind of team. So I joined in February, they had started their team in 2018, kind of timeframe. And I was telling you before, there's kind of two approaches that we generally see teams get built. These are you build like a strong engineering, you harden up your infrastructure, and you build it out that that type of approach, like really hardcore. Sometimes it's a bit of a theoretical look, if you're taking a bunch of graduate students or PhD students to build up your team, or your how we approached it was, we want to show the value of analytics in an organization that has stereotypically not been data and digitally driven, like how we grew up as an organization in the healthcare providing space. That was in our number one forte. So how do we show the value to senior executives, board members, because we're not for profit.

So the approach that was taken, and I can't take any credit for it. That was the previous team, like how they built a team was, let's have some domain experts that are super interested. And let's have them play. I mean, that in a positive way, play with data and start showing because they know the domain, they know things are really good with customers and in our other lines of business, to be able to show how data can provide value. And that was great. So a lot of things were focused on POC and really quick and like that iterative kind of approach with let's show stuff quickly. And then they caught lightning in a bottle. Like they absolutely caught it. It was like, yes, we have it. Now what do we do with it? It's that common piece. Like now that I have lightning, like what do I do with this bottle of lightning?

And for those of you may be like, what is he talking about? Like, Alexander Graham? No, no, no. I mean, now that you have interest, and you have your leadership, really, like, there's something here. How do you turn that into production? How do you scale it? How do you replicate something that feels not replicatable? And that's that whole startup and POC kind of environment. So what we did when I joined is like, well, let's take that approach and let's build on it. But let's build the foundation. And let's kind of put some of those pieces in there. And in foundation, from a production standpoint has quite a few components. And one of the things that I really want to harden up and instill in because we're we are an organization, a company is like a product line approach. Let's have some products, products can be repeatable. So let's build that kind of culture in there. Let's make people's lives easy as possible. And let's always provide a space for exploration, where people can try and where they can play and where, you know, we hear the buzzword, he kind of fail fast, like, well, let's explore quick. And then that's kind of fail fast without using the F word that people are so terrified of, like, no, no, let's explore. Let's do it quick and see if there's anywhere to go.

As we got in, again, I'm going to plug, we were not a code first kind of organization. That's just not how we were. And we had a couple people who had dabbled in R and we're doing some things. And then we have we have to start Albert, a software developer turned data science. So go us turning people over. And he's our superstar. And he's our big time data scientist. So we decided that we would like to have a stack. And we chose RStudio for a couple reasons. One, there's more than one person myself that could use it. So that was always a positive. I think RStudio and R as approach with using tidy as as that kind of grouping of packages, the tidyverse allows for really easy uptake, and swinging people up into like getting them moving forward. And then the platforms, I swear, I'm not doing this from a marketing sales, but the platform really allowed us to like build.

So as we were, like many organizations, not data first, like that's not how we started, we didn't start in the internet age, we didn't start in the data science age, working with it, we don't have like, here's your amazing 64 gig laptops, we're all working with like our standard laptops, and it kind of minimize some of the things that we're able to do. So that's where, where I reflect back and like to your question, how do we get going, making things easier. So we build like an infrastructure where people can log in and do things and share code differently and change that whole, that whole working approach that you can explore and collaborate, and literally build in time to educate. Right. So we have every couple weeks we do called data ops, fun buzzwords, you can say it right, like we're doing that and like introducing people on how to do things, whether that's like code based stuff in Git, or building APIs and build functions and introducing them to our Connect and Workbench and things like that. So we're really trying to build that piece, always with the goal of building a product that serves our use cases.

Tackling challenges with five questions

No, that's really helpful. And Bruno, I'd love to have you jump in and ask that too.

So how difficult was it to transition to code based data science? So it's, it's something in the life of an organization. You have to get stakeholder to like, believe in what you're pushing. So what was the most challenging part of that? And what kept you motivated? So you said you started, I think, 2018.

So our team started in 2018. I started in February 2021.

Yep. So so if I get your question, just to paraphrase, how, what were the challenges? And how did we overcome that transition into a code base? And how do we stay motivated within that piece?

Yeah.

Yeah. So to just to give a like a context of where we started, Tableau and Alteryx were our big kind of like platforms or tool sets that we use. And as we know, for from some of us, those aren't really code, code first approaches, and it's like the scrappy startup getting stuff done kind of approach.

I typically try to break things down into five questions. And I want to own two. That's all I just want to share stuff. And the five questions in the world are who, what, where, why, when and how. And I want to own the how and the who. Everyone else can have anything else. They can have the what they can have the the why I like to collaborate when with people but I want to know how I want to control how we do things and who gets to do stuff because I think that's really how you can kind of drive stuff forward. So that was really a good kind of transition and in the thought pattern of getting it in.

So the goal was never like you are now code. Everyone throw your tools away. Everything you do has to jump in there and you better start line by line. Pick off the books off your shelf. Like that wasn't the approach that really wasn't it at all. And from previous experience, doing similar kinds of approaches. I realized to get people on board and really eager and willing. I have to take on a lot of those costs. And I don't mean financially like the cost of building it. So creating really easy to use, use cases, documentations, putting on training, pointing people in the direction of amazing resources, which our community has so much for. So thank you. You've really made my my life and journey so much easier. So that was a really helpful piece.

Benefits of being vulnerable

Being open and transparent and vulnerable myself, I think was really less challenging for people because it's not like, oh my gosh, this person is the world leader in that. How can we ever aspire? That's what it's supposed to look like. But no, I still Google how to do dplyr syntax every day. Like I still do. ggplot is amazing, but I use a SWS to get the code to import it. Like, like, let's be honest, like you don't have to get to the very beginning, like the very end, like that the neural piece, and just getting people to go into it, like write it down, and use it for yourself just to document your thoughts, and getting them to transition. And like, I do not want you to write efficient code. I don't if you're trying to write efficient code today, I'm sorry, you're, you're wasting your time. Get the proof concept out, get those kind of thought patterns and move them along, and really define where certain activities kind of stop.

I do not want you to write efficient code. I don't if you're trying to write efficient code today, I'm sorry, you're, you're wasting your time. Get the proof concept out, get those kind of thought patterns and move them along.

So for people who are like really aligned to business, and they're rarely like domain experts, I'm not interested in those people having to feel that they have to optimize code to be the most efficient to run any platform. What I want them to know is to solve those problems. And then we'll lift and hand that off to another group of people who are really interested in optimization. They're really efficient at that, so that people really understand what their journey can be. And that if they become interested, there is other opportunities elsewhere. So really kind of showing a path of the forest through the trees was that approach.

Making the case for hardware

From a how did we get it in? I just made a business case. And I know, oh, you just make a business case. Yeah, well, I chose to talk about those laptops for a reason. So if you add up all the costs of getting a team $4,000 laptops, you have 15 people, you're talking about a really big machine. Like that's a lot of money, we're talking about $50,000, you can get and we did get a really big server for half that cost. We have like dual processor, 16 cores, terabyte of RAM, eight or 10 terabytes of hard drive space just to explore and do exploration on. That was financially cheaper than saying, hey, that eight gig laptop that you have that everyone has can't store memory. So you should really get them a 64. And that person actually needs 124. So I would like $60,000 in laptops, like it just that was more of a challenge.

So we went a different approach and identified and really did a data driven approach. Like what data sets do people generally use? How big are they? What are the types of questions that people are currently doing? What people want to do? And what can or can we not ask? And some of our like, we don't have the world's largest data, but we consistently work on 50 gig files, and we're working on multiple of them. So we can't even put them in memory to do a summary. So you can start seeing how when you break the problems down into like little kinds of chunks, we can build that case to transition over.

And in the last piece, because I know I always talk too much, is really listening to people like what can't you do? And I think going into that approach, you know, I like to be the Hulk, I'm always angry. And I want to control that anger and use it for good. Is what what is it that you can't do? Because most people want to do their job, and they want to provide value, and they want to be really awesome. So that's holding them back from making that leap in that step. So it's like, Oh, those are your issues. Let me solve those with you. And then you just kind of break it forward. And then lightning in the bottle is now in another bottle.

Breaking down problems and prioritizing work

Hey, Ryan. My name is Javier. Just a quick question for you. I find myself. So there's, you know, Hadley has this principle of three, where it's like, if you find yourself copying and pasting a function or something three times, like, why not spend the time to optimize the code such that it could be three or 300? You know, iterations of the thing you're trying to do?

Yeah, I say two in our company.

Okay. Yeah. So I find myself getting into these traps where like, it takes me more time than I had planned, because I'm trying to work out a function that could then be used for, you know, like future purposes, as opposed to copying something like 10 times, like that would be a lot faster, right? And just changing the inputs, but setting it up nicely so that I could use it. I don't know. Do you have any feedback on that? Because I, I do lose track on like, you know, am I spending too much time on this, you know, per iteration or whatever it is, you know, trying to like, finesse this function?

100%. And like, you're so on point with the realities of a team. And then when you're upscaling, and you're moving, and you're evolving into like that kind of piece, and, and we don't talk about that so much as a community. And I'm so glad that you brought it up, because I experienced that myself. So I, I'm going to literally answer your question, I'm just going to preface it in there, given a little bit of what's going on. That was me, like in 2018. Like, I had, I'd worked in like software companies. So I know what's possible, I helped design them, I helped build them and put that together. I didn't know how to read in a dang file, alone, doing anything else. So we have this, this illusion and image of what code base should be. And that's a really big step. And typically, we educate people to go linearly, right? Like start here and here. And now you're perfect. And now you're awesome. With the assumption that everyone can learn that way. And in your space, and in my space, we're, we're adults, right? We were adult learners. And that's not how we learn.

What I've recently done is kind of break stuff out into like two kind of areas. One was taking something that I heard at a previous job, the TRL, the technology readiness level. I'm only saying that because what it allowed me to do is take that and break it down into little tiny segments of chunks. So the TRL, the technology readiness level is, was built by NASA, I believe, to kind of say how mature is a software product, so that you know, like how long now you can commercialize it, like from working with the government. It was really not awesome for data science and data analytics. So it was missing a whole bunch of pieces. So I kind of like, how does that work for us? Because we were building a startup, we were building software and working with the government, and they use that kind of piece. And it really helped me understand your question. Right? It's like, okay, you start at one and you go to nine. And then there's a bunch of stuff in between. Where at what point would you think that something is like, a product, a software product that's working, you know, it's all functional based, it's calling, there's no hard code kind of stuff. Well, if you think of that as like, seven, eight, nine, like really far down the line, would we assume that it would start at one? Would you start building that function at one?

That's a good point. Yeah, that's a really good way to look at it. Right.

I need to stop doing that, doing that. But then also for the team, I want people to get as close to 100, but never over 80. Because diminishing returns happens in that 80 to 100. And I'm just using loose numbers, right?

So what value does someone early on in their stages of their career have spending multiple extra time to efficiently do something? Then solving new problems. So let's take two roles. So when there's a domain expert, and you pick your domain, like you know so much, but your code, optimization, programming, like that thing is more lower than the video game level, right? You're more in that junior, you're not the expert. And then you have the opposite. You have someone who's like, I can code anything, right? You give me two sticks, and I'll put it together. Couldn't tell you anything about that business. Where do you want to put them? So you want that person to solve the problem and hand it off. And that's how we've organized our team. We've organized our team to be data science, and then data engineering. And for that reason, it's like, we're going to work together into that like, five, six, seven overlap.

So that people are solving problems and handing them off. But there's that transitionary piece over there for a couple reasons. So that the people who take code don't mess up, but also to train back. Hey, we're going to do a code-review course. What are you doing here? Oh, you're doing that. Can I show you how you could do that more optimally next time?

start building our own packages and code bases for our custom pieces, so that it's like you, I want to use this. So I can just put in a couple variables, and I'll do whatever it is I want. It's not coded to a data set or to a value or a thing like super efficiently optimal. But by going through the problems and understanding how often things come up, you really start understanding what you should build. So you're building a bit of a priority matrix or priority process of what you should build.

And either you tackle it as your own side project. Man, I'm going to figure this out. I'm going to separate some time to kind of do it. But it's not going to hinder me from progressing into like my, my job, my project, my like solving the problem. And then when I get to a point, I'm going to work with my my colleagues over here who were like, they're wizards. And they got the magic wand and they can bippity boppity boo and just slam. Oh, it's finished, right.

And then because it's a shared code base environment, we can look at it. And then we put it into like a knowledge sharing documentation in our Git like we're using DevOps just because we're like we're a Microsoft shop. So it's a lot of those learnings, like really investing in data literacy, probably the unsung least sexiest part of this whole domain is like really putting it there so that we can get people further and further and further up that ladder.

And they can make that choice which that they want to jump ladders. And, you know, we have a person, I won't say his name, because it's not on here. And I hadn't asked, but this person started at zero. They're really good at SQL. It's like, yeah, I can, I can pull some stuff out, introduce this person to R in a month, doing a bunch of stuff, giving a few pointers. Now he's publishing apps. Right, like, you can see that going through is like, don't try to write a function, I'm going to get mad. If you try to write a function first, let's walk through and see if it gives you the answer. And then let's start reverse engineering it and like optimizing it.

And then tell me, let's put it in our board, what utilities we should be building to be making that happen. So you're not hard coding anymore. And then that's where that learning is starting to happen and going. But really importantly, giving that space and the opportunity to do it.

Code review practices

I had a little bit because you all started to talk about code review, which is what I was thinking about. I work at the Children's Hospital of Philadelphia. And we really encourage code review early and often. And I think that really just helps build the muscle memory so that we efficient practices just become something that folks do more off. Like, we don't want like it to get too far ahead and then have to refactor a whole bunch of code, because what happens is folks, folks are like too far along and then get too much feedback. And they're like, that's great. I don't have time for it because like they're like ready to move on with the next step. So instead we start we suggest like start early and then like be pairing with the code reviewer kind of through the whole process.

And I think that's really helped both improve the proficiency on the team, but also reduce like this technical debt that kind of grows if it goes too long. So I just want to put that out there for sure.

If I can add something to that, some other pieces that we find helpful is like, if you're using like an issue board or any like a sprint session like Kanban, we also ask people to identify who they want to review so that you're paired up early on when things happen. And we've built a style guide so people know what it looks like. So, okay, I'm about to start doing stuff. This is kind of our standard how we look at things.

And then we put in effort to create a notebook markdown template so that forces people to think through the problems and like put it in together so that they have it. And then it's the starting of a documentation for that code review and then they submit it up. And then so it's like, okay, that that code block. Great. That's, that's actually your function. Like you were doing some exploratory, you're doing some stuff. Now I know the libraries that you want. We can see all those pieces.

And and I agree with you like code review from day one and often and then it starts to just build that muscle memory where people don't need it need to refer back to it. And I've said you don't do it, but they don't need to refer back to it to the same degree.

And Ryan, I see there's also an anonymous question that came in to about this topic. And it was so without functional programming, how do you manage the production code base as they grow?

Get back to like from an object oriented, if that's the way that the people if the people mean that's not necessarily like what we're doing, that would be more in our it kind of space where they're building hardcore applications. Our data products for us are more functionally based because our products align with reports. So like building automation on reports, dashboards, APIs and models. So functional really works in there from an object oriented space. We're not really doing that. And I don't think that there is much of an intention to go that direction. And in our I.T. department actually owns that owns that kind of like application building. So I wish I could answer, but I would be not doing any justice.

Domain knowledge versus coding knowledge

Yeah, sure. So I was just wondering, because you missed going back a couple of minutes now. You talked about like you have, as you called them, the coding wizards that can do anything. But of course, they then you also have the domain knowledge. Of course, like you're going to have different people join at different points. I was wondering, first of all, just a general question. And what do you think is easier to start with? Do you think it's easier to teach some domain knowledge or to teach them the coding?

And then the second part of the question was, if someone's a coding expert, do you make sure that like they're having, I don't know how often you have meetings with the teams, but do you make sure like they're working almost 100% of the time with a domain knowledge expert to ensure that all the data is in the right direction?

You've got some really deep questions there and I love it. So I'm going to tackle your first piece and then I'm going to tackle your second one. From the first piece, I'm going to do the classic, it depends. It totally depends because the type of person, right? So I think we in our, if I can call us sphere, data science sphere, like in our sector, either people pushed it on us or we do it outside. We think unicorns exist and everyone's looking for a data science unicorn. And I love them. I've met two in my life, but I actually don't think they exist. I think unicorns are just on my kids' TV shows and some of his stuffed animals upstairs.

So why I say that, and I like to try to be a little bit funny, whether or not I am, that's different, is a unicorn really is someone who has got all that domain knowledge and all that technical stuff thrown together. And that technical stuff can be multiple technical pieces, right? And then you have communications if you choose to put it in there or not.

So it kind of depends. So why I'm saying that is through some experience, we in previous roles at the city of Toronto, like in our open data team, we were trying to hire unicorns. Who doesn't want a unicorn factory? Like it should just work. But if you look at sports, most of the amazing teams don't have all the best players. They just don't. It takes like a whole kind of well rounded kind of look at it.

So we were striking out on finding some people and it was because we were looking for a unicorn to do a role that didn't require it. So there are different personality types. There are people who are like, I'm not interested. I'm not interested in any of that. So why would we like knock them out?

So it depends. If you are a certain type of personality that is either one side or the other, that's really if we can just say like A or B, really A, business, I guess we should say that B because it starts with business, really B, like a business person and A, more technical. I don't think you can really switch it. It'll be a bit of a tough haul. And even if you force it on, maybe they're not going to be interested and they might now in the great migration, they would be a candidate to leave.

From a technical standpoint, how can you do it? I think it depends on your tech stack and the type of person. So I started to try to learn code 2003 when I went to college and it was VB and it just didn't hit me. It just didn't work. And then I tried to do Python and then I tried to do C. It just didn't work with the style.

So I think it really depends on the technical piece that it is and how you learn. So that's why I say it depends. SQL is what got me into being able to do things through a code-based piece and, believe it or not, MS-DOS and doing bash scripts, just like line by line, kind of do stuff. It got me into that thought pattern. And then with coming into R and the approach of the tidy, it was like, oh, you're thinking of it from a data perspective. It wasn't an easy transition for me. So it depends on what that tech direction, that coding direction is. It's going to be easier or not easier for certain styles of people.

But business is the same thing. If you're not interested in that business, in that domain, I don't think you'll ever teach anybody it. If you're not it. I think how you need to do it is make it interesting analogies to people. That's how the approach is that I've done things.

And then I roll back to some stuff that people have told me over the years, like, explain it like you're talking to your grandmother. My grandmother is 88, and she has no idea what any of this is. I was doing GIS, and my mom and my sister and my grandmother for 100 years said, oh, she's doing GPS stuff. They don't get it. So you need to break it in.

I think with certain languages from a tech coding perspective, it's probably a bit easier to teach elements and levels of that than it is over domain knowledge, because domain knowledge is experience and exposure. And that's time based. So that would be my long winded answer to the first piece.

Yeah, again, it depends. I would say I don't like to force anything on anyone and holding having people hold hands together can be counterproductive at certain points. So for me, having kind of sprints and team sessions is really good. Coder doesn't need to be at a design session. They don't need to be there when they're talking to the business and trying to figure out what it is, what's the story. But in that build, I think it's really good. And this is where we're seeing in data science, almost a new position, the translator, the universal translator between thing is becoming extremely important.

But I don't think that they work in isolation. I really do not think that they work in isolation. I think you understand if that supreme coder wizard that they have an interest in learning the business, then yeah, have them come in. So we hired a person this year, and he's interested in doing that. But let's do baby steps. Let's get that person like understanding our business and how we're doing approaches and then bring them in with good clients with good projects so that it's not like, oh, my gosh, meeting by paralysis.

So I don't think it's an absolute requirement, but I think it is good to have cross pollination because different thought patterns. This diversity, there's diversity of thought, and I think that's a really good approach. And from a business talking to the business, having that approach like I what you're trying to do, we can automate that or we can make it efficient. And having someone who's literally going to do it brings street cred to the whole project and the purpose. Like if you could get that to me, I can shave three weeks off of this project.

So I think there are some business benefits, those domain benefits of having a coder wizard there. But not all the time. I don't think it has to be like a Velcro buddy buddy kind of sitting there together if that helps out.

Code review and team dynamics

Thanks so much. My question is also about collaboration, specifically around code review. So, often, like, especially if somebody is very good at code review, like, they get tagged for each and every time and it stops being kind of the team activity. And it's like, oh, that's a code review person. And so I'm just wondering, like, how do you prioritize, you know, making sure? Well, first of all, do you prioritize making sure that doesn't happen and recognizing that kind of like additional work that folks are doing when they're doing code review and things like that?

Yeah, that's a really hard thing, isn't it? Like, we we tend to think that superstars should be available for everything. And I'm going to approach it maybe a little different than like than you phrased it. Like a superstar, that coding wizard, they're going to be able to review everything. But their time has a different value prop. I'm not saying their individual hour to hour is more valuable, but their output potential in that hour can be so much higher than others.

So how do you use it efficiently? I think it depends on where you are in your organization. And I don't mean positionally. I mean, are you early days? You have three people? Or are you a large team that has a few other things? So if you're early days and you're just starting all people on deck, like, unfortunately, you've got to use the people as you have.

And if that superstar, that wizard has a great personality, the learning opportunity is extremely valuable. So early on days, I think it's hard to prioritize. But as you start getting into pieces, this is where I start leaning back. I'm sorry, I'm not a harper of it, but that TRL, how far along is your product? Like, where is it? Are you starting to get into like beta release? Are you starting to get into like, commercialization? Are you putting it into operations? Yeah, you probably want to have a really good set of eyes there. Or is it the first time that you've built something of that nature? Like, this is your first machine learning model. Like, yeah, you probably want to have it there. So you don't waste a bunch of time to get it there.

So I think there is a little bit of that difference. So as always, classically, it depends. But if I were to summarize, it depends on like, if you have a small team, I don't know if you can really prioritize it too easily. Because I've yet to find an organization like, how many code reviewers do you want on your team? Like, you don't hire just for that, right? There's multiple hats.

So when it's small, we all have to wear a little bit of hats. I think what we do is we prioritize capabilities and like importance. So, you know, if I go back to my early days, when I was learning, like, how do I bring in more than one CSV at the same time? Right? Like, how do I do that? How do I like, get that from like a folder? Probably shouldn't go talk to the lead data scientist to figure that out. Is there somebody else in there that's done at one time, right? Like those kinds of things. So I think it really depends on the level of code in that piece.

That's kind of where I would look at it. And try in your own kind of thought pattern to break out the development cycle into like, kind of groups, and maybe not have people jump more than a few groups at a time. Right? So if you have four levels of group is like, first time thoughts, like, okay, it's in the POC, MVP, and product, your lead person probably doesn't need to code review the design. Or maybe they just kind of review the concept. But like, if that helps, there's no perfect silver bullet, like to do this, unfortunately. But I would say that some people's capability, productivity has more value than others. So you want to use those times accordingly. And, you know, if it's not for production, my mindset goes like, I'm sorry, it's lower down in the priority chain.

Yeah, I think that's really helpful. Like, our team isn't so much like an IME kind of team, that's just not who we are. But my previous place I was at, we were absolutely all over Slack. And there was a lot of that. It's like, hey, this isn't working. Someone just take a peek at it. That's great. I think one of the things I'm sorry, I'm going to do a plug here, like, it's not too much of a slight. We as a society sector, we kind of change the way that we respond in forums.

And how we respond to questions, right? Like, if you are a wizard, you're rare. Like, you're like, you are special. Not everyone's there. So like being able to write things out. So that makes more of that, like iterative kind of step by step process of how you're coding is really going to help people in the long run. And you as a wizard to not waste as much time like answering these types of questions, right?

So if someone's saying, like, how do I do a group by, don't put a whole bunch of other nonsense in there that's not answering their specific question, because on a learning curve, we're trying to solve a single problem that's bugging me today, not, and this goes back into like some of the previous questions, like, how do I not build something that's a piece. So I think we can do a better job documenting answers and responses so that they're more usable and iterative to build, right? So if someone asks, like, an answer for one plus one, don't teach them calculus.

Sorry, Jake, I'm going to just hop in real quick. It's more of a comment and adding on to what Rachel and Brian, your response. Isn't this really about getting people or teaching people to ask better questions and be more thoughtful in what they ask of the world?

Absolutely. I think there's a mix. So there is a little bit of a mix in that because there is elitist syndrome, right? Like there is a piece like I had to struggle. And I started my PhD. And there were so many things like, hey, that's that's the struggle of the PhD. I had to do like, okay, yeah, well, then that mentality leads to do a lot of things in the world that we don't do anymore. But yeah, people need to take some time to check.

You're not the only person to ever ask this question. I'm sorry, there are very few questions in the world that have never been thought of. Right. So to your point, yeah, we have to ask better questions. I think reproducibility and this is like the hot buzzword right in our industry. Being able to put that out so that people can explore into it is really important, but also breaking things down into the appropriate response, right? Not to like flex off and use if we use forms as an example, as a social media post to show how awesome you are at something.

Yeah, it's not the place. It's like a library, you wouldn't write in the back of the library on the card. I read this book in six hours. Well, I read it in three and a half. Like, I don't care. I'm reading the book. It's gonna take me six months because I have other things going on in my life. I don't like that. So when those response rates like, I don't, I think we can do a better job to get everyone up. We want everyone there. That's what we want as a community. We want everyone there solving problems, helping and making the world a better place. And if the cost of the ticket to the party is too much, we're going to exclude people. But yeah, people have to ask better questions.

Getting people excited about open roles

Rachel, that is such an awesome question. And I can imagine I'm not the only person struggling or challenged by that, right? Like, we thankfully live in an awesome sector and time, right? Like, for us as individuals, you know, we've got a bit of that golden ticket. But for, like, building organizations, it's challenging, right? We know of, as you said, those big tech firms, the thought, the stuff that goes through it. And then location has a thing, right? Like, Canada being in the shadow of the United States. Like, there's a little bit of that too, right? Like, the poll.

When I joined Greenshield, I only knew about them because we had healthcare coverage through them before. So I was aware of some of the stuff that they were doing. So some of those other industries, similarly to us, is really lower down. And the pre-notions and preconceptions of what that means, like insurance or banking or retail, like some of those other sectors that, you know, you don't think of startup or Silicon Valley or, like, those kinds of pieces, it's a challenge.

So how do we do it? How have I done it? What are some approaches that we're thinking of? LinkedIn, first off, be shameless. LinkedIn, get as many people as possible. I think being a bit edgy and fun, knowing your audience is a bit different rather than we currently have an opportunity. No, like, people have so much limited time in their day. They want to know what you're really going to be like.