#132 The Past, Present, and Future, of the Data Science Notebook

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 when something's put into production, it's not a dormant thing, it's a living thing. And when systems go down, someone needs to be responsible for it. So if you have a machine like an algorithm writing the code that is then your production code. Who owns it? Who understands it? Who's responsible when it breaks foreign.

Hello, welcome to Data Framed. I'm Adele, Data evangelist and educator at DataCamp and data framed is a weekly podcast in which we explore how individuals and organizations can succeed with data. Today we're speaking to Jodi Burchell, developer advocate at JetBrains. If you've been in the data space, even if it's been for a short while now, you probably know that Jupyter notebooks are a pretty important aspect of the data science eco ecosystem. The concept of literate programming, or the idea of programming in a document, was first introduced in 1984 by Donald Knuth and notebooks are now the de facto tool for doing data science work. Heck, even datacamp has datacamp Workspace, which is a cloud based managed notebook environment aimed at users of all types. To bridge the gap from learning to application and help teams Collaborate at scale, JetBrains has Datalore, a notebook based IDE aimed at data teams. So I wanted to speak to Jody about the state of the Jupyter notebook today, its past, and more importantly, where it's going. Throughout the episode we speak about the notebook landscape today for data professionals and teams, the challenges teams have that led to the innovations we see in the tooling space today. What large language models in ChatGPT mean for notebooks and the data profession in general, the nature of tooling, fragmentation in the data space, how to become a developer advocate, and a lot more. If you enjoyed this episode, make sure to subscribe to the show. And now onto today's episode. Jodi, it's great to have you on the show.

Yeah, I'm super excited to be here, so thanks so much for having me.

Thank you so much for coming on. I'm excited to speak with you about the state of the data science notebook. Your work at JetBrains as a developer advocate the tooling needs of modern data teams and more. Can you please give us a bit of a background about yourself and what got you into this space?

Yeah, so I have maybe in some ways a kind of typical background like I'm an ex academic but I didn't do a PhD in physics or machine learning. My PhD was actually in clinical psychology. So the way that I kind of went from psychology to data science is in Australia. The way that we teach like psychology is a behavioral science so you have to do like a ton of statistics and research methodology units and most people hate them. I loved them. So basically completely fell in love with statistics, which not really something you hear that often. And when I finished my Ph.D. i took on a postdoc in biostatistics. And then when I realized I didn't want to be an academic, data science was actually just heating up. So I had really good timing and yeah, basically started my data science career. Been doing this for about seven years and yeah, like few different areas, mostly natural language processing, but I've worked across like a whole bunch of industries so it's been amazing. Very interesting. And yeah, the latest move has been to developer advocacy.

That's really great. And we're definitely going to unpack what it means to work in developer advocacy. I work in developer advocacy in a lot of ways as well. So it's really nice to meet someone else who's in the same boat as I am. So let's talk about that at the end of the episode. But first I want to get into the meat and bones of today's episode and talk about really the state of the data science notebook. I'd love to set the stage for today's conversation by really trying to understand where the data Science notebook is today. In a lot of ways, the notebook interface has been around here for decades. The concept of literate programming, or the idea of programming in a document was first introduced in 1984 I think by Donald Knuth. A lot of innovation happened since. Right. The Jupyter notebook was released in the early 2010s and today we see an explosion of notebook based IDEs, collaborative notebooks. So I'd love to first understand from you, Jodi, how have you seen the Jupyter notebook ecosystem evolve over the past years or the past decade?

