How Can Data Teams Get Out of Their Own Way (Alex Gold) - KNN Ep. 196

Speaker A: My first actual data science job was literally the result of waking up from a dream.

Speaker B: How does that lead you to where you are now?

Speaker A: I had an experience that I think a lot of data scientists have, which is getting sort of inexorably dragged down the stack. What I wanted to do was do all this cool data science that would, like, make a difference, but what it kept turning out I had to do was make the data better.

Speaker B: Are there any key factors for improving voter turnout?

Speaker A: Turns out that working for political campaigns is, like, really exhausting because everything is on fire all the time.

Speaker B: It's an interesting data problem.

Speaker A: How do you fund open source software? And there have been a lot of different models to try and fund open source software, and the reality is, unfortunately, that most of them kind of suck.

Speaker B: What do you think the state of the language war is now?

Speaker A: I don't understand why people, like, put up with jupyter notebooks like, y' all can have nice things too.

Speaker B: Hello and welcome to another episode of Ken's Nearest Neighbors, the podcast where I bring in fascinating people from my world, talk about life, data, science, sports analytics, content creation, and much, much more. I'm your host, Ken G. If you haven't already, we'd greatly appreciate it if you gave us a rating and followed the show. It helps us to continue to bring in incredible guests. This episode of Ken's Nearest Neighbors is powered By Z by HP, HP's High Compute Workstation grade line of products and solutions. Today, I, uh, had the pleasure of interviewing Alex Gold. So, Alex recently published the book DevOps for Data Science, and in this episode we're going to dive into a little bit of what DevOps is, what it isn't, and how it might be different from mlops, which we've talked at length about on the podcast. Alex also has had a very interesting career. He's currently the director of solutions engineering at Posit, and we're going to ask some questions about what solution engineering is, who might be a good fit for those types of roles, and what opportunities are available there. We'll also dive into some of the details on the language wars. Obviously, uh, Alex works at Posit, so he has a little bit of a strong take on the R versus Python debate. I really enjoyed this conversation with Alex, and I'm sure you will as well. Alex, welcome to the Ken's Nearest Neighbors podcast. Thank you so much for coming on.

Speaker A: It's great to be here. Thanks for, uh. Thanks for having me.

Speaker B: Of course. Well, we met through some mutual friends at Posit. Yeah, obviously, I'VE worked with them a lot. Well, you guys a lot in the past and you have a book coming out. I wanted to learn a little bit more. One about your story and two, a little bit more about uh, the overarching process and your book in general. So uh, I'd love. Before we get into all of those wonderful things, I'd love to first start with a little bit of background on yourself. Yeah, maybe let's dive into where you first got interested in data.

Speaker A: Sounds great. Yeah. So my background, my undergrad was in uh, in math and econ. I went to Wesley University. They don't have minors. At least they didn't at the time. So there was this funny. Like it was not quite a double major, but it was like a major and a minor in math and econ and math, that order. Uh, that was one thing. Maybe it's still there. I don't know if there are Wesley people listening. I'd be curious to know if it's still a thing. But um, uh, so that's what I, what I did. And the thing I thought was really cool about economics and the reason I like really loved it is that it was numbers, it was math, but it was about the real world. Right. It was not just sort of math for its own sake. It was really, um, you know, related to things that people care about, uh, in their, in their day to day life lives. And so I spent the first few years of my career, um, working in sort of the economic policy world, um, in Washington D.C. i worked at a couple different, different think tanks and found myself, you know, I did some data related stuff, some just like general, you know, qualitative policy work. Found myself enjoying the data part much more. And then, uh, and then you know, a few years down the road I uh, started an econ PhD program and dropped out. Um, and then uh, a few years later ended up going sort of all the way into uh, into the data world. And um, you know, it was really more of the same. It was, right, it was numbers, it was math, it was uh, statistics, but it was about the real world. And um, that was, that was what was so, so interesting to me, right as I got to do these like, sort of. I think a lot of us who love data, right, we love like the puzzle aspect of it. You write the code, you get the, the data is shaped right? And then you make that visualization or you build that model. Um, but I also really like that it was actually related to the real world and not just sort of, you know, math for, for its own sake.

Speaker B: We had a very similar experience there. I mean, in college, I remember taking my first econ course, and I was honestly a very bad student until that point. And it all just sort of made sense. I realized that I could see the world through trends, through graphs, and I could start to understand it in a very different way. And that was something that really spoke to me and it opened the door to saying, hey, if this is useful to understand trends in human behavior, can I use it to understand my golf game better? Can I use it to understand all these different things? And I remember how powerful that was. That sort of opened my, my mind up to the possibilities of math or statistics being an applied thing rather than just a theoretical thing, which was super, super cool.

Speaker A: Yeah, absolutely. And I think what's really interesting about data science as a field is that I think that's the story of a lot of us who are in data science or who got into data science. I mean, these days there are a lot of data science programs, which I think is awesome. Like the, you know, now you can get a bachelor's or a master's. I don't even know. There may even be doctorate programs in data science per se. But, you know, when, when I was, was in school, that, that didn't exist. And so everybody who sort of ended up in data science was coming from somewhere else. And, uh, that's something that I think is really cool about this field is, is just how it sort of is this, this marriage of a lot of really, um, you know, interesting statistics, machine learning, computer science kind of stuff. And, and then like, what can you do with this in the real world? Um, so, yeah, that totally resonates for me.

Speaker B: Amazing. Well, so you talked about how you're doing some of these think tanks you're working in policy in D.C. you're working in, and dropped out of your Ph.D. program. How does that lead you to where you are now?

