#29 Machine Learning & Data Science at Github

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 Frame, a DataCamp podcast, I'll be speaking with Amoju Miller, a senior machine learning Data Scientist with GitHub. Omoju and I will talk about the role of data science in product development at GitHub, what it means to use computation to build products to solve real life, decision making, practical challenges, and what building data products at GitHub actually looks like. Machine learning has the power to automate so much of the drudgery around data science and software engineering, from automated code review to flagging security vulnerabilities in code, and from recommending repositories to contributors, to matching issues with maintainers and contributors and identifying duplicate issues. And just in case that's not enough, we'll discuss GitHub as a platform for work, not just technical and as Emojuhu has called it, a collaborative work environment centered around humans. We're also trying something new this week for Data Framed listeners. The opportunity to try datacamp yourself. All you need to do is email salesatacamp.com that's salesatacamp.com with the subject line podcast and redeem your free two week trial. I'm Hugo Baun Anderson, a Data Scientist at DataCamp and this is Dataframe. Welcome to DataFrame, a weekly datacamp 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 hugobown and datacamp@datacamp. You can find all our episodes and show notes@datacamp.com Community Podcast hi there Emoju, and welcome to Data Framed.

Thank you Hugo. I'm excited.

I'm super excited. It's great to have you here to talk about Data Science at GitHub, but before we get there, I want to find out a bit about you and I want to talk about how you got into data science, what you do at GitHub, but I'd like to take a slightly tangential approach to finding about you first by just asking you what you're thinking about at the moment with respect to data science, or what keeps you up at night, or what really is exciting you.

So. So the thing I've been thinking about a lot is the term artificial intelligence and the fact that it is such a misanomer because the work that we do is not necessarily artificial intelligence. Most of us in industry don't work on AI. We work on massive mathematical problems that are basically a variance of some kind of linear algebra. And that's what we do. We are applied mathematicians. And so I've been thinking a lot about that and then using the right kind of terms, like maybe we're doing things like augmenting human intelligence or building like data intensive platforms and things like that, like figuring out a word that more represents the work that we actually do. So people don't come off with the ideas that we're building some kind of completely autonomous being with some conscience and sentience, because that's not what we're even doing at all. We're not even anywhere close to that.

Agreed. And I think part of the big challenge is that artificial intelligence is a term that has existed for decades, if not longer in the cultural consciousness from, you know, science fiction, for example. So you watch Blade Runner, right? And that isn't, that isn't what we're or whatever it is, but that isn't what we're thinking about or what we're doing.

Yeah, it's not, it's not at all. There's an essay I read recently by Michael Jordan from Berkeley, the statistician. And it was talking about how we're not even anywhere close to that. I forgot the name of the essay, but the essay isn't me. And it's a very fascinating, interesting read and I like it a lot because it really focuses on the major problems that we have ahead of us and the problems that we have to solve. Problems around infrastructure, like any kind of machine learning approach often needs robust solid infrastructure that can scale with it as the data scales. So focusing targeting on those kinds of problems and where the low hanging fruit in those areas are, those are the kinds of things that I've been thinking about lately and that fascinate me.

Yeah, fantastic. So it isn't necessarily about, you know, self driving cars and the self driving cars thing.

I get recruited very often. The recruiter emails about self driving cars and autonomous vehicles. Personally, I am not interested in working on those kinds of data sets. It's not Going to get me out of bed in the morning. I don't care about that kind of data. I care about data sets that I can reason from a human perspective about. I like that kind of, that I can use my intuition, I can basically leverage the ability of being a human to solve the problem even faster. So data sets that I know that this data set represents some kind of a capture of human activity, those are the kind of things I care about. And with regards to self driving cars, unless they're fully autonomous, I think they're actually quite dangerous because they lure you into a false sense of security. You know, it's going to be very, very difficult if you've gotten, if you have a car that's semi autonomous and you've been driving it for three or four years and you never had to engage and do anything, when that incident does happen, it's going to be very difficult for you to like, oh, remember to pay attention because you just learn to trust this vehicle. And those split second, those are the things that actually create lots of danger and I think makes it harder for the public to actually embrace new technology.

And I think a certain amount of education and dialogue around these issues and data scientists getting in the public eye and having this conversation with the public is incredibly important here, right?

Absolutely, yes. And then having them actually understand what we do for a living, what our work entails and the kinds of problems that we're solving and the kinds of problems that we can solve. Questions around data privacy, basically a data education. So the public has a very good understanding that if they give you data, what does that mean? What is that data being used for? Things like that.

Where would that data education take place? I mean, essentially in the end, maybe we'd want it in primary school, right?

Yeah, I think in primary school. So younger children are much more savvy. I have a middle schooler and he's very, very savvy around data and data sharing and issues of Internet privacy and all that kind of stuff. So they are on it, they are very, very savvy. They know exactly what's going on. It's the other people who have not grown up as digital natives who have a bigger chasm to cross in understanding what does this actually mean. And then beyond all of that, there are so many things now that we don't even have rules and regulations for or even have mental models of how to think about it because it's just so far out there that we've never really thought about it. Have you ever thought about who has access to your genetic material because it's never been, like a real thing. So it's like. But now it's a real thing.

Very much so.

Like, who owns that data? Do I own that data? These are the complex questions now.

Yeah. And I think you raise an interesting point about children and younger children being a lot more savvy. I think I remember a while ago you were on Hansel Minutes and you were talking about your child using the term physics engine and knowing what that meant at a very early age. Because they've been introduced to that.