Yeah, and it's actually a bit scary to say. I do remember when Jupyter Notebooks came out, I actually started my data science journey in R, which I guess is unsurprising because my background was so statistical. So I got my first taste of this sort of literate programming environment with R Markdown scripts and they blew my mind. They really just felt so much more intuitive and cleaner to me for the research process than trying to use straight scripts, which always just felt like a compromise for me. So I think this is probably a pretty common feeling that a lot of academics or ex researchers would have when they start using Jupyter notebooks or R Markdown. Notebooks used to be basic, like really basic. And it's really cool, I think, to follow along the journey and see how much richer the notebook ecosystem has gotten. I think especially in the last, I would say three to five years, things have really changed a lot. I think really the biggest change I've seen and was a much, much needed change was the move from notebooks from local to remote. So we've seen this kind of explosion of managed notebooks. We've seen Jupyter Lab, of course, which has been like a real revolution. But a lot of companies, including my company, JetBrains, have their own solution and of course Datacamp has their own solutions. So some of the most famous ones are AW SageMaker, we've got the GCP and Azure managed notebooks. Got Colab, of course, and we've got Data Law, our product. At Jetbrains, we've got the ability of IDEs to now connect to remote servers really easily. So Pycharm and Dataspell, again, JetBrains products can do that. And then of course Datacamp has their own workspaces. So it's like a lot. And I think this move to remote has really opened up a lot of possibilities for seamlessly developing more complex models straight from the notebook environment. You don't need to do anything special to run your, say, a script on an EC2 instance or something like we used to have to in the old days. Yeah. And I think also when you move to remote, it makes accessing increasingly bigger data easier, so you can basically connect to databases that are stored on aws. If your notebook is hosted on aws, it's much easier. I think other interesting things is notebooks have really become a direct launch pad into production. This is a new area, but one of the first ones I saw was AWS SageMaker prediction endpoints. It's an interesting area. I'm not saying I'm going to entirely agree with notebooks to production, but it's an Interesting idea. And then, yeah, I think it's even basic stuff that a lot of software engineers would take for granted that we never had in notebooks. Things like code completion or introspection, debugging. So it's amazing what a notebook is now compared to when I started using them quite a long time ago.

That's really exciting. And there's a couple of things I want to harp on here. From what you said, you talked about when you saw the introduction of IPython Notebook, it wasn't in the data space at the time. I'd love to understand how was the rate of adoption at the time, because what you mentioned here is really the magic of notebooks is a lot of ways is in the interface. And this reminds me now of ChatGPT. Like the interface of the chat interfacing with a large language model is the reason why it's so adopted in such a quick time. How has the notebook interface contributed to the rate of adoption at IPYTHON at the time of release? From your memory?

Yeah, so I can really only speak anecdotally, of course, but this was during my postdoc, so I remember a friend of mine sending me this and saying, hey, have you seen these IPYTHON notebooks? They look super cool. And I'm like, oh yeah, they look similar to what I'm using in Ring. And I do remember I had friends who were particularly working in biomedical engineering and things like that. They really talked to the notebooks and it became this word of mouth thing where people were like, oh my God, have you seen this amazing new format? So yeah, it was, I think, a lot of positive feelings and adoption among the Python users that I knew.

Yeah, definitely the interface plays a big role. And you mentioned as well kind of how notebooks have made it much easier to work on data science projects and to get to models much faster. One thing that we've seen as well, like with the collaborative notebooks and cloud based notebooks, is that the rate of adoption and like from learning data science to doing has been also much higher. Like the ability to just open up a colab or any kind of cloud notebook environment and get in is really wonderful in the education sense as well, because I was writing an article recently on how to install Python and I'm still surprised at how relatively difficult it is to like manage different Python installations and versions on your machine. And if you're a total beginner, that's also like a pretty difficult endeavor. Right. It will bog you down in your learning journey.

Yeah, I think this is Actually one of the most powerful things about these managed environments that it's. So I have like a real maybe passion for reproducibility, probably coming from a psychology background where that was quite a problem. So it's a really exciting thing when you have a managed notebook. And again, data law is the one that I'm most familiar with. It's this thing where you basically have a one to one relationship between a notebook and an environment. And because it's containerized, it's a Docker container under the hood, basically everything is reproducible. You start up your server again and all of the same environmental dependencies get reinstalled. And for beginners this is so much more approachable because they can get straight to all the fun stuff and they don't have to deal with all this overhead, which is not so fun.

Yeah, agreed. So in a lot of ways the innovations that we're talking about in the notebook space arise from the challenges encountered by data teams over the past few years. What do you think are some of these tooling challenges that data teams have faced that led to the rise of this modern ide, modern cloud collaborative notebook?

