Data Science Hangout | Zac Garland, Mastercard | "Inner Source" to Talk About Open-Source

Welcome, everyone, to the Data Science Hangout. And I know most people who are on today, you've been here before, so you kind of know the drill. But for anyone who's new today, this is an open space for current and aspiring data science leaders to connect and just chat about some of the more human-centric questions around data science leadership, but also to focus on questions that are most important to you all.

So, there's three ways that you can ask questions. You could just jump in live, put questions in the chat, or we also do have a Slido link where you can ask anonymous questions, too. But just a quick note that this session will be recorded and shared up to YouTube, so just want to make you aware of that if you're jumping in live. But again, feel free to ask questions anonymously, too.

I'm so happy to be joined by my co-host for today, Zac Garland, Manager of Econometrics and Data Science at Mastercard. And Zac, I'd love to just have you introduce yourself and maybe share a bit about the work that you're doing on your team today.

Yeah, no, absolutely. Hi, everyone. My name is Zac Garland. I'm part of the Economics Institute at Mastercard. And I think the easiest way to kind of summarize what we do, we like building cool shit. And I'll try to not cuss, but I wanted to make this feel very open. I'm obviously not in a suit or anything special. I'm kind of in what I'm in every day. And so yeah, open questions, feel free to ask anything. Yeah, excited to be here.

Making data interesting and communicating insights

So while we're waiting for a few questions to come in as well, Zac, I think one of the things that was really interesting to me chatting with you this week is really about the ways that you make people interested in data and then the work that you're doing on your team. And I think it'd be cool to just maybe share a few examples of some of the stuff that you're working on.

So I guess there's a lot of broad things that data science covers. I think that we try to figure out how to approach it really holistically. You know, from the point that you pull the data to transforming the data or visualizing it and I guess some simple plots. And then how does that eventually make its way to either a product or an output like a report? So one of the ways that we're constantly communicating is really a public report. And then we have kind of our client presentations or I guess you could say stakeholder presentations where that's really the summarized view.

In general, I mean, I think that we always try to summarize big topics in a way that everyone can consume. And that's my dog, Winston, by the way, for anyone that was curious. Yeah, no, he's the big one homie. But yeah, and I think that we try to find ways to explain it to a sixth grader, right? I think within data science, you can get very, very in the weeds and it's all super exciting for people that understand it. But for someone that's not familiar with data science or how to interpret data, you almost have to find a way to really explain it or find a way to summarize your ideas. And so I think that that's always been kind of a driving factor for us.

And even we have this framework where it's what am I looking at and why does it matter? And it's two very simple questions. But I think it gets to the heart of what you're trying to do, which is show something and then why does that matter?

And even we have this framework where it's what am I looking at and why does it matter? And it's two very simple questions. But I think it gets to the heart of what you're trying to do, which is show something and then why does that matter?

And kind of going on that path as well, I see, Kevin, you just asked a question around the what's your latest fun project that you've worked on?

Yeah, so I would say that it was a very fun project, but it was very, very work intensive. So we're coming out with a small business report and the fun thing, at least from my perspective, I like developing, I like code, and I've been learning JavaScript, trying to find more ways to use it. And so from my perspective, the most exciting or fun thing was I finally found a way to have basically a static rendered R Markdown map show all of these individual city level leaflet maps. And so I'm talking in R, but I think that's probably acceptable here. But it was super fun for me to figure that out and find a way to make it work. And yeah, I think it's a very visually appealing report. And so I think we're releasing it next Tuesday, and I can send out a link to that.

There is just a general MasterCard services.com slash Economics Institute, where you can find like most of our public reports. And so that's a really good place that we kind of see what's accessible or out in the public view. And then outside of that, I would say that we're constantly trying to focus on the business or trying to understand where does this fit in the big picture? How do we provide value to our clients? How do we provide value to our stakeholders?

Open source and the idea of "inner source"

But I know MasterCard being such a huge company, I was curious how you go about like showing the value of open source and explaining to maybe other stakeholders the importance of open source?