Right? Yeah. I was like, whoa, Physics Engine. I didn't know what that was for a while. I was like, oh. I mean, I don't play video games, but yeah, like, they understand intuitively what a physics engine is and what the physics engine is going to help you do. The way they learn is so interesting because they've just grown up in the age of YouTube, so knowledge for them is not something that you have to go and acquire. The most important thing for them is figuring out the right sets of questions to ask because they just have the assumption that the knowledge is there. I just need to figure out what's the right query to pull that knowledge up and then I can apply it.

And of course, now that we have widespread education, in a lot of respects it can get a lot better. But we have a lot of education available online. As you say, it isn't about necessarily learning everything at school or having to move to a different city, state or country to go to the university and sit in the lecture hall. And we've got totally different models of learning that are evolving right now.

Absolutely. Absolutely. And the same exact thing happens for us, too. Machine learning is so. There's so much happening in ML and then ML research that it's so hard to just keep abreast of everything that's going on in the space. So you find yourself watching videos, reading papers, and trying to build your own versions of those models. And it's basically the same exact kind of thing. You just have to put yourself in the same mindset of the knowledge exists. What's the right question to ask? How can I replicate this experiment? What do I need? Those kinds of things. It's the same exact thing. You have to be in the mind of a child to. To do the kind of work that we do and do very well.

Yeah. Something we've been circling around and something you mentioned explicitly was data science ethics. Data scientists are not necessarily trained to be ethical in their jobs. They're not necessarily incentivized to be ethical at work. Do you think this is a problem and do you think we need to. All data scientists need to be ethically minded at work in some sense?

Yes, I absolutely think that all data scientists need to be trained around ethics, because the kinds of things we're doing today involve real people. And the repercussions if it goes well is amazing. We change people's lives. The repercussion, when it goes poorly, is devastating. So we need to have that ethical understanding, we need to have that training, and we need to have something akin to a Hippocratic oath, and we need to actually have, like, proper licenses, you know, so that if you actually do something unethical, that perhaps you have some kind of penalty or disbarment or some kind of recourse to something to say, this is not what we want to do as an industry, and then figure out ways to remediate people who go off the rails and do things, because people just aren't trained and they don't know. And it's so far removed. When you're working with large data sets, it's easy to just forget that those data sets eventually are going to be used by people. And you can be so distant from it that you completely forget.

Absolutely. And we need to be very rigorous in a lot of respects. For example, if you have a machine learning model, I think one of the famous ones is to predict recidivism rate, and you take out the feature ethnicity, you're like, okay, well, now we're not including ethnicity, but if you include postcode, then you're actually capturing a lot of that information already.

Exactly. It's highly correlated. And even asking yourself those kinds of questions and understanding the application of the mathematics, it's not just, yes, you have correlations, like, you know, just things like that, knowing that zip code is a good proxy for ethnicity, Just simple things like that, and then just asking yourself those questions. And I think as data science becomes more mainstream at the university level, I hope that there'll be a track that goes along with it, which is the ethical ramifications of data. In the undergraduate program at Berkeley, they actually have classes on the social implications of computing in one of the classes. That's a thing. And I would hope that that continues along the track so students can get exposure to it not just once, but every time they're in a class. Like, what is the social implications, positive and negative, of the technology I'm working on right now? Like, what is the best thing that could happen if my technology is successful? How can my technology be weaponized? What are the safeguards I can put in place to prevent that when such a thing occurs? And how do I educate people on what the affordances of that weakness or loophole in my technology is?

So I think education system is a great place for this. I think having a general reading list of, you know, people who necessarily aren't working data scientists, who are theorists or social scientists who think a lot about this stuff. I mean, Kathy o' Neill's Weapons of Math Destruction is a great book. A lot of the work that comes out of NYU's data and society group is really fantastic. But of course we see, you know, rules and legislation emerging in different places. In Europe we have GDPR now. And I'm just wondering, in your mind, where do these movements come from? Or is it a confluence? I mean, do we want the movements to be stemmed from data scientists from the ground up thinking about these, or directed downwards from legislators?

Oh, I would actually hope that we are the ones ahead of the curve, that it's not just the regulators. Regulation from governments. Regulation has its role and it's a good thing. The biggest challenge is oftentimes policymakers might not have the knowledge necessary to help craft the regulation. So perhaps they do it in tandem with the people with the expertise. And so maybe, you know, how it is in academia where somebody might go work with the NSF for like a semester or two, we actually should have something akin to that, where you take a leave of absence of six months or something like that, and you go work within policy in the government of the country you're working in. And it's just part of like the norm of what the work is. Maybe every four years, work in policy for six months. And it's part of like the requirements to have your license as a data scientist or something like that.

For sure. This is really interesting. This really promotes a dialogue between legislators, working data scientists, stakeholders in the community. What do you think the role of black box models and, you know, their counterpart interpretable models is in having this conversation across a variety of stakeholders?

There are some problems that black box models are very good at solving. However, depending on context, if it's going to be something that can really harm people, there has to be a way to investigate how you come up with a solution. Then sometimes maybe you don't necessarily throw away the black model entirely. Maybe the black box model helps you come up with a set of features that you use, but those features cannot really be translated in human language into this. I think the best approach would be to have an ensemble of different kinds. Like the black box model can help you triage and then eventually, on top of all that, have like a decision tree, some kind of hybrid of the two. But deep learning has given us so much, so powerful, we can't just throw it away.