For me, honestly, one of the biggest challenges, and I really saw this when I was going through my data science journey, is access to resources. And as the size and complexity of models grows, especially with the increasing use of deep learning compared to just classic machine learning, you can't reasonably fine tune something like BERT or GPT on your local machine. It's just not going to happen. So that I think is one major challenge that notebooks really needed to rise to. I also alluded to this, but data has grown as well. The volume of data that we're expected to deal with is enormous. And I think increasingly data scientists have had to move away from the CSV on my local machine to working with these huge remote data sources. And databases are obviously a huge one. So having good database tooling and like the ability to actually see what's in your database and like even plan queries and things like that can actually be a really important thing to add into your jupyter notebook. Spark. So we've actually seen a new kernel come out which is Spark Magic Notebooks. I love them. Use SPARK a bit and I can say setting up a Spark session yourself is not very fun. So having the notebook take care of it for you is wonderful. And then like some other things are collaboration because we're moving to a remote first world. I, I think a lot of tech companies are saying that a lot of people do not want to come into the office all the time. But then that means if you've got a team of data scientists, you want them to work together on the same project, they're going to need to collaborate. So there's been changes to notebooks to deal with that and then yeah, finally the reproducibility thing that I already talked about. So plenty of changes.

Yeah. And this definitely speaks volumes over how fast the space is evolving as well. I think one major thing that we've seen the notebook take place in and really provide value for organization, which is a challenge that organizations have faced for a while, is the need for democratized insights within datacamp. Notebooks and workspace notebooks especially have become more the de facto way to read data insights within the organization because people who have business analyst skills, for example, are SQL based people can use a SQL node like SQL cells, visualizations are easily serviceable and that report interface makes it easy to gain access to insights. Walk us through how the notebook as well has evolved to accommodate that need of democratizing data insights and being able to publish reports within the organization.

This is such an interesting topic. So in my past roles I've worked really closely with non technical teams, sales or marketing. And it's a funny thing that non technical people see code and their brains just instantly like go. This is not for me, like it's not that they couldn't understand it, it's just that it's not part of the usual workflow. So what I've actually found is you cannot present just a notebook to people in these roles. It's fine for people who are used to code, but people who are not do not welcome it. So a nice thing that I've seen coming up with notebooks is changes that allow you to switch between this development and presentation mode. A really basic one is in Jupyter you can just hide cells so you can just hide the inputs and you can just show them the nice graph. And I think there's also been an increasing move towards pivoting reporting off notebooks. So again I'm going to spruce Data Law. I'm probably going to be talking about my products a lot because I get very excited about them. But datalore has this ability to build like actual dashboards off notebooks and to me this is cool as well because one of the big challenges you have is okay, you've done your analysis, you spent a lot of time on it, you just need some feedback from someone in the business. You don't want to then spend like a day making a PowerPoint slide deck, presenting it to them, then going back to your analysis. So it's much quicker being able to pivot straight off the notebook.

Yeah, I completely agree. Like GUI interfaces within the notebook as well, to be able to provide democratized insights within the organization is so crucial. And it's such an interesting space and aspect within the modern notebook environment because it does signal to a certain extent for me that there will be some portion of the Excel crowd, like the highly technical Excel crowd, that will maybe adopt notebooks down the line, especially as that GUI interface becomes stronger. So something though, like Fritsch switching here from the aspect of the modern notebook to kind of the more data tooling space in general. Something that I've been following pretty closely is how the data tooling space over the past few years. Right. Has become extremely fragmented. We've seen over the past few years the rise of new category of tools, the rise of MLOps tooling. There seems to be extremely limited consensus within the data industry about what constitutes a de facto data stack. So I would love to hear your thoughts on the state of fragmentation and data tooling today. Where do you think we'll be in a few years in comparison to today?