Yeah, no, absolutely. So I think when I think about open source, I mean, I'm in love with open source. I think there's a lot of value in sharing code and using code, debugging code, and having that all available. And so I mean, one of the reasons why I'm such a RStudio supporter or advocate is all of the packages were built for some reason, and they all more or less speak together. They talk to each other. They have the ability to integrate functions with one another.

And I think when you start to scratch, which is really what I joined shortly after the group was started, and there wasn't any paved pathway or any determined, this is what we have to do. And so when you start from scratch like that, it offers the ability to really design a full framework or a entire system or entire portal, however you want to kind of describe it. But it makes it interesting when you start doing that to see how much you're leveraging open source, because it's probably a lot.

And that's always been kind of my view that many companies are seeing the end result of open source. But I think the conversation really has started to turn more towards how do we start to be an active member? How do we start to think about what we need to keep very secure and I guess behind some form of authentication? And then how do we also start to generate new ideas with open source? Or how do we start to partner with them to take on a big project? Or if we have an idea, how do we start to think about what can be open source versus what couldn't be?

And I think the easiest intro to that is talking through inner source. So how do we share within the company first? And how do we start to approach, you know, broad frameworks or, you know, building out all of these different components? And so I think the inner source conversation is an easier one to approach or get into. But I think eventually that really transitions into how do we talk about open source? How do we, you know, view open source? And how do we really collaborate and contribute?

That's one of the first times I myself have heard the like inner source and open source conversation and was just curious if others from the group as well have talked about it that way or thought about it that way with leadership.

We've talked about it and implemented certain things, but I like having the term that specifically identifies what you're saying. I'm going to totally take your term. Sure. What is worth is not my term. I don't remember where I read it, but I was like, yes, that's exactly it.

Idea generation and project selection

So basically, my question was just if you could talk a little bit about kind of like the idea generation and idea refinement process to kind of get to things that you actually want your team to work on in the sense that like, I think a common dilemma is that like the I just use business. It's kind of like the non-tech folks, but like the business folks kind of know a lot about their individual problem areas, but don't know about the tech side and the tech side obviously knows the tech side, but not the business side. And so you can get ideas from either or, but like how you go about kind of getting this from the larger number of like potential projects to the ones that like you actually have your team working on.

Yeah, no, I think that that's a great question. I would say that our team is constantly generating ideas. And so I would say that we have a very almost open board when it comes to new ideas or doing new things. And I think we're very quick to drop something that we thought was interesting, but then turns out it would take too much or the data would be too hard to pull, or there's something that causes us to kind of change paths. And then when we find something that's really good, I would say that we invest in it and we double down on it.

And I like that approach because it's almost an open collaboration between teams. Like how do we come up with the best ideas? How do we move on from bad ideas quickly? And then how do we really hone in on what's good? And so I think it works well. The hard part about it is sometimes managing a lot of things going on at once. I think for anyone that codes or is in data science, they know how intense some of the projects can get. And so I think managing expectations and trying to communicate requirements or needs is super important. But generally, if you have good ideas or you can constantly come up with new ones and find a way to really communicate them, it makes for a fun environment.

Can I just ask one quick follow-up to that based on part of what you were saying? I like the idea of being able to pivot quickly and doubling down on the things that are worth doubling down on. Do you ever get pushback when you're dropping some of the stuff that is no longer seen as important? And how do you deal with that?

Yeah. I mean, there's always going to be pushback from some area where there's so many people to please and there's so much that is in the realm of possibilities or opportunities. And I think managing expectations and really just trying to communicate is super, super important. And I think that that's where sometimes you get into trouble is not communicating needs or not finding a way to really communicate so that someone else has understanding. So, I mean, the short answer is there's no perfect solution and there's always going to be someone that wants to go one way and you want the other. But the more that you can kind of be confident in what you're planning to do or want to do and then really just doing it, it makes it a lot easier to kind of come back with, well, we didn't get this done, but here's what we got done.

Do you have any tips on communicating those expectations?

