#42 Full Stack Data Science

Hi, I'm Maggie, VP of Curriculum at datacamp, and I know firsthand how overwhelming it can be to keep up with the rapid changes in data and AI. But staying ahead doesn't have to be hard. That's why our curriculum team has curated the best learning content to help you and your team stay ahead, covering everything from data and AI literacy for busy executives to cutting edge generative AI for developers, and everything in between. Whether you're upskilling yourself or your team, we make learning practical, engaging and flexible. It just works. Power your data and AI transformation journey on datacamp.com.

In this episode of Data Framed, a Data Camp podcast, I'll be speaking with Vicky Boikus, a full stack Data Scientist and Senior Manager at Captech Consulting, working on projects in machine learning and data engineering. We'll discuss what full stack end to end data science actually is, how it works in a consulting setting across various industries and and why it's so dang important in developing modern data driven solutions to business problems. We'll also discuss the increasing adoption of data science in the cloud technologies and associated pitfalls, along with how to equip businesses with the skills to maintain the data products you develop for them. All this and more, I'm pumped. I'm Hugo Baun Anderson, a Data Scientist at DataCamp and this is Dataframed. Welcome to welcome back to Data Framed, a weekly Data Camp podcast exploring what data science looks like on the ground for working data scientists and what problems it can solve. I'm your host Hugo Bown Anderson. You can follow me on Twitter Ugo Bown and Data Camp datacamp. You can find all our episodes and show notes@data camp.com community podcast for those interested, we've also got a special offer this week for Data Frame listeners. The opportunity to try datacamp yourself. All you need to do is email salesdatacamp.com that's salesatacamp.com with the subject line podcast and redeem your free two week trial. Hi there Vicky and welcome to Data Framed.

Thank you so much for having me.

It's an absolute pleasure to have you on the show. I'm really excited to talk about your work in Python education, Full stack Data Science, end to end data Science, what these things actually mean and your work in consulting. But before we get into all of that, I'd love to know a bit about you. So I'm wondering what you're known for in Data Community.

So probably first and foremost terrible puns and memes about all sorts of data and programming related things. Secondary is the content. So my strategy is a little bit like buzzfeed. Right. Hit them with the memes and then sneak in serious content in between. I've written a lot of blog posts about how to do specific things in Python, how to do specific things in data, and then just talking about like where we are in the data community in general. So very high level articles and talking about things that break down complicated concepts into easy understand analogies.

Fantastic. So I love that secondary is the content and that primary. Terrible puns and memes. I don't mean to put you on the spot, but what's one of the worst puns you've said or come up with or heard?

So, so they're all so terrible. I have this series of puns where it's basically me pretending to talk to a TV producer to pitch them on possible shows or movies. And so that series is pretty terrible. Series of tweaks.

Well, we'll definitely link to that in the show notes. So that's primary. Secondary is the content. And I thought I would just mention that you're also in terms of content, in the process of creating a data cam course.

Yeah, that's right. I'm working on a course that teaches object oriented programming for Python, specifically in the context of a data setting. So we'll be going through how to create objects and do manipulations with CSV files and digging into numpy and Pandas internals. So I'm pretty excited about that.

Fantastic. And something you've also mentioned previously is that the educational stuff you do now is that you're essentially being the person you needed when you started out.

Yep. Yeah. So the Internet is a pretty big place and there's a lot of resources, but if you're just learning a program or you're just getting into data science, the best thing you can do is have an in person mentor or someone who's ahead of you, who you can ask questions and so my goal, I didn't really have that person when I just started out. So my goal is to be that person for people just getting into the field.

Fantastic. And actually Data Camp itself has a similar origin story in that the CEO, our CEO, Jonathan Cornelison, when he was at grad school, he, he was looking for something like Data Camp and just couldn't find it. He was like, okay, when I finish grad school, I'm going to make this thing essentially. So that's, that's one of our several origin stories. All that having been said, can you tell us what you do professionally at the Moment.

Yep. So I am a consultant. I work for captech Consulting and we do a bunch of different stuff. Part of our company deals with management consulting and part of it is deeply technical consulting practice. So right now I do both data science and data engineering consulting depending on the project scope.

So that sounds very much like this idea of full stack data science, right?

Yes. So the idea is that a lot of companies will start out by not having the infrastructure set up to do data science because really data science is kind of a mature product offering. So we'll come in, we'll build out those pipelines and then we'll get to the data science aspect which is creating the models and presenting those results. Great.

And we'll get to more of that later. In particular, I'm really interested in thinking about this job of building out the pipelines, doing that, but at the same time needing to demonstrate know value as, as quickly as possible within an organization. So this is something that's a little teaser for some things we'll chat about later. Before we get to that though, Data science is interesting because so many people have different avenues lead, all roads lead to data science in, in some sense. And I'm wondering what your journey was. How did you get into data and data science originally?