Yeah, so this is actually something I thought about from a different angle. I thought about this a lot. So I came into data science from a non engineering background and for me engineering tools are still not my tools because they don't work with the way that I think. And I feel like this fragmentation that you're seeing, that I've seen as well, that you've observed is actually based on a fragmentation of the field. So I think data science 10 years ago was a bunch of academic refugees and they were all just working like research scientists back when they were academics. And now we're seeing a lot more diversity in the background of data scientists and you're seeing a lot more people with engineering backgrounds. It could be up to 50% based on surveys I've seen. So I think that means that the tooling needs and the tooling approaches and even the place where they sit in the data science workflow will differ. So you're always going to have people like me who died in the wool data sciences, like scientists. I'm a researcher, I will always be a researcher, I will never be an engineer. And for people like us, the tools that we need are like something that reduces the barriers to do the research. So I actually think for people like me, these all in one managed solutions are going to become more prevalent, whereas then you've got that part of the ecosystem who are data scientists with more interest in engineering, maybe an engineering background, maybe they are machine learning engineers and they're doing production work. They're going to need engineering tooling and I think for them you're going to see increasing integration and support of sophisticated notebook tooling which then integrates with something that then helps them move to production scripts and like do all of the work around that. So I don't know that we're going to see a consolidation. I think we're going to see further siloing, if I'm being perfectly honest.

That's a very interesting insight. I never thought about it this way, so I'd love to deep dive into it a bit more. So do you think that data teams, to a certain extent there'll be two different types of data teams, one with a more predominant U type of data scientist, to a certain extent with tooling that fits to your workflow, and then other data teams that are engineering based. Or do you think that there will be a consolidation, at least in terms of the type of profiles on one data team but siloed data stacks within the same organization?

This is like. I'm not going to say I have all the answers, but I've seen quite a lot of data teams, I've worked in quite a lot of different configurations. So everything from being a siloed data science team to being the lone data scientist in a team of engineers. So basically I think the conclusion that I've come to, I've always worked in medium to large institutions, is once you start getting a certain level of complexity with your projects, it's impossible to have one person doing everything from research to not just productionizing it, but maintaining it in production, because that's where you start getting a lot of debt. So in my mind, what actually makes the most sense in terms of ease of hiring and also I think the happiness of the teams is to hire specific data science teams who do your prototyping and they do your research. Hire engineers who will be responsible for your data pipelines and also your production, but have them work together on a project basis. So I think they're called squads in some places. However you like it and you need to have constant communication. You can't just go and plan a data science project without consulting engineering because you have constraints, you have technical constraints about language and about latency and things like that. But I think honestly the most sustainable model that makes everyone the happiest is this sort of team based approach based on skills and expertise. But then project Based on the actual thing you're trying to achieve.

That's great. And you mentioned here communication, what do you think constitutes effective communication between engineering teams and data scientists?

Yeah, so in my kind of view, the data scientist, it's probably going to be like one of the more senior data scientists on the team. They need to take in some ways a project management perspective. So they need to be a bit of a translation between the business requirements and the technical requirements. They won't do all of it, obviously, like, I can't speak for engineers, I don't have that expertise. But you need to be like, okay, you want to, I don't know, increase your customer retention by 30%. We need to work out if that's feasible from a business perspective. But assuming that's true, here is the approach that I would take. Now let's go and talk to engineering and let's get a list of all of the constraints they have because that's going to affect the model I can build, that's going to affect the data I have available. It's going to affect the potential feasibility of the project that I thought from a business perspective is feasible. So at the beginning you have this back and forth communication and you need to keep revisiting it because research projects evolve and you get more information. So you need to keep in constant communication between business. Oh, you know, this is going to take three months longer than I thought. Do you want to keep going? And you need to keep in touch with engineering and be like, okay, this is the best I could come up with in terms of the predictions from this model. Is this fast enough? Things like that.

I love the level of depth that you go into here. So we talked about the current state of the data science notebook. We talked about the fragmentation of tooling. I'd also love to get from you where you think the Data Science notebook and the IDE is headed. So I'd love to understand where do you think the notebook is going to look like in the future? What do you think are standard features of notebook and IDEs in the future?