I almost want to say, I'll let you know when I find them. But I would say, you know, really just going back to kind of be, how do we explain this to someone that doesn't understand it? And the best way to do that, in my opinion, is kind of treat it like you're explaining it to a six-year-old. How do you explain the big picture? What's the goal? Why does it matter? What does it require? And not getting too in the weeds of the details, I guess.

I think anytime that you approach data science, you're always going to find people that really don't understand it or don't understand what's involved with the code or how it needs to scale. And so the more that you can kind of bring it to a mutual understanding or common ground, that makes it easier. But it's certainly a topic that I think over time will get better. I think data fluency is something that will improve in the future. I think more and more people will code. I would love to see it. I guess from my perspective, I'm a self-taught coder. And so I think there's so much great material out in open source, whether that's books or videos, webinars, packages. All of it really comes together to create a more open environment where that understanding starts to bridge. But I think we're kind of early in the game. I think that data science is relatively new, even though it's super, super old. But the concept of how much data is becoming available and how much data is being generated really opens up that door for people to start having that conversation.

Frameworks for approaching projects

I got some online certifications in data science. Obviously, I'm not a super big expert in the subject, and I'm willing to learn. I'm currently working as a business intelligence analyst. And I have a question about frameworks that you use when approaching a new topic, from how you manage expectations to how you decide which project, in your words, is good or bad. Do you have specific APIs that you go to measure your new project against? Do you have specific steps that you go from, I don't know, from deciding on whether or not to take it on to measuring which model is best to use to maybe setting adoption targets and making sure that the data is validated and the users are using it? So any tips that you can give regarding that?

Yeah, no, I think that that's a great question. And so I guess the way that I've approached projects has always been, and not always. I wish that I had approached projects, you know, always this way. But I always start with a package. And the first package that I started at the Economics Institute was this package called EI Tools. And it's a conglomerate of many things in the tidyverse or in use this, for anyone that's familiar with that. But I always start with a package. So anytime I have a new idea, I build out, you know, a simple package and then store it, you know, everything that's related to that inside of that package. And I think what that offers the opportunity to do is to really have organization around all the things going on. So if an idea gets dropped, it's not a big deal. It's still there.

But at least it's getting to the right framework or starting to be in the right form before you really pursue something. And so I guess by way of example, when I was getting started, I built out this big application and it had a ton of functionality. And it was more or less just me learning. But I didn't build it in a package, you know, files were hard referenced. And there was just a million things that, you know, could have been improved if I had come up with kind of that initial package structure. And so I think the more that you kind of dive into projects, you start to kind of find a flow. And I think the package structure really works well for me.

And I would say it's not an easy thing to get through. None of it's easy. And it all takes a lot of time and learning, you know, trying, failing, all things that I've done. And so, yeah, I would say as long as you have kind of a positive mindset about it and try to get things organized, the better off you'll be. And then in terms of, you know, model performance and how to think about all that, I think it's such a big topic that there's no perfect answer. I think the more that you can focus on kind of the end output or what the value is of what you're trying to do, the better. And then the rest of it is kind of just details.

Learning strategies and resources

But one of the things that I know I personally struggle with is every time I pick up a new resource or any kind of training, I'm finding things that I feel like I should have known early on or, you know, blind spots in my knowledge. Do you have any strategies for kind of proactively seeking those out?

Yeah, so, you know, I think it's a very individual question where I think there's plenty of ways that people can learn. For me, I love books and I have too many that I haven't read, too many that I buy and I'm like, I'm gonna read it and then I just don't. But what I like about books is if you start from the very top and you finish it, you have so much knowledge that that author had. And so a great example is just the data science for our book. And it took me a long time to really get through the entire book, go through all the exercises and to really understand the concepts. But once I felt like I had really mastered all the concepts or really read through all the chapters, I felt like I had almost a framework.

And same thing with the R Packages book or, you know, the Mastering Chinese book. And there's actually this book that's called The Big Book of R. And it's basically just links to books on different topics or different ideas, different approaches or things that you could learn. And so I always think that that's a really great reference. Videos are super helpful, at least for me. But I mean, anything, you know, training courses or, you know, in-person meetups or, and I know we're kind of still in COVID, so maybe not in-person meetups, but things like this, you know, how do you think about new ideas or get someone else to share ideas on code or data science, modeling, you know, all of these different things that are available.