Agreed. Something we've been circling around is how data science can inform us about humans. And I know that, you know, a deep evolving interest of yours is anthropology and the uses of data science for the humans. So I'm just wondering how you're thinking about this at the moment.

I think it's so fascinating because human beings, we think we have an idea of who we are and we have an idea of our own behaviors and our own biases and we often don't. Like human memory is so fuzzy. The kinds of things you can actually do sometimes when you think about all the stuff from cognitive science, how you can literally delude yourself into believing something that is completely false by firing a same set of neurons and creating this strong association. But if we can actually use data to help you understand your own habits and your own patterns, then you can actually use it to optimize yourself in a certain way. The thing that is very interesting to me is often I'll find people who are in science, maybe they're machine learning engineers and things like that, and we're very good at the craft, but we never actually apply it to decision making for ourselves. Like, we literally just do the work and we don't apply the same rigor into our own decision making. So I'm one of those people that would like to believe I do more of that. And so it's very, very, very interesting to have a good reckoning of what your strengths are and what your weaknesses and having data to actually give you the evidence that that is in fact the case and that is in fact true. And the question is, what do you do with that knowledge? But in my mind, you use that knowledge to make better decisions.

Absolutely. I love it. And I've actually started doing something along these lines recently. I'll tell you very briefly. I've started doing stand up comedy open mics recently in New York, where I live. And I've realized that stand up comedy, I can apply the principles of Bayesian inference to it. So yeah, when I write a joke, I've got a prior belief of how funny it is.

Yeah.

Then I have to do I have to tell that joke maybe 10 times in different settings to get 10 different data points on how funny it actually is for an audience. And I update my prior with respect to the likelihood generated by this data and then I have some posterior belief of how funny this joke actually is.

Exactly. Things like that.

Yeah.

And just realizing that as a human being, literally everything you do is an opportunity to experience and optimize some kind of data algorithm.

Yeah, absolutely.

Your whole life is just a chain of decisions from moment to moment.

And as you say, before decision making, though, there's a process of pattern recognition, classification and understanding of your own behaviors as well.

Yeah, yeah. And this is, it's fascinating to me because the lack of understanding of this is sometimes the reason why we have so many societal ills. It's a tricky thing to walk around because we don't even understand how the human mind works. The understanding that we do have, we don't apply it very well. The human mind is optimized for pattern recognition. If it didn't, we will not be able to function adequately. There's also the first fit model. Like the first fit is the best fit. You never question the second fit. If it looks like a chair, I'm going to assume it's a chair. You never question, is it actually in fact a chair? Because you have to triage so much information so fast and make decisions. But there are certain times where you want, like friction and you want to reconsider the decision you just made. Is it actually a chair or is it a piece of art? And then come up with the heuristic of why you believe it's something you should sit on versus something that you should look at.

That's a great example. So how did you get into data science originally?

This is one is a bit tricky. I think it goes back to how did I get into computer science? And I go into computer science because of the Internet. I was just fascinated by communication technology. The fact that you could just know whatever you wanted to know it. It just seemed like the world at your fingertips. And then as I continued down that path, I realized, I mean, I did my Master's years ago, 2002, and it was all about neural networks and all that kind of stuff. But this was before things like scikit learn Numpy Pandas. So writing those algorithms and CIF was not a pleasant experience. And then that we didn't have tons of data. So it was almost like we had all this knowledge and it was. We couldn't use it, the power was not there. So I kind of abandoned it and went from symbolic logic. But then I realized years later, oh, now we actually have the cell phones and we have Tons of data. And now is the time you can actually use all this knowledge, all that knowledge you've acquired years ago and you can apply today. And there are all these frameworks and tooling to help do this thing faster. So I just decided that the time was right. And so during my dissertation at Berkeley in computer science education, I collected all this data doing the data analysis and I just, it just, I was like, oh, I really, really love this because it's fascinating. It's just so fascinating. You could just keep on knowing more and more and more things about people through the things they can find in their data. And it seemed to me like the most interesting and fun thing to do. And I was just like, yeah, I guess this is what I'm going to do for the rest of my life. I'm very actually happy that it is a thing now.

And you're not merely a data scientist, but you specialize in machine learning. You're a machine learning data scientist. So what does that actually mean? And what's even the distinction there?

So the biggest decision that I see is that we have like data science is such a broad umbrella term, but data science encompasses decision support. So organizations like analytics often gathering data to support a decision versus shipping data products. So building data products, something like maybe like a learning a control system for an autonomous vehicle is a data product. It's not necessarily doing decision support within an organization. So it's just different uses of the same tool set. But on the machine learning routes, what ends up happening is you probably have vast more amounts of data and the kinds of approaches are very, very, they go further. I think that's the biggest difference.

I want to know what you actually do at GitHub, but before that I want to know what your colleagues think that you do.

I think so. People outside of machine learning often don't know what we do. They magic and it's not magic. We don't do magic. They don't have a clue. They actually don't understand. They know there's data, something happens, decisions get made somehow. So they literally don't have a clue.

Is that dangerous?

It's very, very dangerous because people think it's magical. They think that it's a knowledge that is so far out there that the gap between them and the attainment and understanding of that knowledge is too wide. And that is a very thing because it's not true.

And are there, for example, product managers that have more of an understanding than other people within the organization or.

Yes, we do. We have some amazing product managers we have one in particular that supports our team and he knows so much about machine learning because it's a voracious reader, but he is very rare, Very, very rare.