So I, I think I come from kind of a non traditional, kind of a traditional background. It's kind of in the middle. So I, I started out as an undergrad who majored in economics. And the reason I picked that because I didn't want to be an English major and I didn't want to be a math major and I like that econ kind of combined the two. So I like using both sides of my brain a lot. So that was my undergrad degree. And then after that I actually got into economic consulting which was pretty rare because I don't know a lot of people who focus on their major out of undergrad. So I guess I was lucky or maybe unlucky in that sense. So that's where I got tuned into doing stuff with data. Usually when you start right out of college, you start doing stuff with spreadsheets. So I started doing stuff with spreadsheets. And then I heard about this new cool programming language that was free, that was called R. I got exposed to that a little bit. I had a couple of roles that were analytics based and then my last role was as a data analyst where I learned SQL. And then I got tired of waiting for data to come into the SQL database for me, which is when I started really focusing on learning programming with Python and statistical methods. And then I became a data scientist as my next position. And at the same time I decided that I also wanted to get an MBA because I was interested in technical leadership. So I actually don't have a statistics or development background in terms of a master's program, but I kind of came to it through the job field.

That's really interesting because a lot of people I speak to when thinking about advice to give to aspiring data scientists is, you know, one of the most important skills isn't to be able to, you know, build a thousand layer recurrent neural network, but to be able to learn on the job and pick up new skills as you go along. And it sounds like that was an integral part of your journey.

Yeah, I think that's been really important for me the entire time in figuring out what to learn because there's just so much to learn learn in data science and in consulting. That's one of the primary skills as well, because you never know what kind of environment you're going to come into or what the client needs are going to be. So learning and a broad set of skills.

Great. And I'm just wondering, with your background in economics and your mba, how do these play into your work as a data scientist in general? I mean, do you find skills and tools you developed and ways of thinking in economics and your MBA useful in your work in data science?

Yeah, so economics and econometrics is actually pretty close to data science and I think that's probably partly where data science came from. So there's a lot of hypothesis testing, for example, there's a lot of statistics and econometrics that goes on. There's a lot of like the social science aspect where you have a hypothesis about how especially large scale systems would work. And that's what a lot of data scientists these days do, right? They test large scale social systems like social networks or platforms to see how things will perform. So that's part of it.

So let's talk about your work in consulting. I mean, I presume you work across a variety of different industries, but which verticals do you see data science having the most impact on in your experience?

This is going to be a really consulting answer, but it really depends and it's really a broad, broad variety of verticals. So the ones that I focused on in my consulting career so far have been telecommunications, banking and healthcare. And data science has an impact or a place in all of them as long as it's implemented correctly and as long as the business believes in data and sees it as a priority.

And what type of challenges have you found in demonstrating the value of data science across these industries?

A lot of the times, we'll probably get to this later, but a lot of the times it's even building out that pipeline to get to the point where you can do data science. But a lot of the times, especially in larger companies, my company deals a lot Primarily with Fortune 500 companies. Is getting to the point where you can demonstrate that your hypothesis, or whatever it is that you set to do, your call to action, actually results in a change in the business.

Great. And are you able to give any specific example, I don't mean the names of companies or anything like that, but specific examples in telcos, bank or healthcare of actual data science projects.

A lot of projects. So this has been true for every industry I've been in. Every company wants to be able to measure churn or why customers are leaving or joining their platform, and especially tracing the fact of why companies are unhappy. And for larger companies, this might result in an enormous amount of features, not all of which you can control. For example, the signup process, the billing process, issues they've had with their cert, with your service or with their service, outside people that have approached them. So you can create a model of what potentially causes customers to churn, but that might not necessarily be reflective of the real world. And I think that ties back to econometrics too, because in econometrics, you're trying to create a model of the entire economy, but you really have what you really have as a representation because you can't trace all of it.

Yeah. Great. And I'm actually. This is a great example and something I've actually been thinking about a lot recently and talking about this morning. In fact, this inter. The churn example, in particular, the potential for customers to take their business elsewhere is the intersection between data science and decision science, because you can build a model that may tell you or approximate what's happening in the world as to why customers are churning, but that doesn't tell you what to do.

Right, right. So ultimately it's for the data scientist, in my opinion, to present a number of options, to present clearly what they think their view of the company is, and then a way for the company to move forward. And that's kind of the point where we hand that off to a client. We'll recommend a couple options, but we obviously won't say, here's what you have to do.