So, yeah, I would say that the fear of not knowing what you should have known, that's always present. Like, I know that there's a million things I don't know. But I do know that there's ways to find it or to learn it. And so as long as you kind of have a learning mindset, then, you know, it's always the best place to start.

Communicating results and technology choices

And the first one was, how do you communicate your results? Do you use the open source solution, enterprise, cloud or something else?

Yeah, so I think that that's a great, a great question. So I think when you're developing on your own, you have open source to leverage and really constantly evolving technology. And I think when you're in a company, the thing that I didn't understand before was really, you know, there are predetermined systems or predetermined technology solutions that you kind of have to start with where, you know, even if there's a better solution out there, what's available is kind of what you get. And so I think there's almost this balance between what do we have access to today and what do we really want to have access to tomorrow? And how do we start to communicate where these different technologies come into place or what that would enable you to do?

And I actually, I saw this PDF where it went over the data landscape or all of the different technologies that are going on in the world. And there's so much. And so I think opportunity is there. And you just have to find out how do we kind of handpick what's really going to work for our group or for the company? And then how do we start to kind of pursue it?

Following up on that question, I guess, if you like find a technology that you want to pursue, what does that process look like for you or what tips you have for someone who's trying to do that?

Yeah, absolutely. So I think that really gets to communicating with stakeholders, right? So finding some way to use what you have access to today to provide value and then coming back and saying, I know that you love this, but here's what we could do with this. And I think it's really finding ways to produce something that people really understand and view as valuable and then showing them how they, that new technologies or additional systems could really enhance that or improve it, scale it, and just showing them kind of what that next step might look like. But really just opening up the conversation, finding ways to ask questions or to say, here's something that I think would be super valuable. How should we approach that?

Measuring success in data science

The question is, what are metrics that Mastercard uses to measure success or impact?

I think that's a great question. It's something that I think about often. I don't know that we have a perfect solution for that. You know, I think if you are generating revenue, that's a super simple way to, you know, kind of measure success. Our group currently, you know, we are pursuing that, but when we got started, you know, that wasn't part of what we were doing. And so I think that that's really when it starts to get down to, you know, how much are we communicating with clients? How much are we communicating with stakeholders? Are we helping them to do their jobs better or to have a better understanding of, you know, data or the macro view? And, you know, are we really enabling them to do better? And so I think there's plenty of opportunities to kind of measure or to try and figure out, you know, how do we view this as valuable?

But I think those are kind of the two avenues that I would kind of identify. I know one of the examples you had shared with me was on, like, travel and sharing some of those insights. I guess taking that, like, success question a bit further, like, how would you measure success for that project?

Yeah, so I think very early on, we kind of identified core themes. And so we started with this idea of, you know, how do we come up with, you know, six or seven themes that broadly we want to cover or that we want to have a view on? And then how do we constantly kind of enhance it? So if you were to look at our first projects or our first, you know, dashboards or reports, we took a view or tried to come up with a view, and then we constantly just made it better. So I don't know that we had any measure of success other than, you know, people telling us that they liked it, they valued it, you know, they appreciated it. But in terms of kind of measuring how well we're doing, I think it's certainly an area that we could probably do some more exploring or thinking through.

Leveraging team skills regardless of technology

A lot of the discussion earlier was around, like, you know, kind of coding and things of that nature. How do you, I guess, how do you ensure that, like, your team is all kind of using, is up to date, basically, like, you know, a lot of people have different varying levels of skill with regard to coding or data science. How do you guys kind of make sure that people are kind of in sync?