So now, knowing what your colleagues don't know about what you do, what do you actually do at GitHub?

What I do at GitHub is I build data models, often deep learning models on GitHub data to help GitHub. Probably build things like a recommendation engine so we can recommend repositories to people, do things around understanding security vulnerabilities in code, do things around figuring out what topic a repository is really speaking about. So that's the kinds of things I do. We build data products. So basically getting data, building a data pipeline, coming up with a hypothesis, building a model, if it's a predictive model, see how good you are at making the kind of predictions. If everything goes well, put it in an API and serve that API so that other engineers can use it and use it to support the GitHub platform.

This speaks to the machine learning side of things. When you're making product changes or anything along those lines, do you also do or does somebody at GitHub do online experiments to decide the direction of these changes?

We are beginning to start to have a team that's going to start doing that right now. Machine learning is very nascent to us. Machine learning is around a year plus. So we are at the beginnings of doing all of those kinds of things. We are not ready yet for full on online experimentation quite yet, but we do a little bit of that.

Really exciting times.

Yes, very exciting times.

We'll jump right back into our interview with Emoju Miller after a short segment. Now it's time for a segment called Data Science Best Practices with Justin Boyce talking about reproducible data analysis pipelines. What do you got for us today, Justin?

Well, learning from data involves taking a data set and performing a set of operations on it to ultimately get human, interpretable and actionable results like plots, parameter estimates and hypothesis tests. That sequential set of operations, which I'll refer to as a pipeline, really defines how you drew conclusions from data. If you want someone else to understand your analysis and deem your conclusions credible, it is essential that the pipeline is reproducible.

What do you mean by reproducible?

I mean that you, or importantly someone else, can understand and perform the steps in the pipeline. Another person should be able to take your original raw data set and perform the steps in the pipeline and get exactly the same results you reported without having you looking over the shoulder.

That's a pretty high standard though. How can you ensure that co workers or colleagues can achieve both understanding and exact execution?

Well, the exact execution part is the most straightforward. This involves making your code available so that another person can input the original raw data, hit a button and get the results. Version control software like Git enables you to tag exactly the code used in your analysis. You can make these tags available in your company, or if you are working more broadly, you can make them available to the whole world through websites like GitHub or Figshare.

What about helping people to understand what you did?

Well, that's a bit trickier. For this I like to make notebooks, which for many data scientists usually means making R markdown documents or jupyter notebooks. I like to step through my pipeline, often with smaller, easier to understand datasets, with graphics and explanations of what I'm doing in each step. This lays out the logic of the analysis.

Can you think of any good examples of this?

Ligo, the Laser Interferometer Gravitational Wave Observatory, famously observed the first gravitational waves in 2015. The LIGO team provided a Jupyter notebook accompanying their paper that walks through how they analyze the signal from the detectors to conclude that it indeed came from gravitational waves.

So what does a data analysis pipeline look like?

Pipeline consists of well defined steps. The first step is validation. Write tests to make sure your data source is giving results. It should. For example, some students of mine were analyzing fluorescence data from an instrument. Some of the fluorescence values were negative, which is physically impossible. They discovered this in the validation phase and then called the manufacturer of the instrument to see what was happening. So validation is key if you want the rest of your pipeline to work as expected.

That sounds like something you should always do.

Yes, validation should be at the front of any pipeline. Now, after validation comes tighting and wrangling of data. This involves transforming the raw data from your data source into a more usable format. Then, after your data set is ready for use, you can start making relevant plots of your data.

A lot of times that's it, right? You get informative plots and that's enough to get at the human interpretable and actionable results that you're after.

Yes, that's often the output of a pipeline, but you often want to do statistical inference or apply machine learning techniques to the data. These are also sequential steps that you should have cleanly coded up. It is also important that they are clearly explained in your accompanying notebooks so that other people understand what you're doing.

You're describing the pipeline as a linear process, but really there's some iteration as you're working with a data set, right? I mean, you try different plots, different statistical models, things like that. Where does that iteration fit in?

Yes, that's definitely true that analyzing a data set is an iterative process. The pipelines I'm talking about, those are the final product of your analysis. As you're iterating through different approaches, you should document all of those modes of analyzing your data. You might even want to include discussion of various approaches you tried in your notebook that discusses the logic behind the final pipeline that you came up with.

Okay, so this all seems pretty straightforward. Cleanly code up your final analyses, share the code, and have documentation that clearly lays out the logic. Is there anything else we should know about reproducible pipelines?

Well, there are lots of other considerations, like seeding random number generators in your statistical or machine learning based analyses, recreating exactly the same computational environment that you used with tools like Docker, how to effectively share large data sets, things like that. But if you're a data scientist and you make your pipelines clear and available as I've described here, you are well on your way to doing good reproducible analyses.

Thanks for that, Justin.

It's always a pleasure, Hugo.

Time to get straight back into our chat with Emoji Miller. I've heard you describe what you do, and we're speaking about this already, but specifically is you use computation to build products to solve real life decision making practical challenges. And I'm wondering what practical business challenges does GitHub face that data science can help to solve?