Yeah, so I think definitely, like remote first is probably going to be a standard and I'm seeing this increasingly, although I have seen the specs on those latest Macs. They have something like 96 gigs of Ram on a local machine. Like, it's insane. We were joking at work that we were like, oh, maybe we don't need remote after all. I went server in my office. I think also, look, I can't say whether it's going to happen in Terms of the culture of coding and data science, whether we're going to move towards better coding standards. There's been a lot of discussion about this, but I don't know that data scientists see it as a priority. Developers certainly do, but I think in any kind of project where you have data scientists that need to hand code over to engineers, definitely okay, I can't see if it's going to be there, but it would be useful having more of these tools that help data scientists write better, more maintainable code. Even things like introspections. Do you really want to write this Python function without declaring the type because it's not going to be as readable? You need to put in a docstring, things like this. And then I think probably there's. I think this conversation about the role of the notebook and ML workflows is going to evolve and I think we're going to see more tooling around this. So I think potentially having reproducible environments from the beginning for the notebook. So at least if you hand over to engineering, they know what your dependencies were, they know the Python version, they know things like that, assistance to connect to remote resources and even integrations that make deployment easier, like things like AWS toolkit, give you a lot of extra benefits or extra tools that allow you to go from messing around in research to actually productionizing things. So I think these are the kind of big challenges coming up.

And you mentioned here the importance of code quality, debugging, introspection, like having maintainable code. One thing that we discussed behind the scenes was chatgpt, the rise of like large language models. Over the past few years we've seen like autocomplete code tools like GitHub, Copilot, I think OpenAI's Codex. How big of a change do you think these tools will introduce to the coding workflow? Do you think they'll be able to improve code quality, improve the workflow of data scientists? And what do you think this will mean? This is a big question, right? What do you think this will mean for data science in the next few years?

The opinion I guess I've always had and it's really only been strengthened over the years, is that the job of a data scientist or the job of a developer is not to code, it is to solve problems. And knowing what I know about large language models, really they're very sophisticated probability machines. They generate likely next word in the sequence based on amazing amounts of data that they've seen. So while they may approach, I guess human looking reasoning, they can't problem solve, not in the same way that we can. So I don't want to speak for the next three years of large language models. I would say even being an NLP for a long time, 2022 knocked me on my butt. Like I just did not expect what we saw. But what I think is we've had ides for a long time. We've had tools like code completion, introspection for a long time. I think Copilot, it's a leap forward. But I still think like Copilot and ChatGPT are extensions of this. They will help us write better code, they'll help us understand our code better, they'll help us explain regex, which frankly is one of the best things to come out of ChatGPT. But I don't think they're going to, you know, replace all these things. Even those things I was talking about, like you communicate with your business stakeholders, you manage the project like this all still needs to be done. So yeah, I think it's just going to make the coding part more efficient and it'll free up time to maybe make projects more efficient that we don't spend as much time writing the code. We spend more time thinking creatively about what to do next.

So I completely agree with you. You know, I've been also inspired by ChatGPT and kind of what large language models have been able to do in the past two years. I do think they're only probability machines. I think there's a lot of people who are sounding the hype bells around this is going to replace problem solving. I don't think it's going to replace problem solving anytime soon given its current configuration. You never know what happens in the next few years. But it's been an interesting space to follow over the past couple of years. I do think that it will be able to raise the standards for your average data scientist in terms of the coding workflow. It will be able to help them bridge the gap between data science and engineering in a lot of ways. As you mentioned on code quality, best practices, all of these things. I think the only thing that reinforces as well as the rise of large language models is that maybe coding prowess is not going to be as useful in the future as much as problem solving and conceptual knowledge about why you're doing this choice. I'll give you an example. We were testing out this machine learning workflow with ChatGPT. You need to tell ChatGPT I need a logistic regression for this problem. You need to choose what evaluation metric that you need to tell it to code. And all of these is conceptual knowledge that requires you to be able to really understand the space, to really understand why you're doing what you're doing, and to have a good, and to have a solid business acumen, for example, when approaching a problem. So that's where I agree with you quite fully here.