Yeah, no, I think that that's a great question. And even for, you know, data scientists, so, like, for me, I'm very code first. But a lot of people that we work with or that are part of our group, they work within Tableau. And so even with Tableau, you know, the funny thing about it is there's, and I'm probably kind of getting sidetracked with a different, maybe I'll mention that after, but there's no easy way to make sure that everyone's on the same page or has the same code or has the same understanding of code. What's worked for us is trying to figure out, you know, how do we leverage each other's skills, regardless of technologies. And, you know, a great example is really Tableau. So the economists will come up with these great views or these great dashboards, and then I can take those and make them into code or find ways to visualize them differently, put them into a public report. And so I think it's really just gets down to communication, having an understanding of skills, and then trying, you know, along the way to teach each other and to learn.

And so I guess the side portion that I was going to go off into was, under the hood, Tableau is XML. And so for a coder, like, I love trying to parse all of it and trying to understand, like, what can I pull out of this? Or, you know, how do I pull this color palette or things that are kind of more nerdy? But it's, you know, finding ways to do what you love, even though it might not be with the tool you love or the technology, you know, it's always kind of the path that I've taken.

Benefits of code-based data science

Expanding on that a bit further, I see there was an anonymous question that says, what are your thoughts on the no-code movement and AutoML?

Yeah, so I think at the end of the day, there is value in no-code and people that don't code. I guess from my perspective, the reason why I love coding is it offers unlimited possibilities. So I think the main difference for me has always been, if this solution doesn't do what I want it to do, is there any way that I can fix that? Or am I kind of set with what is available? And so for me, I love developing new things or trying to generate, you know, different ways that we can do something. And so that flexibility for me has always been super important. But that being said, you know, there's a lot of value. Like, I always go to Tableau as a great example, because dragging and dropping and creating beautiful visualizations or decks, dashboards is super, super valuable. And, yeah, you know, I think both are super valuable. I've just always been very code-first because I like developing and, yeah.

I guess from my perspective, the reason why I love coding is it offers unlimited possibilities. So I think the main difference for me has always been, if this solution doesn't do what I want it to do, is there any way that I can fix that? Or am I kind of set with what is available?

One other anonymous question that came in was, how do you balance your passion and personal interests and business requirements when it comes to adopting tools and projects?

Yeah, you know, I think that that's another great question. It's not always easy. And, you know, you always have to find ways to have some level of balance between both. And a good example is, so when I first started, we had, you know, we had to really come up with a business plan and a way to communicate that. And we wanted to do something kind of crazy or off the wall. And so we used Prezi. And it was a great, you know, it was a great presentation. It was very fun. It was very interactive. And then eventually I coded, you know, an HTML presentation. But I think there's always a balance of, you know, figuring out, like, what do we really need? And is this the right solution? And then at some point, the hope is always that you can really, really leverage your skills because you're starting to produce, you know, things that always can answer questions or can always satisfy some need. But that certainly takes time. And it certainly doesn't happen, you know, overnight. But the more that you have kind of your passion and your work, the better. And so I think the more that you kind of push that agenda or trying to find ways to do what you love, the better off you are.

The Economics Institute at Mastercard

Your answer and just mentioning, like, presenting the business case is making me think of something I had meant to ask earlier as well, but around the Economics Institute in general. Could you explain a bit more about what that is and how it serves as an innovation lab?

Yeah, absolutely. So we're really a group of, you know, economists and data scientists. And our job is to really come up with great stories and great insights. And, you know, I think that we've always taken the view of trying to view things differently, trying to find the hidden story or the thing that no one else, you know, is looking at. And I think that when we look at the group as a whole, what we're really talented at is constantly being in communication with, you know, clients, stakeholders, really understanding what challenges or things that they're going through, and then finding ways to really explain what's going on. How do they think about that? How do they view it or come up with new ways to approach it? And so I think, you know, the group as a whole is made up of a lot of very curious and hardworking individuals. And I think that that's really created kind of an environment where, you know, we're constantly just trying to find cool things to show or communicate. And then, you know, how do we help people to do what they do better?

But when you say, like, do really cool things or show cool things with data, what are some of the most interesting insights that you've gotten so far for projects you've worked on at MasterCard?