A very interesting. So one of the things is a lot of open Source is on GitHub. Open Source oftentimes is looking for contributors, people to contribute to the open source repository and the maintainers sometimes get overwhelmed. So one very simple thing is perhaps there's an open source library you really like and you use it all the time and then you realize, oh my God, this thing is missing from this library. Maybe something like Pandas. And then you just automatically go to the Pandas repo and you open an issue. I see that when I do this and that this XYZ happened, wouldn't it be great if you could fix this for me? So on and so forth. Open an issue, leave the issue in the repo, right? There might be other issues that have basically said the same thing. So when the maintainer comes to that repo, triaging all those issues becomes a very, very big challenge. So that the challenge of triaging and finding duplicates and what has been open and what has been closed, what's the most relevant, all that kind of stuff, just doing all that decision making around that is a major problem and that's a problem that can be solved with machine learning.

That's fantastic. So I'm just going to stop you for one second and kind of reiterate what you've said, that this is actually one of the biggest challenges in open source software development. There's a huge rate of burnout in developers who are doing a lot of this in their own time after working their full time jobs, taking time out from their to do this. And it's a huge challenge faced by the community at large how to even think about package maintenance, especially with the expectations that come from the user community.

Yes, we the users, we are, we are. So we, we want everything now. So I saw it recently and I was literally aghast. I was like, oh my God. So I think it was like matplotlib, numpy and maybe pandas or something. Like those three scipy packages for data science pretty much are maintained by 15 people.

Yeah, I saw that as well on Twitter.

It was like what? It was like three of them. Five. Five people each. I was like, what? And the number of people that packages orders of magnitude. Yeah, millions of people. Yeah, five people.

I was just gonna say hopefully those five people are never in the same room at the same time.

Exactly. It's insane. It's a machine learning problem. If as a maintainer you can come to GitHub and I've already triaged all the issues for you to let you know. All right, maybe you have 10 contributors. The 10 contributors are available right now and I know what their skill sets are. I could say contributor number A will be great for issue number B and match them because I know that this contributor can close these kinds of issues very, very fast. I can just match them automatically for you. I can basically get rid of all the dead issues, like the things that we won't fix because it's just out of our control or it's not on our roadmap. I can come up with all the duplicate ones. I can find other issues on the platform that are from other repos that look like your issue that have been closed and figure out what the solution was. These are all the things that can just help you. Maybe then those five people then become like an army of 300 because they are powered by machine learning.

That's fantastic. And I actually this, this speaks at automating certain things. Which people do constantly and takes up a lot of time. When I spoke with Jake Vanderplass on, on the podcast, I asked him how he got involved with SciKit Learn. And he'd written. I'm not sure whether it was PCA or he'd written something to help him in his astronomy research. And he. And he'd emailed the SciPy users mailing list or something like that. And eventually someone from Psychic Learn, I think it was Gail, said, hey, why don't we put this in Psychic Learn? And that's how Jake got involved in Psychic Learn. But that took a period of time and a lot of human hours to figure, figure that out. Whereas your, what you're speaking to is developing machine learning automated systems that do.

That work for exactly that do that kind of work for you to just take the pain out of it. Like, what's the point? You have a repo, you need main. You need contributors, you are a maintainer. What can we automate a way to help you get your two, three hours that you're committing to this every four or five days as meaningful as possible. So you're not spending those three hours just like, oh my God, all these issues. Triaging the issues. Triaging issues is a big deal. Machine learning can triage the issues for you.

So you also think a lot about building data products and you build data products. Is this the type of thing that you'd consider a data product at some point?

Oh, yes, absolutely. Everything I've just told you is. Bunch of APIs.

Okay, great. What other types of challenges do you think about? Or is GitHub interested in that machine learning can help with?

One of the things that I am so excited about is actually gaining deep understanding of computational competencies, like actually understanding the kinds of computation that we realize in code, understanding the complexity of a code base, building things towards like just doing, getting to the point of doing like automated code review, giving you some kind of thing that maybe you can plug into Atom, that can go through your code and tell you all the kinds of things. Like imagine a lintel on steroids instead of just finding all the PEP8 errors, but can tell you like, oh, I see you using this pattern over and over again. Refactor, refactoring it for you, like highlighting things. Imagine if you can actually look at. Imagine when you're entering a new code base. A new code base can be so large to just like two. Like, where do you even start reading this code base from? What if there's a visualization of that code base As a tree, a different path they can go to, and that tree can then expand and contract based on the kinds of things you need to go down on.

Awesome.

Just like tools to visualize knowledge, computational knowledge, so you can get what you need to get out of it very, very fast.

Yeah. And something you mentioned in passing earlier was detecting security vulnerabilities in code also, right?

Yes. Detecting security vulnerability in code. It's a major thing. What if we can go through your code and find the security vulnerabilities? Number one, we already have a service like this that will alert you if you find certain vulnerabilities in your code. So you know what it is. Then the next part would be, what if we can tell you what to do to patch that security vulnerability like we found it. Now, here's the patch. The next level is what if we can actually write the automated pull request for you that we've found it, we've written the solution for you. All you got to do is hit merge. These are the kinds of things that will save so many human hours and more importantly, has such a major implication on society. Lots and lots of data breaches have so many deleterious effects. All the people that have been affected by the. Is it Experian breach, all these kinds of things. If we can automatically see that, oh, my God, I've seen that you've committed an AWS key on a public repo, like, just alert you before you even, like, push it, like, stop it, like, you know there's a violation here, Things like that.

That's fantastic.

Simple things that just make you sleep easier at night.

And I know a lot of people, including myself included, use GitHub really as a way to share code, to collaborate on code and to discuss code. But I know that in your mind, GitHub is a far larger ecosystem than this. And I know that in particular, you also view it as a social network of sorts.