Speaker A: Yeah, yeah. So there's another hop after that. So my sort of policy world led me, um, into data science. And my first data science job was a political job, um, doing work on political campaigns. So that was sort of like a little hop into, into data science. Um, then I had another role after that in data science. More, more like generic data science. I was working for a big consulting firm, um, did some work with hospital systems, did some work with the Social Security Administration, um, and that was, you know, sort of general data science. I ended up leading a team in that role. Um, and then from there I, you know, I had obviously been spending A lot of time using R. Getting excited about the power of programming for data science, right? Not just the um, not just the model building or the dashboarding or the visualizations, uh, but I had an experience that I think a lot of people, a lot of data scientists have which is uh, getting sort of inexorably dragged down the stack that what I wanted to do was do all this cool data science that would make a difference. Uh, but what it kept turning out I had to do was make the data better. Then eventually you end up managing a database. And at some point I found myself managing an RStudio server because somebody needed to do it. And so what I found was I actually kind of enjoyed that part of it. I enjoyed learning about how to administer a Linux server. I enjoyed learning about how database administration worked. Although I learned this, this much about that topic. Then what happened honestly is I got uh, connected to some folks at then rstudio now Posit, um, and learned uh, a little bit about solutions engineering uh, and made the hop over to then rstudio uh about five and a half years ago and so spent uh, about a year and a half being a solutions engineer and happy to talk more about what that means but it's uh, uh, sort of this, this interesting spot about helping our Posit customers have a great time using the Posit product. Right? How do you, how do you make sure that, that the um, the environments that data scientists have to work in are great environments to do, to do data science. And so uh, really enjoyed that. And then you know I've been a manager, I really enjoyed being a manager and when um, managerial roles opened up I moved back into management um, and have sort of taken on successively um, bigger management roles. And so now I posit, I lead the solutions engineering and the technical support teams um, which is really, really a blast. Um, so yeah it's, it's one of those stories that I remember, you know, when I was, whatever I was 23, 24 in my, in my first job, somebody telling me that like careers make no sense lived forward but the story makes a lot of sense told backwards. And I really feel saying this out loud that really resonates for me that like oh, that story makes a lot of sense when I tell it this way but at the time it made no sense whatsoever. Uh, I'll just share like my, my first actual data science job was literally the result of waking up from a dream that I had. I like woke up, I had a dream that I was going to work for at the. It was 2015, uh, fall of 2015, I was like, oh, I'm going to go I a dream that I was working for the Hillary campaign. I was like, okay, I'm going to go do political data science stuff. And that was just a complete. It was a great left turn, but it was a total left turn for my career and it was literally the result.

Speaker B: A little left random dream.

Speaker A: I just like woke up. Oh, what if I actually did that?

Speaker B: That's fascinating. You know, the more uh, people I talk to on the podcast, the more that, that really hits home, uh, including in my life. I mean nothing really makes sense until afterwards when you look back at it and you put it all together and going through it, we're all kind of just fumbling through the dark and trying to figure it all out. Before I dive into the solutions engineering stuff, I'd love to learn more about what you were doing in policy and those types of things. I think that it uh, is election season right now and I don't particularly want to get into any politics, but I'm interested in the data surrounding the politics and what goes into, to those types of things that uh, maybe the traditional, the layman isn't familiar with.

Speaker A: Yeah. So I worked in both policy and politics, which from like, if you're outside of it, you're like those are the same thing. Right. But like fundamentally they are quite different. Right. Policy is about what is the government going to do for people or not do. Right. And then politics is about who wins elections. And so while they are related, obviously you only get to do policy if you win elections. If you know, if you're on one side or the other, um, the sort of practice of it is completely different. So as in the policy world, I did some data work for example, where um, we were using some longitudinal surveys of um, basically the economic success achieved by children. And so we were trying to do this like very complex modeling. Um, if anybody's familiar with the National Longitudinal Survey of Youth, the NLSY surveys, these are, these are what we used and we built this model that could, um, at least in theory, synthetic. We created the synthetic data set of people from age 0 to 40. Now there's no actual data set that follows people from 0 to 40. And so we took these several different data sets and stitched them together, um, with, with a variety of different sort of like matching, statistical matching techniques, um, and uh, other other kinds of, um, inference techniques. Um, for what it's worth, I did this all in Stata, which was a real. I know there are people out there who think like, R is a difficult language to work with, you should go have some fun with Stata. That's a bear. Um, so that was what I did on the policy side. So that was really interesting. They're interesting statistical problems. Um, for the most part, a lot of data on the policy side is smallish data problems. Right? They're longitudinal surveys which are very expensive to collect. Occasionally you do get larger data sets, like in, in some later stuff. I worked with, um, hospital claim data, which is not huge, but it's large. Right? You have like one line of data per every single, um, you know, procedure that happens in a hospital. So you have, you know, millions of rows. You're still in sort of modest sized data there. In, in politics there are a variety of different sources of data. Um, one of the biggest ones is something called the voter file, um, which people, uh, who are not in the political world might be sort of horrified to know exists. But it's just a, it's a standard thing. Each secretary of state for every state keeps a voter file, which is a list of all the people who are registered voters in that, in that state, um, and when they have voted. So like as, as we like to say to people, uh, who you vote for is private, but whether you voted is a matter of public record. And so, uh, a lot of, a lot of data, there's a lot of work in politics done off of these voter files. My understanding is that like, also a lot of commercial data stuff like starts at the voter file in a lot of cases. Um, and so, uh, uh, this, these, these data files are compiled by state secretaries of state. There are then companies that go around and gather the data from all 50 states because actually it's like a pain in the ass to homogenize 50 different state voter files. Um, and so we were doing a lot of work, uh, the role I was in, we were doing voter outreach experiments. And so we were looking at things like does this message or that message make people make people more likely to go out to vote? Um, and so the kind of things we would do is before the election we would take the voter file, we would randomize it, and like, some people would get this piece of mail, some people would get that piece of mail, some people would get nothing or this text or that text. And then after the election, we would gather back up the voter files and see who voted and who didn't. And so they were literal, like field experiments, um, on, on voter outreach. Uh, this is sort of the gold standard, obviously, because it's an actual randomized controlled trial. Um, but there's just a ton of data stuff going on in politics these days.