I would say it's, for the most part, it's all pretty interesting. Sometimes, you know, as a data scientist, it's hard to keep up with what all of the different views are or all of the interesting insights that the group generates as a whole. I would say for me, I've always enjoyed, you know, really finding ways to visualize things. So right now I'm trying to learn D3 because I just find it so cool. And it's super difficult. And it's not, you know, it's not coming easy. But, you know, I think even within Tableau, you know, we have an economist, I always look at her dashboards and I'm like, wow, this is like, this is so cool. And, you know, I think it's really just trying to find things that are interesting and that you would enjoy or that you find cool and then, you know, communicating it.

I would say the small business report, there's things I find super cool in that. There within the travel report, you know, there are things that I found super cool in that. But, yeah, I don't know. It's probably an answer. There's so many things that are fun or cool to look at. It's probably hard to kind of pick one.

Yeah, so, you know, I think when you look at our public reports and even just, you know, I can openly talk about kind of what's under the hood. So, our public reports, for the most part, have always been built with our markdown. And I think that we try to push it to the limits of what that can do. But generally, it's a very easy framework to use. You can constantly improve it. And so, I think there's always this element of what it started with was really, you know, analytics stuff, right? Where it's very analytics heavy. There's a very, you know, kind of standard view of color where we started to transition to more elegance and design. How do we create something that people are going to find visually appealing? And so, I think that that's probably like my side gig is, you know, design. I enjoy it. And I think that, you know, we bring in a lot of visualizations that weren't built before. So, things like video or pictures or, you know, graphics that are animated. And so, I think it's just finding cool ways to show what you're trying to think through or trying to communicate. But I certainly kind of love when my graphics make the end cut as well.

Hiring for specific skills and writing job descriptions

So in Rachel's blurb about you before the meeting, she said you're going to talk a little bit about writing a job description for tidy model engineers. I'd love to hear about it. I hate writing job descriptions and I'm writing some right now.

Yeah, no. So I think even with, you know, the way that we approach titles or what we're trying to what we're trying to look for, it's very much an experiment. I think the main driving factor of that was we wanted something different that really relate to the R community. I think a lot of our code is in R currently and we're constantly trying to find ways to increase that portion of the business. So I think the main driving factor of that role is just that we wanted someone that felt that they were really talented with a specific skill to apply and to be found. I think that that's always something that you find with data science, right? You post a data science role and that could mean a billion things. And that's what's always difficult about data sciences. It covers so much that if you don't be, or if you can't find a way, that was bad English. If you can't find a way to be really specific about what you're looking for, you're probably just going to attract a lot of people, but not as many people that are focused on what you're focused on or trying to accomplish.

R vs. Python and multi-language teams

I'm curious because I've been a part of the data science community for a long time, but I've been a part of this wonderful little meetup for some time now, and we talk a lot about like Python and R, and those are generally our data science tools. But I'm curious, and this also could be for you, Zach, or for anybody else, is what are people's thoughts on limiting or minimizing use of both languages? So let's say you minimize Python and minimize R and just try to consolidate the team on one. My personal opinion is that there's technical debt that accrues as more languages you apply, because people obviously are comfortable in one or the other, but I'd love to hear what other people's thoughts are on that.

Yeah, so I would be curious to hear everyone's thoughts as well, and maybe I'll just kind of quickly, I think it's a great question, and I'd agree that there's some level of the more technologies that you use or the more factors that you have in what makes up a data science team. Sometimes it could be hard, but I also have the sense that there's a lot of value in both or multiple, and the more that you can find ways to leverage it, the better. But I think it's just a great question, so I'd be curious if anyone wants to weigh in as well.

Hi, I'm Brian Butler. I manage the small data science team at Bennekin. I am a fan of both. In fact, my junior data scientist, before he was started with me, he was mostly R, and then he converted all to Python, and now he's doing all Python. But I'm like, these are tools. I think about a carpenter. How many nail guns do they have? How many different saws do they have? It's the same thing. If I want to bang out a quick analysis, I'm going to do it in R. I can load the data in, I can write two lines of code, and I've got a ggplot that's interactive and everything else, and boom, I can solve that question pretty easily. Now, at the same time as if I'm going to do some serious natural language processing or some deep learning, I'm going to switch gears. But the best part of it is what I like doing is wrapping Python into R Markdown and presenting through these interactive apps that you can use with Plotly and R and everything else, and then you wrap the base model of Python around it. And so I just think you're not going to be skilled at every tool you use, but the more tools you have, you'll be more effective because you'll find the right one for the right job.