Oh, yes, I use the social coding. I use the social coding aspects in GitHub. When I was on campus at Berkeley, it's easy to collaborate with people or to know what they're thinking about. Even if you're not collaborating with that, like your buddies, what are they thinking about? It's easy for you to do that because you all sit in the same lab. When everybody graduates and goes on and does whatever it is that they want to do. By following them on GitHub, I still have a way of knowing what they're still interested in. So I can go and look at my friends and I follow my friends on GitHub and I'm seeing the repositories that they're starring. Oh, I'm seeing this person is interested in crypto. I'm seeing this person is now interested in this version of like a node. JS I'm seeing, I'm seeing all this person that was totally into front end design is now starting things that with machine learning. So you're like, oh my God, you know, they're now into machine learning. You can hit them up and be like, so what are you thinking about doing? I see that you start all these people, you know, so it's like an opportunity for you to like keep in touch computationally of what people's interests are.

And to see people what are what, what people are committing to. And even as you said earlier, let's say you make a contribution to SciKit Learn, for example, you know, you may get a message saying, hey, if you made that commit. This is something similar that's raised in an issue on, you know, stats models that you might want to have a look at.

Absolutely. Exactly. Exactly like true it. Sometimes I look at my dashboard and I know who's going to what talk. I see they're already preparing their talk. I mean I can see everything that they're doing. If it's public, it's there and it's so interesting. And I also use it as a form of discovery because there are so many open source projects too much for you to consume that your friends can almost serve like a sort of triage to figure out what is hot and what are they staring in common and things like that.

So You've also described GitHub as a platform for work and not just technical work. And I'm really interested in this. You've told me that everyone who works within GitHub, even non technical people, use it for communication. And you've described it as a collaborative work, work environments centered around humans. How do people use it who aren't technical and not writing code, for example?

All right, so I will start off with my use of it, my non technical use of it. So I keep a blog. I have not updated my blog in a while, right? And my blog is a Mac down. So when I want to write a new thing and I'm just writing ideas, I literally like write it in Mac down and commit it to GitHub. So I can just have like a. Basically it's my own version of how I write text. I just, even if it's not marked down, it's like regular English. I'm Just writing it there. And I'm just coming into GitHub. It's just my own version of I guess, Microsoft Word, because I don't like the Microsoft Word. So I just write in whatever free text editor and I just commit it to GitHub, things like that.

And it pushes directly to your blog?

Well, yeah, it pushes to the blog because I'm using Jekyll and all that. But even. But just putting ideas down and just keeping all those ideas together. So I use GitHub. I use the GitHub platform to help manage writing my dissertation. So I'm writing this dissertation. I'm like, I wrote the dissertation using latex. I'm just like committing everything to the GitHub repo. And that just gives me peace of mind just in case something I wrote a while back that I decided I no longer want, I can roll back to that, commit. I can go all the way back and be like, oh, 10 months ago, what was I thinking? Oh, there it is. This was the state of the dissertation. This is what's going on. And I like to do that. And then also I like to look at some of the insight to see my velocity so I can no longer deceive myself. If I'm working on something and I'm not working on it, it's very evident I did not work on it or I worked on it. That's just from a perspective. But things like, I know people use GitHub for coordinating work. People use GitHub for crisis response. They will open a repo and the repo may be around. How are we going to coordinate all our resources together so that when, let's say a hurricane, once the hurricane passes, how do we collect all the things we need and all that stuff? You can open a repo and use that repo to track all those kinds of things. You can track it using issues. Just search for this issue and it's going to have the thread of all the information of this is what we're thinking. It's basically a way for us to capture our thoughts and paper. We can always go back to that issue and see this is everything we wanted to do. These are the things that we did. They can go back and see where did we go wrong. You can almost go and do like your. You can debrief and go back to all those issues so you can see everything and the conversations and the people who participated and what they were thinking about. So opening issues is one of the ways that GitHub uses GitHub non technically just coordinating because GitHub is also distributed. So certain conversations are just better kept in an issue. So we have the record of the entire thing. And there's a repo for everything. There's a repo for the finance team, there's a repo for the legal team, there's a repo for the machine learning group. So it's not just technical groups. Everybody has a repo. Everybody has like, open an issue in the repo. If you want to do this, we'll have a repo. Open an issue in our repo. We'll get back to you, things like that.

That's awesome. And I think that the fact that history is always preserved in GitHub speaks to like you close an issue, but it's still always there. And the fact that you have versioning around everything means that you have a history of everything if needed.

Literally you have a history of everything. So when somebody gets onboarded and they're like, okay, so you're here to do xyz, you can actually see the history that's happened before you got here to see where all the conversations went and then you could take it from there. It's a collaborative work platform. It just so happened that the first major use case was around computation.

And I've actually, I can't quite remember the details. I've definitely used infrastructures and plugins that allow you to visualize issues. Maybe one's called Zendesk, which allows you to track issues and drag and drop them into particular places to see which stage they're at.

Oh, yes, yes, yes. We actually have our own product, like a project board that you can just use within GitHub itself and you can create different verticals and you can drag and drop issues and things can be closed automatically. You can have your Slack integration and all that kind of stuff.

That's really cool. And do you see this becoming more and more a broader use of GitHub as we move into the future?

Absolutely, yes. I hope so, because having used it in this way, it's. And I started using GitHub this way before I actually got to GitHub.

Yeah, that's really cool.