Speaker B: Oh, uh, that's fascinating. I mean that makes a ton of sense to me. You think about a lot of the campaigns that are on about getting people to vote rather than. Ah. I would imagine it's a lot easier to get someone to vote from who's aligned with a specific party than to convert someone to vote for a different candidate. And it's an interesting data problem of, hey, let's invest money in just finding people and getting them to vote versus trying to change opinion. Which is maybe a little bit sad. I think like the idea of having a message that you believe is important and like winning people over with that is. Yeah, is important. But if we think about like effectiveness, there's another side to that as well.

Speaker A: It's a great, it's a great point. And like when you're thinking about what you're. If, if you're aligned, right? Like the organization I worked for was aligned firmly with progressive causes and candidates. And so like, if you're, if that's the side you're on, right, what you're trying to do is you are trying to increase the vote margin for progressive candidates. And there are basically like, uh, three things you could do. You can make people who were going to vote for a Republican vote for a Democrat instead. You can make more Democrats or people who are going to vote for Democrats at least, because very few people actually, actually register these days. They, they say they're independents, but almost nobody's actually independent. Um, and so they, you take people who, you, who are going to vote Democratic and you get them to come out or you get the Republicans to stay home, right? Those are like, those are the three things you can do. Um, the third one of those is, is a little distasteful I think. Like you're know, it's, it's, it's sort of some, some dark side stuff there. Um, but, but those are kind of the three options you have. And, and there, there is a really active, um, I think debate honestly going on about whether persuasion, which is getting people to go to the other side or straight turnout stuff is, is more, um, more useful. It definitely varies election by election. The other thing that's really interesting is obviously you can do a lot more in a smaller election, right? So like, if you're talking about in 2015, 2016, obviously it was Hillary Trump was the, the election. And like most people knew a lot about that election and there really is only so much you can do to affect that. Uh, you know, they're on the news constantly, there's a ton of earned media and so any paid, any new right, like do you actually think one mailer is going to change people's minds on whether they're going to go vote for Hillary or Trump? Like probably not. But when you're talking about down ballot races, when you're talking about a state senate race or ah, you know, the district attorney in Chicago, those are races actually where this kind of paid media can have a much bigger effect because people aren't paying as close attention, their minds aren't made up ahead of time, um, they're more persuadable and they might not be planning to vote at all unless they learn something about the candidates or are, you know, sort of incentivized, uh, to come out for it.

Speaker B: This episode of Cancer's Neighbors is brought to you By Z by HP, HP's High Compute Workstation grade line of products and solutions. Z is specifically made for high performance data science solutions and I personally use the ZBook studio and the Z8 workstation. I really love that the Z workstations can come standard with Linux or WSL2 and they can be configured with the Data Science software Stack manager. With the Software Stack Manager you can get right to the work of doing data science on day one without the overhead of having to completely reconfigure your new machine. Now back to our show. So uh, this might be impossible to answer question and it might be highly variable depending where you are, markets, whatever it is, but are there any key factors for improving voter turnout that are you just like. Yeah, like hugely correlated with improving or. Uh. Yeah, yeah, I'm interested in maybe what some of the nuts.

Speaker A: Yeah, so one of the, there is this, this line of research um, called social pressure, which basically is like we are, we as humans are very susceptible to what other people are doing. And so, and again I, I kind of got out of this world in 2016 so that this was the state of the art in like 2016, which is now quite old. But at least at that point people this had sort of been fully internalized but like everybody was using these sort of social pressure techniques which basically are like every, you know, three out of four of your neighbors voted in this last election. Are you gonna vote in this election? Um, and it's sort of this, this sense that like everybody is voting, it is your civic duty, you should go out and vote and that, that uh, at least among any of the sort of get out and vote messages that, that people tried to, um, um, that one is, is a real, A real winner. Um, you know, showing people's, you know, like, showing your voter record versus your neighbors and like, your neighbors are more consistent voters. You should probably get out there and vote. People, People respond pretty, pretty strongly to that one.

Speaker B: That's very cool. And that's honestly, like, probably a more ethical one.

Speaker A: Yeah, that sounds pretty good to me.

Speaker B: Right?

Speaker A: Like, yeah, you should go out and vote. Uh, even. Even as somebody who has pretty strong preferences about who people vote for, like, you should go out and vote. It's, It's a good thing. It's part of your, part of your civic duty. Uh, and voting rates in this country are depressingly low. Uh, you know, turnout even in, in big elections is 60, 70%.

Speaker B: Uh, are they trending a specific direction or they.

Speaker A: I'm not aware of, of that. Um, honestly, you know, I, I was very enmeshed in this through, you know, the winter of 2016, and then kind of decided that was, that was a good. It was, it was a great period of my career. I learned a ton about data science. Uh, it turns out that working for political campaigns is, like, really exhausting because everything is on fire all the time. And I was very happy to move on from. I'm really glad I did it, but I was also very happy to, like, move on out of that world also. The reality for me at least, is that, um, I enjoyed the work. I did. I personally did not. Some people get really, like, they just want to win elections and like, getting out of bed to win an election like that. That wasn't me. Um, I really enjoyed the data science of it. I thought that was really fascinating. Um, but ultimately, uh, although I care a lot who wins, I, uh, I did not find that the work of being, you know, trying to, to win elections was work that I found compelling enough to overcome the fact that it was a, it was a pretty grueling, uh, pace, especially, you know, in cycle.

Speaker B: Well, that, that makes a, uh, lot of sense to me. Uh, I can imagine how, how, I guess fast that that moves, especially with, like, very specific and strict deadlines for when things happen. Yeah, Um, I think that that is a really good segue to compare maybe your data science work to what a solutions engineer does, because I think, uh, most people are very familiar with what data work is. I mean, you painted quite a cool story about what your data work used to be. How does that differ from maybe a traditional solutions engineer role?