Yeah, great. And in the churn case, I can imagine several courses of action. So the first would be to, if you think a customer's going to churn, reach out to them and make them some sort of offer dependent on how valuable a customer they are to your, your company. Another would be to try to nip it in the bud well before they're going to churn. Are these the types of suggestions that you make or are there others as well?

Yeah, usually it's preventive or you can change it when they're about to churn, or you can create preventive measures so that they can channel their frustration somewhere. For example, new support channels. Great.

So in your work across all these industries, what are common patterns you've seen in data science across them?

So one is that I think we've heard this a lot, but getting the data to a point where you can actually do data science is always 80% of the work. And usually when we come into a company, a lot of the work will be getting the data to a point where we can do data science. The selection of tools and understanding what everybody else in the industry is doing. So kind of this need for understanding best practices, are we picking the right tool? Is this what other people in the industry are doing? Is this what people in our industry is doing? For people who are interested in having data science making the case that we need someone to come in and help us do this data science practice that we actually need data science that we actually need, need help making these decisions, those are probably the big ones.

Interesting. There are actually a lot of things that spring to mind there. The first I want to zoom in on is a lot of it's data preparation, getting into a form where you can do analytic or data science work with it. This amount of preparation you have to do, do you see this changing in the next 2, 5, 10 years? Will these types of things become more and more automated and hopefully productized there?

I mean, some of that. But ultimately I think it's just a feature of data because usually unless you're working in manufact or some related field, what you have is you have humans generating the data, making sense of the data, defining how it's going to be in a business sense. And that kind of data is always going to be messy and especially across larger organizations where you might have five or 10 or even 20 different data flows, sometimes you have two data flows, they're exactly the same, but just with a little bit of difference. That kind of reconciliation is always going to be existing. But what I do see happening more and more lately is a lot of organizations are calling for more data governance. More metadata management is becoming increasingly important in larger organizations. The ability so I think over the last four years or so the push was to get stuff into a data lake. It doesn't matter how. It just needs to all be in one place so we can do something with it. And now the idea is we want to be able to manage our assets in a data lake. We need to be able to see them, represent them and have the business be able to inventory like an S3 bucket or Hadoop cluster or something like that.

That great. We'll jump right back into our interview with Vicky Boikus after a short segment. Now it's time for a segment called Data Science Best Practices. I'm here with Ben Skranker, an independent data science consultant who was my guest on episode four of Data Framed and talked about how data data science is revolutionizing the trucking industry. Hi Ben.

Hey Hugo. It's great to be back on your show. Thanks for inviting me to share some of my hard earned wisdom with your listeners.

Hard earned wisdom? Do you have an example?

Well, like Niels Bohr like to say, an expert is someone who through their own sad, bitter experience has made a sizable fraction of all possible errors in the field. What I'd like to talk about today is Chris dm, which stands for the Cross industry Standard Process for Data Mining. I think it's a great example and not many data scientists know about it.

How is it a great example?

Well, often I see data scientists carried away by the excitement of a project and they just dive into the project without thinking about really important questions. And Chris DM is probably the best workflow in industry for solving data science problems. And it helps you think through your problem end to end so you don't miss steps and you solve for the right thing and use the right metrics. And as I mentioned, surprisingly most data scientists just don't have a coherent workflow and they just got something they cobbled together or they stumble along and it makes them very inefficient. They miss some steps and they make mistakes.

So what are the benefits of having a workflow?

I think there's really no reason not to use a workflow. It's essentially free productivity. It's going to help you get your results faster and avoid common errors. And it's also going to make you think through a project all the way to evaluation, deployment and beyond, which is also super important if you've ever lived in a production real world environment.

So how does this Crisp DM work?

Well Crisp DM has six steps and the first is business understanding, which is super important. And we follow that up with data understanding, then data preparation, modeling, evaluation, and deployment. The business understanding step is particularly crucial. During this first step, you need to define the business question and what success looks like. In the next step, Data understanding, you survey your data to determine if you can even answer your question with the data you have. If not, you need to refine your business question or augment your data.

Now things are heating up. What was next? Data preparation.

That's right, and this is where the real fun starts. In the third step, data preparation, you begin to explore the data, determine its strengths and weaknesses. Now is the time for exploratory data analysis, or EDA for lovers of acronyms and visualization, followed by data cleaning. In this stage, you prepare the data so you can start modeling and it's really exciting because you start to unravel that Agatha Christie mystery that's hidden in your data. After that, you move on to modeling, where you engineer features and refine your modeling approach further. At any of these steps, you may find you need to revisit an earlier step to refine your understanding. So for instance, you might start modeling and realize your model doesn't capture some key aspect of behavior and you need to go get some other data set to provide that information.

And then what?