That's such a nice example as well, because I think it really shows that if we go back to that idea of the business constraints, you may have reasons for choosing that logistic regression over something more complex. So there's layers of decision making there that again, these models cannot replace. So, yeah, I really like that example.

So in a lot of ways, it's essentially an assistant that helps you become better and faster at what you do, but you're still in the driver's seat. Right? And I think that we're going to see an evolution of the data science role in that regards. But the concept, conceptual knowledge and the ability to make educated decisions around what will be useful for the business will only become more important in the future. So second part of my question is what do you think is going to happen in the next few years when it comes to the data science workflow, especially with large language models? I know this is a big fuzzy area at the moment. We never know what's going to happen in six months, let alone five years in the NLP space. But I'd love to see some of your predictions here.

So I think my prediction is we're really going to start automating a lot of this boring boilerplate work. So potentially what you're going to see is a narrowing of the gap, as you said, between the engineering part and the data science part. It may be even a lot of this stuff that I've been talking about, this is really me just making wild guesses. But why not a lot of this code that's needed or workflows that are needed to take your notebooks into production? Code potentially could be suggested by these models. So something I know that a lot of data scientists struggle with is how do you structure a project? Because we don't think in projects, we think in notebooks. So potentially these models could say, okay, I would suggest dividing up this code into these particular files. What I can do is I can reformat the code and put it in that and then potentially bring in more robust coding structures, like moving away from just functions to classes where it's appropriate, reusing code and things like that. So it would be super cool if that was automated because it would be amazing to hand that over to the engineers. One problem would be though, is you still need ownership over this code. And I don't mean this in an ethical sense, but I do want to touch on this. It's more in the sense that when something's put into production, it's not a dormant thing, it's a living thing. And when systems go down, someone needs to be responsible for it. So if you have a machine like an algorithm writing the code that is then your production code, who owns it, who understands it, who's responsible when it breaks. So, yeah, I don't know, even if my little fantasy comes true, whether it would entirely solve the problem it's designed to.

That's a great point at the end that you mentioned here, because I do anticipate that there's going to be, let's say we do scale the use of large language models in coding workflows. There needs to be some form of human in the loop type interaction that is doing the qa. But I anticipate that for large code bases that will be very scalable, necessarily, that would require quite a reimagination of what the coding workflow looks like. And you mentioned the ethical thing here. Do you want to maybe talk about also the ownership of the training data, for example, and what that means when code is being put into production?

Yeah. So I think everyone here would be familiar with the controversy around where the data to fine tune GPT3 for Codex, which then became Copilot, came from. So it's an interesting thing because I think it's very interesting for me to look at these sort of things because my background again was health sciences. We needed to explicitly ask consent for every bit of data we used. And it's then crazy to see companies using all of this data and then maybe making money from it when they didn't ask for that permission. I think it's more complex than saying they shouldn't do it. But this data doesn't come for free. It has been created by someone. It's the same for the language generation models. And I know stability AI are going to let people opt out for stable division three, but I think it really needs to be thought about, not just in terms of the ethics of where you get the data, but also who owns the output.

Yeah, it's an entirely fuzzy area of machine learning that I didn't anticipate is going to be such a massive issue. Think about it. Just in the arts, right, There's a couple of examples that I loved. One is so Nick Cave, Australian singer Someone created a song in the style of Nick Cave. They asked him, like, what do you think of this song? Nick Cave's lyrics comes from a lot of emotional trauma and pain that he's been through. You can check out his life story. And his response was pretty telling. He was like, this is essentially meaningless, right? Even if it does sound relatively well calibrated. But if it's enough to confuse people. Is this a Nick Cave song? Who owns this song? Right, because the original style was in the style of Nick Cave. Similar here on, like, if you create an image in the style of a living artist today or a living photographer who owns the image because the training data is owned by that artist. So you can take that example on code bases as well. A lot of code bases are open source. For example, stuff that you find on GitHub. I'm not an expert in the legality of being able to take that data, translating it into outputs, but it's a big legal issue that the industry is going to have to come to terms with in the next few years for it to become a very productive area development.