My name is Floris Vos, I'm from the Netherlands. Actually, first time I joined this group. But I think it's a great question, and actually the same applies for packages within R, because you have so many packages. You could create a package, but you don't want to have too many packages, and you don't want to have too many packages. Because you have so many packages, you could restrict yourself to all kinds of packages. Actually, I just heard dplyr, I'm very much in front of data table, to be honest, but I use them both, and I see that both deliver a lot of value. For us, how we use it is we just have good documentation, how to use the packages, how to do your coding, so we can always take over work from each other. I think the same applies for using Python R, but even Julia or Go, if you add it to your markdown, can be used as long as you just document it well.

Yeah, I think that documentation and having an understanding of how to use something is always something that's worth solving for. Yeah, I really like that answer, because I would love to go into an R markdown and see like 20 different languages and find ways to get value out of all of them. That'd just be kind of fun.

Yeah, just one addition, for the whole documentation, we use actually the bookdown. Actually, the bookdown, I think it's also from... I never can pronounce his name, to be honest, but it's amazing. So we have many of those bookdowns where you just say, well, like Hadley Accurate is the R for data science. It's really great to do your documentation for your whole team, and we publish it on a web server. Easy to search for all your style guides for everything you have. Yeah, that's amazing.

I would also echo the sentiment of using lots of different tools. And I'm just teaching a data science full three-month boot camp kind of course at the moment, and we just wrapped up a lot of what's going to be R, and we're going to move on to Python next week. And I told the students right from the outset that we're going to be using both R and Python. And I try to always highlight why we're doing this in R. All the statistics was in R. Data viz was all in R. Data munging was all in R. Reporting was all in R. And when we move on to Python, we'll be doing the deep learning and machine learning, things like that, inside of Python. But I'm not going to make them do statistics in Python. I don't think it's worthwhile. And I don't think it's nice to do data munging in Python either. So they have nice tools to do that also in R. So I'll show them some of it, but they're not going to be at the same level in all skills in both of them. So I like the idea of use the tools that you got and use the diversity that you got. Instead of trying to do an us versus them, no, we've got to do everything in this package or everything in this language. And everybody on that side is wrong kind of sentiment, I think, is something that I don't try to reflect in my work and give to my students either.

So I like that idea of kind of using all the resources you have available to you. But when I talk to people on the ground who are not just training, but actually working in companies and consulting, they say, well, actually, what really happens is that you can use R, but the IT department is not going to support you in anything. But if you use Python, at least they'll take a look at your scripts and they make you some critique and try and help you understand what's going wrong. So the support that they get from other departments of the company also determines what they're actually going to use in the end. So there's that Paco component that is not as idealistic, I think.

No, I think that that's that's accurate. I think at the end of the day, that that kind of gets back to sometimes you have systems and that's what you got to use, even if there's a better solution. And so I think that's always, you know, on the table or part of it. And I think the only way that you can get kind of people to convert or to see your side of it is just to create something cool. I think at least that's worked for me is if you can show someone something cool, then it's it's kind of easier to say, yeah, this is why I use this or yeah. And so I guess like that's the it's always part of the game. And I find that the more you can make it fun or interesting is always the easiest way to turn.

I think at least that's worked for me is if you can show someone something cool, then it's it's kind of easier to say, yeah, this is why I use this or yeah. And so I guess like that's the it's always part of the game. And I find that the more you can make it fun or interesting is always the easiest way to turn.

So the and this is great. So I don't disagree with everybody. I think that obviously all of these tools have a place in everything. So sometimes Python, especially from a data engineering perspective, can be a little bit Python, especially from a data engineering perspective. That's what people are using for for ingestion for ETL. And so it's really helpful to have that tool set. And generally, you'll always have that tool set. And for our first variety of purposes, what's interesting