Well, finally you need to evaluate and deploy the model because that's where the rubber meets the road. Evaluation includes standard tools like examining model performance on new data while running in parallel with the old model or a benchmark model. You may want to run a B test once a model is finished as well, to make sure it has good fidelity with reality. And you should expend enough effort to make sure your model is correct.

Well, that sounds a bit like VV.

And uq, you're right. But verification, validation and uncertainty quantification is a subject for another day. Thanks for chatting.

Thanks Ben. Listeners, we'll include a link or two in the show. Notes about Crisp dm Ben, I'm looking forward to having you back on the show to chat about VV and UQ as soon as possible.

Thanks, Hugo.

After that interlude, it's time to jump back into our chat with Vicky. The other thing you mentioned that I'd like to discuss is you mentioned kind of the movement towards figuring out best practices for the industry, what other people are doing. And I wanted to discuss this kind of in the sense that it appears to me that a lot of people, a lot of data science work is occurring in SILOS across many different consulting groups, many different organizations, and that a lot of people seem to be reinventing the wheel in parallel in a lot of ways. And is that something you've seen as well?

Yeah, I think that can definitely be true. And what I've seen in a couple of my projects that were really successful is the organization or the client was dedicated to centralizing all of this stuff. So what I've seen come up in larger organizations is something called a center of excellence where you have cross functional teams. So you have engineers, you, you have data analysts, you have data scientists. And they all meet together to talk about what they're doing as a team. So I've seen that kind of structure come up more and more recently.

Is this the type of structure within an organization for data sciences, data science teams that you think is the most effective?

I think so. I'm a big proponent of always having all the stakeholders of any given data science project in the room if it's practical. So for example, if you have maybe 200 people that are going to impact, probably not. But I really always push for developers to sit with data analysts and more importantly with business users because usually the developers are the first part of the process and the business users are all the way down there. So it can be like a game of telephone where the developers build something that gets put into some warehouse that gets put into a dashboard by the time it's built. The business users don't necessarily always want it and can act on it. So I always like to have all those people in the same room.

What do you think about the future of, I suppose, data literacy for business users? Will we increasingly see, you know, people in management, C level people using dashboards become more and more knowledgeable about what data is and how it works?

I think so. I'm really optimistic about that and not just because it's job security for me, as people want more and more data. But I do believe that the popular press, or at least the tech press, has gotten to a point where, and I've seen this in business literature like the Harvard Business Review or what have you, it's gotten to the point where a lot of executives now understand the need to be data driven. And usually when meet clients they say we want to be data driven. I think the next two to three years will be ironing out what that means for them.

Specifically, I presume it will mean some sort of, you know, computational literacy. I think it will probably mean a bit of statistics as well. And do you think people will need to learn like the basics of math even and linear algebra and you know, logistic regression and these types of things. Or is that expecting too much?

No, I. Well, I think the onus there is on the data scientists to present things for different audiences. So if you're a data scientist and you're presenting to other data scientists, you, you can obviously talk about the specifics, the parameters that you have in your logistic regression or what have you. If you are talking to project managers and especially executives, you should be speaking in a very different way and you should be talking in a way that makes sense with what they're interested in. So an executive is probably not going to be interested in the algorithm you used, but they're going to be interested in what you found and what kinds of actions you think that they should take. So I am a firm believer in speaking to people in the language that they understand.

So I want to shift gears slightly and talk about your approach to building full stack end to end data science solutions. Before we do that though, I wondering if you could give us the elevator pitch or something analogous on what, what even Full stack end to end data science is or means.

Full stack to me means basically building out a data science product. So you start with some kind of data flow, you transform that data into in some environment and then you output a model and you display that model. So that to me is end to end data science. And that's more of a product rather than a project, which I see as iterating on a specific model, for example.

Great. So what's your approach to building these solutions then?

So I don't have a standard approach, it really depends. So I usually come into the client site and just kind of observe for the first week or so I see what the team norms are, what kinds of tools they're using, where their pain points are. I get really annoying and I ask a ton of questions and I do a lot of documentation. And then we usually start with looking at where the data flows into that team or that organization and seeing what we can leave behind that will be easy to maintain, reproducible, where you can understand the model that's going into it and where you can easily visualize the output. This is like the golden ideal of.

An end to end. And could you give me an example of one you've worked on recently that you think was particularly valuable?

Yep. So I did a project a couple of projects ago that was building predictive modeling capabilities into software as a service platform. So this client had a number of, let's say a Number of things that they wanted to predict about their clients. And they had the descriptive capability, but they didn't have the predictive capability. So my part was taking the data that they were already getting from their clients, putting that data through a model. So I used a Markov chain model that was kind of similar to modeling page views for this particular industry and then I integrated that back into their existing software platform. So really my role there was one ingesting the data that the company was currently collecting in its SaaS platform, analyzing that data, making sense of it, because there had been no data analysis done before, figuring out what kind of model best to use to predict. And it turned out to be a Markov because again, the product was similar to page views, where you want to predict kind of the next move of the person or the client client and then integr, then wrapping that model around something that you could integrate back into their software as a service platform.