Speaker A: Yeah.

Speaker B: Ah.

Speaker A: So I Mean, it's interesting, right? When I came to RStudio then posit, right, for people who are in the R community, I think it's easy to imagine, at least at the time. I think this is maybe less true than it was back then. But like at the time it was like easy to imagine that all of our studio was just like Hadley and JJ and like Winston and Joe hanging out and like writing open source packages. And like that was what RStudio was, right? Was like the RStudio IDE and shiny and like that was kind of what, what, what we did, you know, uh, and then I started working there, right? It's a software company, right? We are a software company. We are um, um, I think somewhat, you know, we have a little bit of a unique uh, take in that we're a public benefit corporation. We're really genuinely committed to furthering the creation of open source software and furthering open source data science. Um, so it's a really cool company to work for. But at the end of the day we are a software company. We have to do all the things that a software company does because you know, I think underlying uh, the way POSIT works is this question of how do you fundament open source software? And there have been a lot of different models to try and fund open source software and the reality is unfortunately that most of them kind of suck. Like, you know, you can, you can get out there and you can do grants, you can try and find a funder, you can do like freemium stuff, you can do services on top of open source software. And some of those work and can be sustainable. A lot of them are just not that sustainable. And so the model that that POSIT has adopted, right, is we uh, have many engineers working on free and open source stuff that we provide to the community, uh, which is really cool. But then we need to pay for that. And so what we do is we have right, professional products that we believe provide value over and above the open source software. And in particular, um, the way, the way I, we, we think about it at, at POSIT is uh, you know, we really give away all the stuff that an individual data scientist needs to be successful on their own. Where, where we charge for software is the things that teams and organizations need to adopt and succeed with open source at scale. And, and you know, the reason for that is like if you're an individual person, if you're a student, if you're a hobbyist just doing something, like you should just be able to do that, right? But if, if you're fundamentally achieving uh, organizational value on open source software. Right? That's where we say hey, like we're contributing a lot to this. Uh, you know, we want there to be, be a fair exchange of value here. And obviously companies do get really far just using our open source stuff. That's awesome. A lot of organizations want a higher degree of security and stability and honestly they want somebody to yell at when it all breaks. And so that's what we provide with our professional products. And uh, that's sort of the solutions engineering role is this really cool role where we work with posit prospect people who are considering our professional products or have purchased them and we help them figure out how do the Posit products fit in to the ecosystem of other data things. Uh, they are doing right these days. Nobody has one data product and so we help them understand where does Posit fit into the stack that they already have and then we help them implement it. Right. We help them figure out how do I make authentication work so the right people have access and the right people have access to the right data. Um, you know, at, at the right time. How do we um, uh, uh, you know, configure the system so that it's stable and doesn't like fall over when you know, 100 users come on to use Posit Workbench or come on to look at a shiny app? Um, and so that's, that's really the solutions engineering role. Is this, this really cool? Um, it's a, it's a very technical role but also like you work with people all day, every day and I think it's, it's a really cool role um, for, for people who um, you know, really enjoy technical stuff but also enjoy working with people, enjoy talking to people, enjoy explaining things to people. So that's, that's, that was sort of a uh, meandering path to get there. But I, I wanted to set some context around like what does solutions engineer do? Because it's a foreign role to a data scientist. Because it's really a role that comes out of being a software company, not out of doing data science.

Speaker B: Yeah, I mean so where would you characterize the like, where would the sales engineering role fall between like a data scientist or maybe like a client facing data scientist and like a salesperson?

Speaker A: Yeah, great question. It's definitely, it's somewhere in between for sure. Um, I would say it's, it's, it really depends on the role. Right. We have people who are doing more engagement on with our sales team and those people are Closer to sales. Right. Most of what they are doing is they're putting together demos, they're putting together proof of concepts, they're helping organizations try the Posit software and figure out if it works for them. So it's still a very technical role but ultimately the job is to help that company figure out like yes, Posit is the right choice for me, I'm going to pay you for the software. Um, then there are folks who are more on the, on the post sales side and that is more of a, you know, enhancing adoption, making sure that the platform is really great and so on the team it's about 70, 30, 60, 40 between people who have a data science background and, and people have like an IT administration background because to do this job well you really need both parts. You need the data science to be able to understand what customers are trying to do with our products. So they, when they say like yeah, I'm trying to deploy this model and like I want to like have it run when this quarto doc runs and like push it out to the system. Like you have to understand what all of that means. But a lot of the data, excuse me, the day to day work is really around how do I get the system stable? How do I get the system up and running? You know, how does the Linux server need to work? How does the file server need to work? Um, and so the day to day work is not a ton of data science. But a lot of us on the team have this background in data science because it's what we're talking about all day, every day. We're helping data scientists articulate to the IT admins, hey, here's why we need to set this up in this way because like that's how I'm able to do my work. And then we talk to the IT admins and to help them translate with the, with the data science folks, um, and sort of play this, this role of um, you know, a little bit of translation. Sometimes there's a little bit of therapy in there too, uh, depending on the organization.

Speaker B: Yeah, I mean surprisingly it sounds to me very similar to like a, like a consulting role.

Speaker A: It's not dissimilar.

Speaker B: Yeah, where you're kind of straddling, you're like getting the solution and you're helping to facilitate things. I'm um, not necessarily seeing things all the way through. Like the company asked to take this somewhere but like hey, like let's get you into the right place and, and continue. I mean uh, one of my early roles was fairly Similar to that. So I came from M. Management consulting into data science and that was like a transition point to me where I was doing technical things. I, I had finished my master's in computer science in that time, at that time, but I was coming from a more traditional consulting side and it's like, well, honestly this is probably easier, it leverages more of my skills than necessarily just going straight into data science. And then obviously eventually did make that transition. But I really relish that type of work. It helped me understand.