Just seems like a natural way to do things because it's like several products on the same platform. You don't have to keep jumping from one thing to the next. It's the same that can do all that for you.

So I want to talk about accessibility of Git for a second. And what, what I mean by that is, I mean, I've taught Git in various places and I know that you're very interested in education. One thing I've always found, Git is incredibly difficult to teach for a number of reasons. GitHub has made it a lot easier, I think. But one example is I try to motivate Git and tell people that versioning is important. Then I'm tell them that, oh, we're using Python, so let's use Jupyter notebooks. Right. So there's an inherent challenge and barrier to entry for git. So how do you see this progressing as we move into the future?

As we move into the future, we have a lot more to do to actually abstract away a lot of the pain points in Git and create. I think one of our killer opportunities is the GitHub desktop app. I use the GitHub desktop app probably 90% of the time.

As opposed to using your Unix shell?

Yeah. As opposed to using Terminal. Because the app I make less mistakes because there are so many things that are evident to me. I automatically know what branch I am on. It is right there. I don't have to worry what branch I was on. The branch may not be there. I can see that. I can see my divs visually. I can see the difference. I like going back into the history in the GitHub desktop and actually going through it helps make it slightly easier. As that app becomes better and better itself will become the learning tool then also GitHub, we just launched something recently, the GitHub Learning Lab, which is a bot that is on the GitHub site itself that will teach you how to do all these things. We are beginning to build all these learning tools to help people cross over that chasm of Git. It's not all the way there yet, but we are nowhere near where we were three, four years ago.

Great. Has the Learning Lab gone live in some form?

It's live. It's already out there. People are using it. They've already built several courses and they're using it.

That's great. Well, we'll definitely link to the Learning Lab in. In the show notes.

Yes, absolutely.

So you spoke to a really interesting principle in terms of saying GitHub for desktop, you can use it visually. And I think thinking in terms of design principles, of products, essentially, if we're a lot of the time forcing people to use Terminal to interact with such systems, we're losing a huge portion of the population. Right. People who actually prefer to do things visually.

Yes, people who prefer to do things visually. And then also one of the easier ways to do things, one of the benefits of doing things visually versus by typing or reading is that pictures are not necessarily as language dependent. So if an arrow is pointing to the right and it's saying something like go from left to right, that arrow saying left to right, or the symbol of a bathroom or something at an airport, it is a universal, it is not language dependent. And because we are sitting in San Francisco and we are often English speakers, we are so tied to the English script that we don't leverage all the other things you can do without language, without using text based language. So I often would rather default to a visual medium. What is the visual way of doing this thing before even thinking about anything text based.

Interesting. That actually made me think of something. I had Greg Wilson on a colleague of mine whom you know and who is well known for his original work with the software and data carpentry. But he's very provocative in a lot of respects and he made a statement that he thinks the future of data science in decades may be people using Scratch for data science.

Yeah, why not? Why not drag and drop.

Exactly. So you think that's a viable future as opposed to us writing code in Emacs or whatever it may be?

Yes, because what is the problem you're trying to solve? Maybe you're trying to build a thing that can give you like ranking, like that is the problem we are trying to do prediction, for example. Do you honestly care what way you use to solve the problem of prediction? I don't think so. I think you care about solving prediction. Tying yourself to one medium makes no sense. If there's a medium that is easier and faster and less error prone, why not adapt to that medium? It has nothing to do with the solution to the problem. It is just the afford, it's just the way you're realizing the solution. We don't need to tie ourselves cheek to jowl to only one form of realization of a solution.

I agree. And this is actually why I have such an allergic reaction to the language wars. When, you know, aspiring data scientists, for example, say to me, oh, which is better, Python or R who cares? And I immediately say, I say, who cares? And what are you trying to do? Let's talk about the problem you have and see, see where we go exactly.

What is the problem we're trying to solve? What is the best tool for that problem? And then let's do that. And then in certain kind of environments you have to ask yourself, how will this thing scale? Maybe one language is easy for you to just build a prototype and you use A language that is easier for you to prototype, maybe another language is better for you to actually build a full scale applic production use that. It doesn't matter. I think we are eventually going to start moving more towards automated tooling and things that are like drag and drop and they are not as language dependent. And there will always be an API that you can call and still connect back to Emacs if that is what you want to do.

Great. And I think this also speaks to something that I know you are deeply invested in, which is lowering the barrier of entry to these types of things.

Absolutely. What I'm design, who I am designing for, my perfect person I'm designing for is that person that has a solution in their head of like, oh my God, there's this problem and I could see this solution, but I can't code. Right. There are so many people who fall into that bucket. What if with the assistance of intelligent agents powered by machine learning, we can help those people realize a prototype of their solution so they can at least get the proof of concept out there and if the thing has legs, then they maybe can go raise money and then hire engineers to build a full on computationally robust version of that prototype.

What does the future of data science look like to you?

I think it will still exist, but it's not going to exist in the way that we think it is now. It's going to be more of like a real discipline with so many branches. You have decision support, you have some versions, which is optimization, you have ethics, you have things that are like linear algebra on steroids, like numerical computational methods. It will be all these kinds of things, but we'll have deeper understanding of what it is. When you think of data science, it will be like, oh, I am in medicine, right? And then you say there'll be people who will be like practitioners, who are like internal medicine practitioners, and then there'll be people who will be like oral surgeons or people who will be like cardiologists. There'll be all the specializations and it'll be a discipline with like a committee or boards of like saying, okay, this is what it means to be this kind of data scientist. This is kind of knowledge. More importantly, this is the kind of knowledge you need to be able to solve these kinds of problems. So if you're interested in this kind of problem, this is the path that you go down. Because right now we don't really have that.