So once this model is in production, who then is responsible for maintenance of it and essentially also responsible for checking on model drift, which for our listeners out there, model drift is a phenomenon where when you have a productionized machine learning model, for example, it may not work, it may not give the results you're expecting after three to six months, for example. So who's responsible for this type of maintenance then?

So that depends on the type of project. Usually what we'll do with our company is we'll work with clients to stay on a month or so after and monitor the model. But usually we'll make it so that it can be easy to change on the client side because ultimately it's theirs. So we have to then make sure that it's easy to document and easy to change, which is why it's important to come in and observe it first, like I talked about to, to see what tool sets they're comfortable with, what programming languages they use, what the statistical skillset of the people on the team are so we can pass it back to them and not have it be a black box.

Fantastic. So that really is setting the expectation to make sure there's someone in house there who even has the capabilities to do this type of maintenance. So another thing that sprung to mind when you elucidated the process of building full stack end to end data science solutions was there are so many steps along the way and to be able to do this as one person, as opposed to a team of people with different specialties, you really, it seems like you, well, one needs, one needs to be. And you are a data Science generalist in order to do this.

Yeah, I think that's true. I mean in general I hate to like propel the myth of the data science unicorn. I'm certainly not a unicorn, but I do think there are generalists and specialists and for consulting particularly it makes sense if you are a generalist and if you like to be a generalist because you could be doing a bunch of different things. So recently I've done some prototyping in R, right now I'm working on data ingest into aws. I've done, like I said, the Markov chain modeling before. So all of that really is the skill set of understanding what the client needs and being able to figure out how to research and to get to that point where you can offer a solution versus a specialist who might be very, very knowledgeable in for example, deep learning for a specific industry.

Yeah, and you mentioned are there implicit in your work, of course, is that you work with SQL in order to do what you need to do. I'm sure you need to do a bunch of command line stuff and you work in Python as well. So there's this kind of whole array of tools that you use to get the job done, right?

Yep.

Yeah, I would say my primary tool when I can use it as Python, just because it's also kind of like the Swiss army knife of languages. I actually read somewhere recently that Python is the second best language for almost anything, which I agree with, it's my personal favorite language. But if you want to do almost anything, you can do it with Python. And so for my position particularly, it works really well. But like I said, I've worked with R, I've worked with Scala, I do a bunch of command line stuff recently, more and more I've been working with cloud platforms, AWS in particular, which is a whole new skill set. And more and more with engineering things like continuous integration, which is putting your model and making sure that you can keep building it and integrating it into the software.

And I actually. So I've referred to Python as the Swiss army knife and I've heard it referred to as the Swiss army knife for years now. And I just had a brain flash, even if that's even a term that maybe we could call it the Dutch army knife because of Guido.

In honor. Yeah, in honor.

Okay, great. I just want to also make clear to all our listeners that although Vicky and many guests I have on our data science generalists definitively not everyone is and there is not a need to be a generalist either. And something we May discuss later is that we actually are seeing a lot of specialization emerge within the discipline.

Right, Vicky?

Yep, I totally agree with that. I think there's a place for both. And I'm also a big proponent of data science teams, as opposed to just one person doing it alone. So I always work in teams and usually it'll be someone who knows a little more statistics, someone who knows a little more engineering, and someone who's more business or business analyst oriented and someone who's completely business facing. So you have a combination of three or four of those kinds of people. And the best teams that I've been on complement each other in those ways.

So for people who want to get into this type of work, you know, building full stack, end to end data science products and solutions, what advice with respect to learning paths would you give them?

I would say to just learn one thing that you're interested in. And so the best advice I ever got was to just learn one language really well. It doesn't matter what language you're learning. Although probably for the generalist Python would make more sense. But learn one language really well and learn the internals of that language so then you can apply it to other things. Because what generalists do really well is to understand how different things apply to other things. So, for example, oh, this is how objects work in art. This is how objects work in Python. Oh, this is how data flows into aws, this is how data flows into Hadoop. This is how we would do something in tableau versus D3. So generalists generally work well with patterns and are able to research different things. And so what I would suggest is one learning one language and then being able to extrapolate from that. And B, build, try building a product or a project end to end. And I had a tweet about this, which I can link to, because it can sometimes be really hard to come up with project ideas. Ideas and daunting too. So the way that I kind of scratched that itch for myself was I built a project called Soviet Artbot which tweets out socialist realism art. So for that I had to get that art from a website, I had to put it in aws, and I had to have an AWS lambda to create the bot to tweet. And so that kind of like scratched my itch to figure out how all those different parts came together. Like I said, I have a tweet that I can link to that has a couple of different project ideas.