Speaker A: Yeah, I think, you know, for, for the kind of person who enjoys that, right. Like consultative kind of work. I think this is a really awesome job. Um, so I love it. I think, I think it's a, it's a really, really cool position to be in. You know the other thing that I think is really cool about the way we do it, ah, at Posit at least is that the solutions engineering role is not, we're not just customer facing. Right. We also, because we are in this unique position of being, you know, very technical, very knowledgeable about the products, very knowledgeable about data science. And we're spending all this time with customers. We just know a lot about what customers are trying to do, what they need, what their pain is. And so we really think a lot about the responsibility to like take that and help other people, other people at Posit, right. Bring that back into the products, bring that back into our documentation, bring that back to the open source engineers and the professional product engineers so that ultimately, right, what we learn doesn't get stuck in our heads and doesn't become sort of like, oh, we're going to fix it for this customer but can over time, you know, make it better, make the docs, make the products better for everyone.

Speaker B: That's such a cool feedback loop. I don't think a lot of people really think about that as much.

Speaker A: Um, yeah, which is that to me is the, is the uh, like that's the part of the job that I think is like, makes it from like oh yeah, that's a cool job to like, oh. When I'm, when I'm talking to people who are in the interview process, like I sort of say to them, I'm like this is a big job. Like people who succeed at ah, Posit in this role are excited about having a big job with a lot of freedom where they just have the ability, uh, they are asked to go try and you know, improve the products based on what they, they've learned from talking to customers. Um, I think people who, who thrive in the role find that exciting. I think everybody finds it terrifying when they start. I certainly did. Uh, but, you know, people who thrive in the role find it both terrifying, but also invigorating and not paralyzing.

Speaker B: Uh, well, I think so. I've talked to jj. I forget what episode number it was, but it seems like part of that is also a transition to doing more Python stuff. I mean, obviously, uh, very common language in the data community. Um, some of my basketball clients are using R. And it's interesting to me because I'm like, pretty aggressively Python guy. But I'm wondering, obviously you're in a unique position going from R Studio to now having Shiny for Pythons, having some of these other options. What do you think the state of the language war is now?

Speaker A: Yeah, uh, I really think that we are in a spot where what language you choose to use, I mean, between Python and R, right? Like, if you want to go write some C, like you're doing a different thing entirely. But between Python and R, I really feel at this point like a lot of it is style and background. Like, I think personally I really love R. That's the background I come from. Right. I come from a social science background. Uh, I did two semesters of computer science in college. But like, I'm not a computer scientist. And so, like, for me, R makes a lot of sense in the way it treats data. I really like the interface. I think the tidy verse is awesome. Uh, I, you know, grew up using RStudio and learned a lot there. Um, I. And so, like, that's great. I, I think there are some libraries in Python that are better. There's some libraries in R that are better these days. I think that's the, like, that's why you would choose one or the other, or you're on a team that has standardized on, on one or the other, the degree of interoperability, especially, like, if you look at like Quarto for creating interactive documents, you can go like one code chunk, um, to the next, different languages. Five, fine, no problem. Right? You look at like the ability of, in either R or Python to write an API, to speak to the other one, or like to something else entirely. Fine, no problem. Um, you know, I think recently, right, we, we released, uh, is it now beta, the Positron ide, which is a new IDE that sort of is growing off of what, you know, JJ and folks learned about building RStudio and creating a, you know, from the ground up, multilingual data science thing. And honestly, for me, and I know I Know Python, people feel differently. For me, the main reason I didn't want to do Python is like, I don't understand why people like put up with jupyter notebooks. Like, y' all can have nice things too. I don't know. Like, I just think the RStudio IDE is so great. I always loved it and maybe that's because I come from there, but I've like, I always struggled to get into doing my work in a jupyter notebook. It just like never, never really worked for me.

Speaker B: You know, it's funny you say that because I've never like actively used.

Speaker A: So what do you use?

Speaker B: So when I started writing in Python, I actually use Anaconda, which is like very, very similar to RStudio.

Speaker A: Sure, sure.

Speaker B: And then people made fun of me for that. So I started using VS code and I use VS code now. And I think, I think VS code you have to install a lot of plugins to get it the environment. Right. But, but the funny thing is my VS code setup runs very similar to how my Anaconda environment was or like my.

Speaker A: Have you tried Positron?

Speaker B: No, it wasn't Anaconda, it was Spider. Spider, not Anaconda. Sorry, sorry. Spider, uh, is very similar to.

Speaker A: Yes it is. I tried Spider and I was like, oh, this is cool. But it is not as baked as our studio was at the time. Uh, have you tried Positron yet?

Speaker B: I haven't yet.

Speaker A: So it is fundamentally a, like it's a VS code. I don't know if it, I don't know if it's a fork or what. How exactly you would describe its relationship to VS code. Um, but it, it for people who are comfortable in VS code, it really like pulls downstream of that but builds off of. Right. The, the idea of a four pane data science IDE which like same as Spider or, or RStudio but sort of modernized and based off of VS code, which for the folks, right. I'm, um. This is not my, my area of expertise but like gave us a lot of things out of the box that in RStudio we had to build ourselves. Right. Like things like uh, uh, like as a very simple example like coloring of. Of code lines and that sort of thing. Right. It's like the kind of thing like you just, you just get from open source VS code. So um, if you haven't tried it, you might, you might want to.

Speaker B: Yeah, it's where honestly the one thing I miss the most is being able to see all of the data frames that you have like in working memory. And that was 100, like the single largest factor where uh, why spider was very appealing to me and now I operate without it. But I feel like you've like learned