No. And we have a problem then with career paths and even job listings. You look at job listings and it's like we want 10 years of experience with distributed computing and five years of, you know, statistical inference and these types of things. I think it promulgates this stereotype of the unicorn. Existing specialization will be a restorative force.

There will be a restorative force because what do you need 10 years of distributed computing experience for? What are you trying to solve? Like, you know, and a lot of these things is like over the top. Some of the things that they're doing, you probably can write an SQL script. You don't need learning for everything. And some of this stuff you don't need this. And then some other things you're like, maybe you actually don't need a machine learning expert. Maybe what you need more as a data engineer, some problems are just pure infrastructure problems. They don't require any kind of extraordinary numerical computational methods. It's more just infrastructure. There are things that like, oh, this is truly the bleeding edge. You really need advanced computing and you really need advanced numerical methods to understand the, the space of hypothesis. You know, just we don't have a lot of that kind of stuff yet.

We haven't got too technical and I don't want to. But before we end, I'd like to know what's just one of your favorite data sciencey techniques or methodologies, Just something you love to do?

You know what I love to do? I really like exploratory data analysis. I actually like that stuff a lot. I don't even get to do it as much as I would like to because I have things I need to build. But I just like true data.

It's a lot of fun, isn't it?

Yeah.

And I like creating my pretty pictures.

Yeah, that's playful. Playful.

It's playful. That's the thing. It's actually just playful. It's playful.

It's like a first date or it's like the first few dates. Right. When you don't know someone. Yeah. You're discovering things always.

Yeah.

Yeah.

I really like that because I think it's interesting for sure.

And something you, you mentioned to me last time we spoke and this is something I've been thinking about ever since actually is that reading code is, is so important. So if you want to like think about how like go and read the code Jill Loop wrote for Psychic Learns Random Forest. Right. Like, how much fun is that?

Yeah, I really like doing that. I love doing that and I like to read the. So like I would like to read the person's dissertation, like understand how they write in English and Then go see how the writing code.

You actually said something to me that stuck with me. You said to me, you know, you don't only learn to write by writing, you learn to write by reading a lot.

Exactly. So just read that and you can.

Think about that in terms of code.

Yeah, Try and read tons of code and just go through it. Instead of thumbing through Instagram, read some code.

I wonder if there's some sort of Instagram for code, like some product you could have in GitHub. Right.

I know we're totally getting nerdy, but that would be so awesome because what I would love is understanding after understanding how the human mind works and how the brain works and how the human brain actually acquires computation. Like there's so many ways to game it and to become a master at certain kinds of things.

And I just want to circle back to a comment you made that you love exploratory data analysis or eda. I just want to say that's really heartening to hear from a machine learning data scientist in particular, because, you know, a lot of aspiring data scientists say to me, you know, what's the best model to use on data? And I'm like, what are you talking about? What does your data look like? Let's actually spend a couple of hours just looking at your data to get a feel for it, to understand its contours and its dimensions. Right before thinking about, you know, throwing blended extreme gradient boosting at it.

Exactly. And the what is the best model for your data? Often the simplest thing will do if you have lots and lots and lots and lots of data.

So emoju, do you have a final call to action for all our listeners out there?

Yes, one that is quite self serving. GitHub is hiring. GitHub infrastructure is hiring. We are hiring in machine learning. So look at, look at the career pages and we'll put it in the.

Show notes as well.

Yeah, and the only other call to action that I have for people is to actually challenge yourself to learn like this. Machine learning is not magic. It is basically mathematics. It's applied mathematics. And if you really want to understand it, take the time required. It might take you two years, it might take you three years. It's absolutely worth it because this is the future and I want more people to have an understanding of what it is so they can ask stringent questions of us and keep us ethically sound and force us to actually use our knowledge to create solutions to the problems that they have, because they will know that we are able to do X, Y and Z. They know what our capabilities are and they can hold our feet to the fire and say, I want to fund a company that does X, Y and Z. This is the fund is dedicated to this, so it forces us to go build the solutions.

Thanks Emoju. It's been such a pleasure having you on the show.

It's been absolutely a pleasure, Hugo. Thank you for having me on the show.

Thanks for joining Our conversation with Omoju Miller about machine learning and product development at GitHub. It was so refreshing to get Emoju's unique take on the role of platforms such as GitHub in facilitating the human endeavors involved in collaborating on code. The productization of features such as security vulnerability detection in code is amazing, but think of a future in which pull requests solving these issues are automated. Emoju's vision for automation of so many of the processes in open source software development, from detecting duplicate issues to matching contributors to projects, repositories and issues, heralds a future in which so much of the drudgery is removed, allowing developers to focus on what they do best, the fruits of which we'll all have access to. And don't forget that we're trying something new this week for data Framed 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. Also, make sure to check out our next episode a conversation with Taras Gorishni, a senior analytics manager at McKinsey and head of data science at Quantum Black, a McKinsey company. Taras and I will be talking about the role of data science in management consulting, what it takes to change organizations through data science, how the different moving parts of data science have evolved over the past decade, and in which direction they're heading. I'm your host Hugo Bown Anderson, and you can follow me on Twitter hugobown and datacamp@datacamp. You can find all our episodes and show notes@datacamp.com community podcast.