I love that. And we'll definitely link to that in the show notes. We'll jump right back into our interview with Vicki after a short segment. Now it's time for another installment of Statistical Lesson of the Week. I'm here with Emily Robinson, a data scientist on the growth team here at datacamp. Hi, Emily.

Hi, Hugo. Today I'd like to talk about Simpson's Paradox, a phenomenon in probability and statistics.

Great. I, for one, feel that everybody should know about Simpson's Paradox. Tell us about it.

The paradox is that a group of data may show a particular trend that is reversed or disappeared when groups are combined together. Here's a famous example. In 1973, the University of Berkeley admitted a smaller percentage of female graduate school applicants than male, 35% versus 44%. This was a statistically significant difference. So was the school discriminating? Three professors, Bickle, Hamill and o', Connell, investigated. They wanted to examine the people in charge of admissions to see if there was evidence of discrimination in graduate school. This is generally the faculty of the department the person is applying to. But when they looked at all the departments that had female applicants and denied admission to at least one person, they found only four departments that had evidence of bias against women and six with biases in favor of women. Additionally, for those four departments with evidence of bias against women, the number of women they would have admitted without bias would have only been about 26. But the overall admissions was short 277 women.

This may seem odd to the uninitiated. How can this happen?

The problem is that looking at just the aggregate data, you don't take into account the relationship of the gender of the applicant and the department. It turns out that women were more likely to apply to competitive departments and less likely to apply to departments that were easy to get into. And this was even more pronounced in departments with large numbers of applicants. So while overall a smaller percentage of women were admitted, this is entirely explained by their choice of department.

Right. Could you talk us through a simplified example with numbers?

Sure. Let's say we only had two departments, A and B. A lets almost anyone in, and B is very competitive. A gets 990 male applicants and 10 female applicants. 980 of the men get accepted and all 10 women get accepted. So the acceptance rates are about 99% versus 100%. Department B gets 10 male applicants and 990 female applicants. They don't accept any men and only accept 10 women. So it's about a 0% to a 1% acceptance rate. So each department accepted a higher percentage of female applicants than male. But if we aggregate the numbers for the school, 990 men out of 1,000 got accepted, or 99%. But only 20 women out of the thousand got accepted for a rate of 2%.

I think I get that. So does that mean we should always look at subgroups if we know they exist instead of the overall statistics?

That's the tricky part about the paradox. You need to know your context. For example, imagine instead of departments A and B, they were Saturday and Sunday and male and female applicants were replaced. With you and me trying datacan problems, you may have done better on Both days. Getting 100% of the 10 problems you tried on Saturday right, and 1% of the 990 problems on Sunday right versus my 99% of 990 problems right on Saturday and 0% of the 10 problems on Sunday. But we certainly wouldn't say you're the better problem solver. You only got 2% of them right while I got 99%. In this case, we look at the aggregate because the distinction between Saturday and Sunday isn't meaningful.

So this is an example of where it's important to know the context. In the day of the week case, we want to look at the aggregate numbers because the groups don't really mean anything, while in the Berkeley case we want to look at the statistics by groups.

Exactly. Never do data analysis in a vacuum.

Cool.

So I also want to mention that this can happen when you have two numeric variables and a categorical grouping variable too. So in one of my tutorials that I'll link to in the show notes, I show how in the IRIS data set, overall sepal length is negatively correlated with sepal width. But if you look within each species, sepal length and sepal width are actually positively correlated.

Simpsons paradoxes are really everywhere.

They sure indeedly doodely are. Well, thanks Emily for another instalment of statistical lesson of the week.

Thanks Hugo.

Time to get straight back into our chat with Vicky Boykas. Something that's in the cultural consciousness at the moment. It has been emerging for some time is this trade off in predictive analytics, machine learning and deep learning between multiple forms. So how well a model is at predicting what it wants to predict and being interpretable. So trying to figure out why it's making the predictions it does. And I'm wondering in your work and your client work, what is the approach to this trade off generally?

So.

So my personal approach is to always create models that are a little bit simpler but always easier to look in under the covers. And the reason for that, and I probably would Have a different answer if I were full time at a company. But as a consultant, you always need to be able to leave behind work that other people can look at, they can take apart, they can rely on, is easily documented. And especially for dealing with people that are not as technical, it's important to be able to explain those things really well. So for me, I always err on the side of simpler is better.