Speaker A: to live without it. Yeah, so anyway, I mean that was for. So to, to go back to your original question. Like, you know, uh, to me it's just like, it's, it's more. And the other thing I didn't mention, right, is obviously like Arrow and other uh, you know, fi storage, uh, formats that allow basically symmetric access from R and Python. And so you can just like save and parquet or whatever and like it's fine, right. Like you get actually nice, right? It's not like saving in CSV where like then you import and everything kind of, you know, you gotta like recast all your dates and stuff, you know. But like it, it like actually works. Um, and so I think like increasingly it's, it's an interface level, the language is an interface level. And like, I think that's going to become even more true as LLMs become more and more capable in this regard, that it really is going to come down to some combination of personal preference and like there's this or that package that happens to work better. Right? Like, I don't know, at least as of a couple, I have not kept up with um, like natural language processing very much. But like as of a couple of years ago, right, the uh, NLTK in Python was like a better natural language processing library than anything I thought there was in R. So like, if you were doing that, I'd be like, yeah, go use Python. I think that's the kind of thing where it's going to come down to is there are going to be sort of esoteric packages for doing this particular task or that particular task that might be better in R Python. But other than that I think it's really going to come down to what, what interface do you like better?

Speaker B: I think, uh, I, I 100% agree with, with that sentiment. I mean, for example, I remember doing PCA in R was just so much better than in Python. Granted, not really a tool I use very often, but I was willing to basically relearn R every time I had to do PCA just because I didn't like using the Python libraries that were there. And just as you said, I think a lot of the AI tools we have now democratize the process, uh, or like the analysis to whatever language operates.

Speaker A: Yeah, I'm actually a little, and I'm curious what, you know, what you, what you think and what you've seen about this, but I'm actually a little concerned on that front because the way these, these LLMs work, right, they, they are good at a lot of basic tasks and I feel like you still need an expert to look at it and make sure it's doing what you think. Think it's doing. And I, I do wonder if like, introduces this at least question of like, how do junior people get their start? If, if, like, if you're able to do a lot of the stuff that a junior data scientist would do, if an LLM can kind of do that, how do you get over that hump to like, being able to then review what the LLM wrote and really, like, really knowing, like, yep, what it wrote. Like, that was what I meant. Or like, oh, shoot, that was not really what I meant, like, try again, Claude. Uh, that feels like a, an unsolved problem to me of like, it's, it's cool that, that it can do some of these, uh, these different kind of tasks, but it, like, it still feels to me like there's a need for expert eyes on it to, to make sure it's, it's doing what you want. And, and I'm not, I'm not sure how you get that, that exposure in a world where like LLMs are, you know, not today, but like in five years kind of, kind of territory.

Speaker B: So I think, as they are right now, agree 100%, basically, we need a lot of the stuff it produces is wrong or it doesn't work or it's like, I had an issue where I was writing some code and when I ran it on my machine, I just got different results and I was like, like, why is this happening? Uh, basically a name was misspelled and I was like, okay, fine, like, yeah, but I'm a little less concerned because I think that it allows people to iterate faster and see dramatically more code.

Speaker A: Sure.

Speaker B: And that evens out the, um. It evens out that eventually because there are going to be bugs in the code, you're going to be getting bad results and like, frankly, you're not going to have a job if you're producing bad results or, you know, there is a compromise. And so inevitably, I think sort of the market corrects itself that, hey, after you make a couple mistakes, you start scrutinizing it really carefully and then you can actually use it as a tool for debugging itself in the sense that like, hey, like, why is it this way? Why did you choose that rather than this decision? Are There other ways to do this.

Speaker A: I think that's cool.

Speaker B: I believe a lot of those problems can be solved with good prompting. And by good prompting, I mean asking questions of what is being built and having it break itself down.

Speaker A: That's interesting.

Speaker B: Uh, that's also a skill. I think that has to be cultivated so it's not something that comes out of the gate. But that, that's, you know, I, I'm, especially with people who are learning, I, I think they will give up before they come over reliant on it because they'll have problems with what's being created, um, as well. So that's sort of where I fall. But I, I think it's a, a still legitimate, a completely legitimate concern.

Speaker A: Yeah, it's interesting that, that makes a lot of sense to me. I think one of the, one of the things I'm concerned about, we got like what we're like 40 minutes in this. The first time I'm mentioning my book DevOps for Data Science. But like in the book, right? One of the things that I talk about is um, that you know, like if you're doing regular software engineering, there's basically like one kind of correctness you care about. It's basically like, does it run in a performant enough way? Like if your software does that and you're doing sort of general purpose software engineering, like it's fine, right? Like, like Zoom needs to run and like when it runs then like Zoom Excel works, right? But like when you're talking about data science, there's this second sense in which it needs to work, which is like the answers need to be correct and they need to be what you meant them to be, right? And like the problem with that is that unlike um, unlike the way you can write unit tests for a software stack, it's very difficult to write testing for actual results in data science because usually like you wouldn't be doing it if you knew what the answer was and you could just run it and make sure you got the right answer. And so I think uh, like what you're saying makes a lot of sense to me. Uh, it is still scary to me that probably you're going to find out those mistakes by like putting them in front of somebody who is an expert. And they'll be like this, this number makes, I mean we've all been. Right, like this number makes no sense. We've all heard that. It's like, oh geez, what have I done? Um, but, you know, but like, but like there's a second level of um, Correctness that you care about in data science that isn't there in pure software engineering that I think uh, you know, makes that sort of self correcting piece a little scarier I think for a data scientist. Whereas like if you're just writing code, if it doesn't run, it doesn't run or if it takes too long, it takes too long. But like you know, in, in data science, like your, your data merge can work in some sense of the word, but completely screw up your data along the way and you may not realize that for a long time.

Speaker B: Which is, yeah, there's not like binary outcomes where it's like yes or no. It's uh, this is sort of right or this is sort of wrong.

Speaker A: Or you can, you can code can run and give you completely the wrong answer. Uh, or like do something you, you don't intend.

Speaker B: Right.