And I think maybe when we were scraping Wikipedia or Google Books for training data back in the early days of word embeddings, no one really anticipated this.

So, yeah, it's. It's a. It's a. It's an interesting area. Very excited to see what happens in the space Now, Jodi, before we close out, we talked about it at the beginning. I'd love to talk to you about your experience being a developer advocate and what does it take to become a developer advocate. A lot of ways we share a similar role, so it's always nice to talk to fellow evangelists and advocates, walk us through the process of having become a developer advocate. And what does that entail?

Let's just say I fell into advocacy. I vaguely knew about it because my husband is a developer. He used to go to a lot of conferences, so he knew a lot of advocates. And a good friend of mine is an advocate, which is how I got into it. But I'll talk about that in a second. I'd been working as a data scientist for quite some time. I think I had six years under my belt by that point and I really liked it. But I used to be a psychologist and I missed in some ways, I really like the teaching aspect and the sort of not the helping people. It sounds a bit wooey, but I like being able to make people who feel maybe a bit unwelcome in this space feel really welcomed and, like, they can do it. So I actually ended up just talking to my friend about this role, and when it came open, she was like, hey, you should totally apply. And I was like, I don't know, not sure if it's for me. And then, you know, she sold me on it. She told me that it's a lot of that stuff that you like. You get to teach people, you get to mentor people, you get to help them. And when you create materials, it's explicitly to teach, not to sell the products. So, yeah, that's how I got in. Did you want me to maybe explain a bit about what advocacy is? Or maybe you could explain, I think advocacy.

From my experience, advocacy differs from organization to organization and role to role. So maybe walk us through, in your experience, what advocacy entails in your role.

At Jetbrains, they're very strict when they hire advocates that we are not. We're not there just to sell the products. You will not get the job if you do not genuinely believe in the products. So that's a good start. So because I really believe that these products can help people be better data scientists, my job is really just to help show people how they can be better data scientists by using these products. But then also the products aren't perfect. So I can take feedback from the community and be like, hey, if we do this, I'm going to make the product better. Or in my own opinion, I can say, I think this feature is really lacking, or. Or this feature's too complicated. There's also all the materials around that. So the content creation, if you want to call it that, is a secondary kind of thing. The primary goal is always to help people be better data scientists. And it's super nice because I think when I started, it was overwhelming. Like, I was scared of the command line. And so I really want people who maybe feel like, oh, God, like, I really like this stuff, but I just don't think I can do it. I want to maybe be a friendly face and say, hey, I'm not going to be able to teach you everything, but I can support you.

Yeah, that's really great. Contrasting it with my own experience, evangelism at datacamp. So there's Richie as well, who co hosts the podcast. He's also an evangelist at datacamp. I would say it's really predominantly about sharing the insights of the data community with the wider datacamp audience. Right. Like, we also don't necessarily, like, sit there trying to sell the product. It's just being the interface between the community and the organization. So that's been a humongous privilege for me. I think my role is a bit more creation focused. If you think about, we run our webinar program, our live training program. We really think about how can we make as many magical experiences for the community as possible. Because in a lot of ways, our content team as well, the ones who interface with the wider community in creating courses, also act as that interface between the learner and the rest of the organization. So in the Data Camps position, it's a bit different. I get to be really just a creative and like, focus on the creation side of things, which is why I told you, like, it's different from company to company. I talk to a lot of people in this space. Some people are more in the professional services consulting space. They talk to customers, help them adopt the product better. So it's really different from one organization to another. So it's interesting to see how it looks like at JetBrains.

Actually, can I quickly tell you a very cute story about datacamp?

Yeah.

So I actually, I really genuinely love datacamp courses. I think they're such a nice starting place for beginners. But I have a friend who, she's been trying to learn Python for 2 years for data analysis, and she kept like getting distracted. She went off and started watching this CS course, like Fundamentals, and I'm like, no, no, no, you don't need that. And then she found datacamp and she's so happy because she finally feels like she's, she's making progress, learning what she needs to, and she's really excited about it. So, yeah, now she's learning pandas and she's really enjoying it.