So something you spoke to earlier was the fact that more and more data science work is moving to the cloud, and I'd just love to pick your brain about that. I mean, this is a relatively large challenge for us as a community to do, and I was just wondering how you approach this in your work.

Yeah, so what we've seen recently, while it's been a trend over the past couple years, but I've seen it come up in more and more projects, is a lot of clients are starting to realize that they don't want to maintain infrastructure and they want to take everything to the cloud. And of course, when they're doing this, they want to consider the fact that there's now things that you have to manage. For example, you have to manage the security of the cloud. Like there's been a lot of stories in the news lately with, for example, S3 buckets just kind of left wide open and all the data leaking out. So that's important to handle off. You need to handle some of the cloud management and most importantly, you need to understand how all of these parts work together because it can be harder than just, for example, creating a model inside kit, pickling it and then putting it on some server. You have to understand how all the parts of the ecosystem work together. So that's becoming more important in data science. And I think for specifically for data science in the cloud, the tool set is really just emerging at this point. Like, for example, I know there's SageMaker and Google Cloud has some stuff and there's Azure machine learning, but all of these are, I feel like, are just starting to come into their own, but they'll become more important components as people move in that direction.

And also I think the fact that these are emerging and rapidly developing technologies means that the barrier to entry might be slightly higher, right?

It could be, yeah, it could be. In some ways it's less than others. So if you already know how to move in cloud environments, the barrier to entry to the cloud is low. And then the barrier to entry for machine learning is lower too, because there's already some prototyped components that you can put together. If you don't know how to operate in those environments. In that sense the barrier to entry can be higher. And so what I've seen recently is a lot of people doing data science are kind of moving a little more towards the engineering path even. Right.

And yeah, I suppose I'm really thinking of the people who, you know, are working data scientists or are, you know, proficient in machine learning, trying to go to the cloud and it may not even be obvious, even documentation wise, what to do and how to do it.

Right. Yeah. The documentation for a lot of these cloud services, these a lot to be desired and.

But we'll see that improving surely.

Yeah. And in fact, I know aws and I think also Microsoft have open sourced their documentation on GitHub, which is a really positive.

That's right. And I actually recently had Paige Bailey on, on the podcast who's a software developer advocate at Microsoft Azure. So and she, she's instrumental in a lot of this work as well. Great. So we've talked a lot about kind of the data science landscape and your work. Currently I'm wondering what the future of data science looks like to you.

So I think what we'll see is a lot of standardization and kind of like a narrowing out of the industry. So the last five years have been about this explosive growth in this new field called data science, which nobody really knew what it was at first. And so we started to define that there's a lot of now kind of shifting to data science. Everybody almost knows that data scientists are statisticians. What we're seeing now, I think is a lot more to your point, specialization. So there's a lot of people doing specifically deep learning or specifically AI. A lot more movement to software development like I mentioned, especially as more stuff goes into the cloud. Data scientists will need to know how to work in those environments. And as always, I think the future belongs to people who can be flexible, who can write and read good code in whatever language and who can teach themselves as the environment shifts.

Great. And I do think something you spoke to previously is trying to understand what best practices in data science look like. And there isn't as of yet. I mean, people talk about certain things, but there isn't kind of solidified system of best practices like there is in, you know, front end software engineering, for example.

Right? Yeah, And I think that's just starting out. So like I've seen both Facebook and Google release guides on machine learning and things to look at. Google is particularly good because it has things you should look at. And Facebook just released A bunch of videos. So I think that will start to become more solidified. And the other side of that is you also hear a lot of people talking about ethics in machine learning and data science. And I think there might be some pressure from that perspective as well to define just what data science means. And of course there's GDPR regulations which will have us define what data we can collect. So I think all those three things together will give us a little more fleshed out view of what that is.

Yeah, great. And I think the GDPR is an interesting example of. We'll be seeing more and more of this. I mean, that's Euro specific. Well, in. In a number of ways. If you have any data going through the EU potentially as. As well. But as we see more and more countries adopting these types of things, I'm wondering if that will impact how we use cloud technologies as well.

I'm sure it will to some extent. I think the big thing in cloud will be figuring out security. Security and data flows for sure.

You mentioned ethics in data science. I'm wondering what, what you think the biggest concerns are in the ethical landscape.

Personally, I would say right now probably the biggest issue is data leaks. So there's a number of different things. But I want to focus on the practical issue, which is a lot of people are not securing their data. So the issue there is potentially collecting too much and then not monitoring carefully enough.

Okay, yeah, I agree with that. So we've talked a lot about different aspects of data science and the data science flow. I'm wondering in particular, what's one of your favorite data sciencey things to do? I mean, techniques or methodologies?