Speaker A: Like there was that whole thing a few years ago in about in Scikit, learn like the default for a lasso regression made it actually a do. Do you remember this? Like, was that like the default value for some type of regression was not what people thought it was? Right. It was like this very like, it's like an interesting thing of just like, oh, if you're not reading the docs super carefully, you actually didn't do the kind of regression you thought you were doing. And that's, that, that's bad. Right? Like you want to do the thing you thought you were doing and you meant to do.

Speaker B: Okay, that, that makes sense. Where it's like, I would assume it's like a lasso and a ridge.

Speaker A: Yeah, it was like the penalty on a lasso was something somebody's gonna like yell at me that I got this right. But it was like, it was like the penalty value wasn't what people thought it was by default or something. Like it was something like that that people were surprised to be like, oh, I read the docs and it is different than I thought it was.

Speaker B: Interesting. Interesting. Well, I, you know, I, so I, I think that that's um, Unfortunately I think we're probably going to see just more issues like that presenting itself. I think we're going to see a lot of people who are starting in this field learning those lessons. The idea is that hopefully they learn those lessons in school now.

Speaker A: Right.

Speaker B: Um, rather than in the workforce. And that is where they can cultivate that.

Speaker A: You know that although I don't want to speak for you, I certainly learned those lessons the hard way. And so like, I can't say that anybody learning those lessons the Hard way, like with an LLM involved, like probably that makes it better, not worse, but you know, like I didn't do any better as a human. I learned those lessons the hard way, personally.

Speaker B: Uh, totally fair. But you know, I think that, I wonder if those, the error rate associated with that will go up or down.

Speaker A: Yeah, it's an interesting question.

Speaker B: Maybe it could stay the same. Yeah, I mean, that's something. Maybe we'll talk again in five years and be able to remiss and, and

Speaker A: I, I look forward to it.

Speaker B: Yeah. So, you know, talking about the book, talking about the nature of I guess like DevOps in the data science space, can you explain maybe what that actually means and how that might be different from for example, mlops, which is talked about quite a bit.

Speaker A: Yeah. So, you know, fundamentally DevOps is a set of practices, procedures and, and tools, sort of. Right. So here's like, I'm going to, I'm going to digress here and tell a little history. Right? So you're like in the 90s and um. Right. At least according to these stories, which I believe are completely apocryphal. Everybody is writing their software using the waterfall method where you like spend a year gathering requirements, you spend two years writing software and. And then voila. It doesn't do what you thought. Right. Like that's the like waterfall story. I'm somewhat doubtful that that ever actually happened. But like that's the story. And so then come up comes the rise of Agile, right? The Agile software movement, which is like this idea that you're going to, instead of trying to like do a year of requirements gathering and two years of building, you're going to build small increments, you're going to deliver quickly. And like fundamentally, while agile is a development method, it's also a, a method of like checking that you're doing the right thing, right? Because you're frequently going back to your customer, whether that's a customer, customer, an internal customer, and you're saying like, does this do what you want to do? Is this the right thing? Is this the right thing? But there's a problem which is you can write the code that does, you know, creates this, this thing. But like how do you then deliver it? Right? You have to put it into production somehow to get it in front of those people. And if you're doing this right before you did that like once, right, it was like you spent a year gathering requirements, two years building and then six months putting into production. But it was like one time, but now, you know, like if you're, if you're talking about a major code base like Facebook, right. Like they, they push I think like it's thousands of updates a week to their code base and they go live on the site. Like they're constantly just pushing updates. And so uh, uh, a system that requires you know, six months to check that a release is good to go just, I mean that's not going to work if you're trying to release, you know, even if it's once a month, right, which is a slow release cadence for a lot of products. Like that's completely untenable if, if it takes too long to get production. So DevOps is this system of tools, procedures, processes so that you can build the software to make it easy to put into production and put things into production in a way that they're going to be safe, secure, observable use. You can see what they're doing, you can understand what happens when they go wrong, recreate the error and try and fix it on the code side. And so it's basically trying to bring closer together the development, the dev and the uh, day to day running of the software, the ops. Right. So that's where it comes from. It's a sort of pure software engineering kind of concept. And so you know, as uh, might not be surprising given how I described what the solutions engineer role is like that's what I spend my time discussing with our customers. Like how do you take data science and put it into production, how do you make it production grade, how do you like write code that is ready for production then how you actually put it into production? And a lot of that is lessons from DevOps or they're an interpretation of DevOps. And you know it's tempting I think for people who are software engineers to be like you just do DevOps but you should just do it in R or Python. And I think that's really wrong. Like I think fundamentally data science is a different thing than software engineering. Like uh, uh, the analogy I draw is like if, if uh, software engineering is like architecture, data science is like archaeology. Like, like they're, you're, you're doing something in both cases but they're very different. And the way you think about building software and if you're doing data science like you're building software even if you don't like it or if you're bad at it, like you're building software. And so that's really what, what the book was a reaction to was observing that people knew a lot about data science, about you Know, uh, machine learning about, you know, statistics, about, um, you know, sort of, uh, uh, uh, like graphical design and these sorts of things. But then they got really stumped when it came time to put it actually into production. And so the book is sort of split into three parts where the first part is really about like, how do you write your code, your R. Python code, in a way that makes it easy to put it into production when the time comes. How do you think ahead to, like, how do I, how do I, you know, put it into production eventually? How do I make it secure, how do I make it stable, how do I make sure it scales on bigger data sets and these sorts of things? The second section of the book is the part that I really didn't want to write, but I kind of felt like I had to, which is like, if you have to manage the server that's hosting all this, like, how do you, how do you do that? How do you manage a server, how do you manage a database? What the hell is up with Docker? Like, you know, those, those kind of questions which I think a lot of us end up facing. I think most data scientists at some point in their career have to answer these questions, uh, but are really lost about where to start. So that's sort of the middle section of the book. And then the last section of the book is about, okay, you're working at a big company that has an IT admin organization. It's a sophisticated IT admin organization. What concerns are they going to have about the work you're doing and how do you communicate with them about the, the, the work that you need to do and make sure that they understand what you need from them and give, giving them what, what they need from you so that you can create a great environment to do data science.