That warms my heart. It's always like we're being reminded of these learner stories. Reminds us why we got into this space. In the beginning, I did a data science master's. I wasn't very passionate about necessarily just sitting there coding. I was really excited about the education side of things. So it was like a perfect match for me to stay at Data Camp. But yeah, you mentioned here that story, seeing this on a daily basis on LinkedIn, people tag you for your courses, stuff like that. It's really heartwarming and it's great that your friend found value. Like, one of the main reasons why I liked datacamp from the get go as a learner before I joined the company is that there was no analysis paralysis when I got into the platform. Like, if you go to any other education technology platform, you have like Introduction to python, you get 10,000 results. Whereas I just want to know where to get started.

Yes, you have the tracks 100%.

So what would be your advice for someone looking to get into this type of job?

Yeah, so I think honestly, you need to have a particular type of personality. So I think Adele and I already alluded to it, but. But I think if you're the kind of person who you want to come into work every day and you want to know exactly what you're going to be doing for the next two weeks, and people just leave you alone with this project that you know very deeply, this is not the job for you. And obviously you need to be relatively people oriented. I think if you're a curious person who likes to learn continuously, you like outreaching to others, and, I don't know, you like doing new things all the time, I think it could be a really cool role and you just need to bring a lot of passion to it as well.

I completely agree. Just the ability to juggle different projects at the same time. Being able to talk to customers, create content, being people person, like loving to speak to people is very important. I think one of my main weaknesses, for example, is I'm not very present on social media. It's because I'm always spending time on podcasts, like talking to people and doing webinars and stuff like that. But, yeah, this is something that I think is part of the core when it comes to the evangelism role. Finally, Jodi, as we wrap up today's episode, do you have any predictions for Data Science in 2023?

I have a few. So I think we've already alluded to it, but models got big and they got really big last year. And I think last year was probably the point where we realized, okay, a lot of the cutting edge models that we're getting value from, most of these models cannot be trained by individuals or even small companies. So I think think we're going to be increasingly moving towards the idea of standing on the shoulders of giants, taking these large language models that have already been trained, or these image generation models or whatever, and fine tuning them for our own purposes. This leads back into this ethical conversation because we are now then taking models that we don't necessarily understand the training data for in some cases and using them. I think it's going to be a year where increasingly we have conversations around things like, like data ownership, whether the production of the data was ethical, whether the data is biased. And, you know, with some of these models, should they even be made and released at all, like galactica was a very notable one last year. I think these conversations are going to heat up more this year and I hope they do. And then I have a very boring prediction. But I think in most companies it's just going to be like classic machine learning, business as usual. Like, I think there's all this sexy stuff happening, but I think most of the money is still coming from random forest or XGBOOST or like linear regression even.

Boring AI for the win.

Boring AI for the win. And I'm there for it. I will always love you. Legit linear regression.

No, I completely agree. Linear regressions, logistic regressions, these simple interpretable machine learning models are what's going to drive the majority of the value in organizations today. I think we'll see a lot of more productivity tools emerging from large language models, but most organizations are not going to have the ability to train and deploy their own large language models at this point.

No. Especially when you need to use APIs. Like it's expensive.

Yeah, definitely agree. So it's going to be an interesting year for data science. Jodi, before we wrap up, any final call to action before we end today's episode.

Yeah like I would just encourage you to come check out our tools. So I've mentioned them all, but I'll just re mention them. So we have Data Law, which is more for collaborative data, data science and managed Solutions. We have DataSpell, which is our IDE dedicated for data science. And then within pycharm we have really rich scientific computing and data science capabilities. So yeah, like I'd encourage you download the downloads. We have a community edition of both PyCharm and of data Law, although a lot of the scientific computing is not in community pycharm. And yeah, just give them a go. Reach out to me on Twitter and give me some feedback if you like it or you don't like it. And love to hear what you think.

Awesome. And do make sure to check out datacamp workspace. Thank you so much Jodi for coming on the show.

Yeah, thank you so much for having me. It's been a really fun chat.

Likewise.