Yeah. So the ones that I enjoy doing the most because I get the most return out of them are probably decision trees. And the reason I like them so much is because they're very easy to discuss with people who aren't necessarily data scientists. They're very easy to visualize and they give you a clear path to a call of action. So if I can utilize, that might do.

And so this really speaks again to something we were discussing earlier of one, interpretability. You can actually show someone going down the tree and what decisions it makes at each branching point. But also ease of explicability or just being able to explain something to someone else.

Yep. And the ease of porting between multiple platforms as well.

In what sense?

Implementation details. So you can create a decision tree locally inside Kit Learn, you can create one on In R. You can create one on almost any platform that exists.

Yeah.

So I like it for that reason.

That's great. And of course in SciKit learn you can. It's nice, it's compatible with Graphviz.

Right.

So you can visualize it immediately.

Yeah.

What about with respect to data engineering, what really gets. Do you love doing there?

So I'm really into AWS Lambdas, which are basically think of them as like virtual environments that exist ephemerally. So they spin up, they do something and then they go away. There's a lot of potential for use with them and I'm really interested in exploring them a lot more. And I've used them in my past two projects and I see them only growing.

What's the game, what's the big win to be made with AWS Lambda environments, do you think?

So they, they're kind of like functions that do things very quickly so they can move data, they can tweet. So I use lambda functions in my bot to tweet every certain amount of time. They're very easy to maintain and once you set them up and have them going, they just kind of keep going.

Fantastic. All right, so my last question is, do you have a final call to action for all our listeners out there?

Yeah. So I'm on Twitter, I'm Boikas. You can find my site there, my tech blog. And if you're interested in more about what my company CAPTECH does, you can go to CAPTECHconsulting.com we're always hiring and we're always taking on new clients.

Fantastic. And I suppose I do have a follow up question there in terms of the hiring process. This is a question I get a lot. Do you have any advice or general rules of thumb for people entering an interview process? I mean with you or elsewhere?

So one, prepare well to understand the company that you're interviewing for. Especially in consulting, it's a little bit different because we're looking for people who are good technically, but we're also looking for people who are interested in doing a lot of different things and are good at doing a lot of different things and can be self learners and do a lot of research. And the second thing is to be enthusiastic about what you talk about. Tell me about what you're passionate about, tell me about what kinds of projects you've done. If you've done projects outside of work, tell me as much as you can about your work projects. So basically when I come into an interview with someone I'm looking to have, I'm not looking to trick you, I'm looking to have a conversation with you. And to see if I can work with you.

Fantastic. Vicky, it's been an absolute pleasure having you on the show.

Thank you for having me.

Thanks for joining. Our conversation with Vicky about end to end data science and Full Stack data product development. We saw the absolute importance in data science consulting to businesses of Full Stack Data Science, which essentially means building out data products. What this means is starting with some sort of data flow, transforming the data in some environment, and then outputting and displaying the model and its results. Moreover, we saw the importance of making sure there's somebody within the organization to maintain the model and the skills within the business and may alter how you build out your solution. We also discussed the role of the generalist data science in the consulting setting and saw how cloud computing is making some parts of the process easier. But we do need to be vigilant of new emerging concerns such as data privacy. Also make sure to check out our next episode, a conversation with Andrew Gelman about statistics, data science, polling and election forecasting. Andy is a professor of statistics and political science and director of the Applied Statistics center at Columbia University. Next week, Andy and I will talk about the ins and outs of general polling and election forecasting, the biggest challenges in gauging public opinion, the omnipresent challenge of getting representative samples in order to model the world, and the types of corrections statisticians can and do perform. Chatting with Andy was an absolute delight and I cannot wait to share it with you. I'm your host, Hugo Bown Anderson. You can follow me on Twitter Hugo Bown and datacamp at datacamp you can find all our episodes and show notes@datacamp.com community podcast. Don't forget that. For those interested, we've also got a special offer this week for Dataframe listeners. The opportunity to try datacamp yourself. All you need to do is email salesdatacamp.com that's salesdatacamp.com with the subject line podcast and redeem your free two week trial. Now it's time for a segment called Blooper Reel with Hugo and Emily. Hi, Emily.

Hi, Hugo. Today I'd like to talk about Simpson's paradox, a phenomenon in probability and statistics.

Great. Okay. Yeah. I don't know what happened there. Great. Okay, I'll click and I'll just. We'll start again.

Let's just start again.

Yeah. Now it's time for another installment of Statistical Lesson of the Week. I'm here with Emily Robinson, a data scientist on the growth team here at. Oh, that's awesome. I think we've got an outtake.

I was like, why? I was like, did something go wrong with you? Just, like, pause after sitting.

Yeah, I don't know. I was just. I was staring at the word great, and I was like, great. Okay, we'll try this one more time, okay?