Speaker B: I love that. Um, so let's. I also think that's a very important, uh, like, gap that is filled. Um, so my hypothesis, and correct me if I'm wrong, so DevOps for data science, it probably encompasses more of the pipeline than just mlops.

Speaker A: That's right, you did ask about that. So to me, I mean, MLOps is such an interesting, like, to me, MLOps is just this, like. And I don't know, there's been so much hype around it, but like, it's this tiny, narrow slice of the pie which is like, once you've built a machine learning model, how do you serve that machine learning model? And then how do you do things like horse racing them? And I'm being a little like, glib, about it, but to me it's such a small part of the work you need to do as a data scientist. And at least in my observation, there are organizations that have sophisticated mlops needs, but they're much rarer than organizations that like, have a dashboard in R or uh, you know, some sort of image processing pipeline in Python and they need to somehow productionize that. And maybe there's a machine learning model somewhere in there, but there's like a whole data management pipeline on one end. There's a whole downstream pipeline of people or systems who need to consume these things. And so there's a lot of understanding around the, the narrow slice that I think of as, as ML Ops, which is really about like building and serving machine learning models, which, you know, I mean, I think is an important but narrow part of the job of a data scientist. I mean, unless, you know, if you work at Netflix, right? Like there are just straight ML engineers at, uh, Netflix, and that's awesome if you can get that job. But like, most data scientists are doing a lot more than just building machine learning models. And particularly if you want to deliver value, there's so many other things you have to do than just building and serving machine learning models.

Speaker B: Yeah, I get it. So, uh, in terms of the DevOps for data science, what do you think is the most overlooked aspect of that, uh, process?

Speaker A: Yeah, I mean, this is the like, unsexy answer, but to me it's the people. It's that fundamentally what you're doing is you are a person who is working with other people to try and do something that is valuable to your organization or to the world. And so, you know, there are tools, there are systems, but fundamentally what you're trying to do is to work with other people to get something, hopefully something cool done. And so to me, and I see this particularly, um, from, from junior folks, right when I, my first, uh, uh, job managing a data science team, um, I was working with some folks who were just a couple of years out of college and they would be doing a lot of different kinds of work and they'd be like, when do we get to do the data science? Like, when do we get to build the models? And I'd be like, well, if what we want to do is provide value to our organization, and ultimately that's what matters, we have to be focused on understanding what is valuable to the organization, what is, uh, valuable to the people in the organization. And then there's a lot of like, relationship building to get that done. And so, um, you know, that's why the, my favorite section of the book by far is the third section of the book which does not have any code in it. It's all just like helping, helping people understand what it is that it. Admins are concerned when they, when they're talking about security, like what are they, what do they care about? When they're talking about authentication, what do they care about? When they're talking about stability, what do they actually care about? Because to me that's when data scientists can have the best outcomes, is when the data scientists are able to do data science and when they can communicate effectively with other people who are concerned about all these sort of productiony things and, and not having sort of crosswords. But you need to be able to communicate with each other and need to understand what those people care about. Like what keeps them up at night. It's probably not, you know, did you add that extra feature to your model? That's probably not the thing that, that keeps them up at night. Uh, although it might be what keeps you up at night as a data scientist and communicating about that. Uh, I think is, is the easiest part to overlook because it's right like people are going, they're technical people. We, we want technical solutions. We like the elegance of, you know, APIs fitting together like puzzle pieces and like. But then you have to like go talk to the person who's going to like put the API into your like, you know, production system and that, that's, that's a people problem. Uh, and that's, that's always, that's always going to be mushier than just writing a bunch of code.

Speaker B: I like that answer. It's a little harder to write or research or talk about the Mosheer side of things. And uh, I'm excited that your, your book connects those two so elegantly. Um, I would love, well, I'm excited to read the book. Um, where can people learn more about it? Where can people learn more about and um, hear more from you?

Speaker A: Yeah. So the entire book is available for free online. Do4ds.com d o n number 4ds.com um, entire thing is available for free there. You can also buy print or epub versions on Amazon or wherever you, you buy books. Um, so if you want a print copy or an EPUB version, you can, you can do that. Um, I occasionally blog@alexkgold space. I've written a bunch there about management if that's something that you care about. I wrote about why I dropped out of a PhD program. If, if you're thinking about that. Um, that's, that's on, on, on my personal blog. And then, you know, if you want to reach out and chat with me. Uh, it used to be Twitter, but I don't think that's true anymore. I think it's probably LinkedIn. Um, I'm, I'm, uh, Alex Kgold on, on LinkedIn. Uh, so happy.

Speaker B: Amazing. I will link. I will link all of those in the description and in the show notes as well. Alex, thank you so much. Is. Is there anything I should have asked that I didn't?

Speaker A: No, this. This was great. This was a blast. Thanks so much for having me, Ken. And, uh, really, uh, really enjoyed, uh, the time. Thank you.

Speaker B: Amazing. Thank you so much for coming on.

Speaker A: Yeah.

Speaker B: Thank you for tuning in to this episode of Ken's Nearest Neighbors. Many of you have been asking about how you can support the show, and we're extremely grateful for all the engagement so far. The best way that you can show your support is to subscribe to both the Ken's Nearest Neighbors and the Ken's nearest neighbors clips YouTube channels. If you're listening to us on Spotify or Apple Music Music. Giving us a rating and sharing any of the episodes with someone that you believe might find the content useful is also greatly appreciated. The Ken's Nearest Neighbors podcast is hosted by me, Ken G, produced by Bobby Hicks, and is edited by Mario Paul and Tony Pellariti.