Julia Silge: Part 1 — Positron, pineapple pizza, and the art of iteration
In part one of our conversation with Julia Silge, astronomer-turned–data science leader, we explore why data science needs a different kind of IDE. Julia takes us inside Positron, Posit’s next-generation, data-scientist-first environment, and unpacks the day-to-day realities that make data science work unlike software engineering. Along the way, we get a first-hand account of a legendary pineapple-pizza protest and how to juggle multiple projects at once. A behind-the-scenes tour of Positron and the workflows it’s built for, plus the stories, trade-offs, and team choreography required to ship an IDE on a living substrate. We talk extension ecosystems, upstream merges, data viewers, and more. Plus, Julia shares why applied systems (and messy, real-world data) are her happy place. What’s Inside: • The pineapple-pizza story that unexpectedly went viral — and what “context collapse” feels like from the inside • Why Positron is a data-science-first IDE, optimized for analysis, not general software engineering • Iteration vs. reproducibility: the central tension in data science workflows and how tooling can honor both • Hadley’s cold-turkey move from RStudio, muscle memory, and finding the new ergonomic groove • How Julia measures success by smoothing the boundaries between tools and teams • The applied, people-and-process side of data science that keeps Julia energized
image: thumbnail.jpg
Transcript#
This transcript was generated automatically and may contain errors.
Welcome to the test set. Here we talk with some of the brightest thinkers and tinkerers in statistical analysis, scientific computing, and machine learning, digging into what makes them tick, plus the insights, experiments, and OMG moments that shape the field.
This episode is part one of a conversation with Julia Silge, data science leader and engineering manager at Posit.
Hey everyone, welcome to the test set. We're joined by Julia Silge, and per usual, we have Wes McKinney here and Hadley Wickham, two data science leaders in the R and Python community. And we're so excited to talk about Julia's work on Positron and a whole array of things.
All right, Julia, thanks so much for coming on to the test set, a podcast where we explore the people behind the data, and we're so excited to have you.
For just a little background, you've written three books, you have a PhD in astronomy, and you're currently an engineering manager at Posit, but you've also done so much work in the R ecosystem, building packages, so I'm really excited just to be able to talk about your open source and managing. Welcome.
Thank you. Thank you so much for having me. I'm really glad to be here with talking with you and our other folks here today.
The pineapple pizza protest
Okay, one thing I thought we could just start out with right out of the gate is we had a question when we were talking with you before starting about if you like pineapple on your pizza, and I was not expecting the answer you gave. I don't think I could have predicted it.
But as it turns out, your Wikipedia page speaks to this question that you, one time as an activist, sent a pizza to a senator. To my senator. That's right. I don't know if it's too big out of the gate, but I thought maybe we could just open with that, pineapple on your pizza, and why is it on your Wikipedia page?
So in full disclosure, I do actually like pineapple on pizza. I am a pineapple and ham Hawaiian pizza. That's good to eat, if you ask me.
Several years ago, I did actually send a pizza to my senator. It was at a time that it was difficult to get through on the phone to your elected representatives. There was somebody up for being confirmed for the cabinet at the time, and it was somebody that I had strong feelings about. I was really opposed to this person getting confirmed, and I was trying to get through on the phone, and the stupid mailbox was full, and they were not answering the phones, and I was so upset because I was like, this person represents me.
Thinking back, I am honestly not totally sure why my brain went there, but I thought I will send them a pizza and put my message in the delivery notes, so I did. I went on to a local pizza delivery place, and I put in the office at the federal building, the one that's here in my city. I live in the state capital of my city, and so the delivery address was the office of the senator in the federal building. Here, I put that as it, and then in the notes, I said, please vote no on this person.
My name is Julia Silge, and I live in this zip code, and I put that in the notes. I put a really big tip because I was a little bit like- If you're going to get through security. I wasn't sure how this was going to go, and I sent the order, and the order went in, and I did get a call from the delivery driver, actually, like, how do I get into this building?
I said, oh, well, the office is on the such and such floor. I feel, actually, that's the part I feel a little bit bad about was the delivery driver having to have this experience because I was like, oh, man, I've kind of like roped this other person into this whole experience, but they did. They get in. They delivered the pizza, and I was like, okay. It went in.
I, like a little bit later, got a call from the security for the federal building at this like here in the capital where I live, and the security person was like, I've gotten a report of a pizza being delivered, and I was like, oh, I was so nervous. I was like a little shaky and nervous, and it ended up.
So, at the time, I had like I would say like a moderately big Twitter following at the time, mostly because of my engagement in the data science community, and I was kind of tweeting through it. I was like, because I was at the time, I was just like really upset about how things were going and that this person was, you know, up for this cabinet position, and so I was, you know, I was in a moment where I was just kind of like posting through it, and it went the most viral of anything I've ever done in my life, and it was really, I think of it now as my 15 minutes of fame.
Like, it was on, you know, Rachel Maddow, and it was on the Washington Post and really went pretty broad, and it is really interesting like what happens when you kind of escape your, you know, the circle of people who know who you are and like what you do, and it was the time that happened most dramatically, like where like what something I had written like had escaped kind of, you know, like it was a real experience of context collapse. It was an interesting experience in a lot of ways, and yeah, it's on my Wikipedia page.
Like, it was on, you know, Rachel Maddow, and it was on the Washington Post and really went pretty broad, and it is really interesting like what happens when you kind of escape your, you know, the circle of people who know who you are and like what you do, and it was the time that happened most dramatically, like where like what something I had written like had escaped kind of, you know, like it was a real experience of context collapse.
Did it work? Like, did they vote no? No. Did they respond at all to your... Yes. Okay, so you got the message through.
So the senator's office reached out to me after it went super viral and started getting picked up on news, and they said, they were like, oh, you know, thank you. It's just, you know, they're like, oh, it's just been so hard to hear from our constituents because like all these fake people are just filling up our... And I'm like, no, it's real people like me that we're trying to get through. And they're like, oh, it's just so hard to hear from people.
And I took pleasure in voting against that senator every chance I got. I changed party registration so that I could vote against the senator both in the primary and in the general, so...
Introducing Positron
So I know you're working on an IDE called Positron at Posit right now, which I imagine probably has a lot of moving parts.
So Positron is a new next generation data science IDE. So, you know, us at Posit, we are the makers of RStudio. And so we are a group of people that have a lot of institutional muscle, a lot of institutional knowledge about what people who are doing data science, people who are doing statistical analysis, what are they like? What are the tasks that they're trying to do? And so Positron is our kind of like new next iteration on providing a set of tools for people who do data science.
Positron is a fork of Code OSS, which is the open source software that is used to make VS Code. So if you're familiar with, you know, other forks of the VS Code infrastructure, like a cursor or Windsurf, it has some similarities to those in that it is built on this kind of underlying infrastructure. But it's different from those other kinds of projects because there's a different set of goals. Like the goal of Positron is to provide a data science first IDE. It's not built for general purpose software engineering. It is built specifically for the work that data scientists have to do.
A lot of people who might be used to, like, there are a lot of people who use VS Code for data science or other kinds of more general purpose IDEs. And you can't often get that to work, right? Like you would install some sets of extensions and then you can kind of like kind of bailing wire together an experience that you can then use to do data science, to do machine learning, to do statistical analysis. But our hypothesis, our sort of bet here is that we can do better. Like, we're not interested in making something for everyone. But our bet here is that we can do better specifically for people who have data analytic tasks, who have data science tasks, who have machine learning tasks to do. If we build a tool for them that is specifically built with that, you know, you as a user in mind, that we can make something that's more integrated, more pleasant, that you can have like more fluent, ergonomic kind of workflows.
What makes data science workflows different
Obviously, I've got like a lot of thoughts about this, but like, what do you think makes like the data scientist workflow different to the software engineer workflow? Obviously, like different tools and stuff, but it feels like the workflow is different to it.
I do. And I think there is, there are two, like two characteristic things I think really define, what is data science work that maybe set it apart from like other kinds of software engineering. And the first one is that it is more, it is more iterative. Like you, even if you are all in on writing code to do your data science, like often you literally cannot know what the next block of code you will write until you see the output of the first block of code. And so it is, it is more exploratory, more iterative.
At the same time, there's really high needs for reproducibility. And so when you sit in this tension of my work is deeply iterative and I have high reproducibility needs because we can't like, like, like sure you could, you can have a very iterative exploratory kind of work, say in a, in a pointy clicky gooey kind of tool. Right. So if you don't have any way to make that the set of steps you took reproducible, sure you get the exploratory side, but then you don't have the repeatable reproducible side here.
So what I think is different if you take people who write code for all kinds of different reasons, I think what's different between someone doing statistical analysis, data science, machine learning, and someone who might be doing more traditional software engineering, by which I mean like build a website, build an app, build, you know, like something of that nature. The work of a data science, data scientist has high reproducibility needs and high needs for supporting iterative exploratory workflows.
I'll tell you like this one thing that I found really, I think the thing that I found most surprising kind of about Positron and hints about really about VS code. And that is, it seems like most software engineers have like one VS code open like that in one project. And they live in that project all the time. And that is really far and coming from RStudio where he'd like, I'd have like three or four projects out because you're often working on all these different things in tandem. You're different data analysis, you know, different repos. Whereas I think software engineers have many, at least many of them just live in kind of that one place and working on that one code base.
And that just, this is fascinating to me. Like that's never something I would have predicted as being different between software engineers and data scientists. And it's like one of the things that's kind of taken me, like I think we're now at a good point with Positron. Like I'm just like, now that I understand that we've figured out like what the workarounds are and like, like how do you use it? But just really fascinating that that was just such a journey to go on to learn. Like how do I manage like multiple VS Code projects at once? Because this is not a problem that most people using VS Code have.
It's so interesting to think about the workflow too, of sort of like, what about this area of work would lead someone to have like four open where the other person has one? It seems like in a way such a small thing, but it is really surprising, a pretty striking dynamic.
There's also this whole idea of like, what is a project? And I think one of the things that like people coming from RStudio, like really have to reckon with when they move to Positron is like, what is a project? And RStudio is very clear. Like a project is a directory that has your approach file in it. Now you're in Positron, like kind of anything can be a project. It's just like a folder you're opening up into a workspace. And like, it's not, you know, it's not like one is bad and one is good. It's just like different. And now I feel like help people kind of manage that.
Just to give some context on VS Code projects is a VS Code project is often like a code base. Is that right? Like a package or? So from a conceptual or I don't know, I don't know, from like a slightly higher level, like VS Code has, it has concepts of a workspace, which is like a workspace is about the same thing as a folder, which is about the same thing as like a little P project. You know, it's like these kinds of things are all like conceptually about the same. People who came from RStudio have placed a strong amount of meaning on something that is like a capital P project. And it like, so think of that as like a folder that has been imbued with special meaning.
Python, Jupyter, and the path to Positron
I think for me, one of the interesting things both is using Positron and contributing, contributing to Positron has also been the intersection of the experience of building, building and using RStudio for the last 15 years and the experience of from the Python ecosystem, more of like the terminal based data science through IPython and then Jupyter, Jupyter Notebooks.
And so I actually never, I've hardly used RStudio only a little bit here and there. I used MATLAB and other data analysis environments in the past, but for the better part of 15 years, I've been mostly using, doing data science in the terminal and using Jupyter Notebooks. And I've run into a lot of the limitations and the rough edges of like jumping back and forth between an actual development environment and, and a Jupyter Notebook where Jupyter Notebook is really great for that, like interactive exploratory work, looking at spending a lot of time looking at your data, plotting, manipulating plots, looking at the data. But to create this, this environment that's synthesizing all of those ideas in one place that's really optimized for looking at your data and iterating on your data visualizations and, and all of that has been, has been really satisfying since I've, I've in the past, like I was always felt like I was grappling with the rough edges of the code editor plus Jupyter centric environment that I'd been, I'd been using.
It's so funny to hear you say that Wes, because I like 10 years ago when I was transitioning into data science, when I was, I was coming from a background in like scientific computing, really comfortable at the terminal, really comfortable. I mostly wrote low level code at the time, like C code for like, like a lot of numerical kind of stuff. And I was like, okay, time for me to transition into data science. Time for me to, you know, get a new kind of job. And I, I attempted to learn Python first.
And I actually didn't, I never even heard of R because I didn't come up through stats or anything like that. And I like, I literally had never heard of R. I was like, well, I've heard of Python and other people I know have kind of like started using it. And when I think about like full disclosure, it didn't go very well. And I like largely attribute, so there's two things I attribute it to actually, like that, what, like, why did it go so badly 10 years ago for me when I was like, time to learn Python.
The first one was, you know, was I had some real challenges around like environment management, Python environment manager, classic, classic, you know. And it was actually pretty frustrating because I thought of myself as computationally pretty competent, you know, it's like, I'm not bad at computers. Why am I failing to manage Python virus?
But then the second one, I think was that all the tools I was trying to use as to do data analysis were not really a good fit. They were not really good fit. Like at the time, I was not aware, maybe VS code wasn't around, but at the time I was like, like, can I use a Jupyter notebook? Can I use like Emacs, like org mode, all these extensions to do data science and like some combination here. And it really didn't go very well. And I, it's been pretty interesting working on Positron now and feeling really, even as someone who works on it as my main job, feeling, feeling now, finally, like, oh, now I can use Python in this iterative way where I have that sort of balance between like the iterative exploratory work and the reproducible practices.
How the team uses Positron day to day
Oh, cool. I'm most curious too, because I think everybody hears using Positron, but I'll be curious to hear a little bit about what kind of things you've been doing in Positron. Like if you've been doing any like data analysis, I'd imagine, like what, what kind of projects have you gotten up to sort of like driving Positron?
I'll, I'll, I'll kick us off and I'll say two examples of things I've recently done in Positron. One, one is a Python thing and one is an R thing. So we have multiple repos that we use to build Positron. And it turns out on GitHub, you cannot automatically put the same milestones on all repos. And so I just did a little project where I, so I use Python and like Pydantic and the requests, the packages Pydantic and requests to make a little thing that I could run that would pull all the milestones from one repo, match them up, which ones do and don't exist and like write them all to another one. So that's like, and I did that and in Positron was able to do this like iterative exploratory kind of little mungy kind of thing.
And then another thing I recently did is I do use Positron for my R package development. So I recently did a release of, I think the last thing that I did a release of was the pins package. And so I use Positron for my R package development work to be able to go through, run the tests, get it all ready to do a release to Crayon. So those are two for me. What about you all?
I mean, like 90% of what I do is like R package development in Positron. And maybe like 10% might be pushing it like data analysis, but mostly like little, like what's the one, one thing I've been trying to like do data analysis wise is like we, we have solar and our solar has an API. And I was like, okay, I really want to get all the data from that downloaded so I can start to like analyze it.
Do you say solar? Solar. Solar. Solar power. Solar. Oh, I'm so sorry. Solar. My bad. Solar power. It's the Kiwi accent tripping you out. I thought it was some kind of enterprise API.
But I mean, the API was atrocious. So I spent like all last, like it was just like a little fun project. So I spent all of my kind of allocated time getting through the auth process of the API. But I hope to like start to look at the data soon.
And are you, are you doing a hundred percent of your package development in Positron now? Like what does that look like? Yeah. A hundred percent. I had to go cold turkey off RStudio. For a while I was like, okay, I'm going to like every day I'd start out with the goal of using Positron. And at the end of the day I'd be like, oh, that's weird. I'm in RStudio. Like, and I don't remember. Because just my fingers are like so accustomed. So I had to go cold turkey. I just like deleted RStudio from my computer. Like now I can like go into RStudio when I need to.
To be clear, listeners at home, you do not have to switch. But if you want to do like Hadley, you just have to delete RStudio, you know? But I mean, I think that is one of those things, like when you are trying out something new, like that, you know, making that hard break and being like, I'm going to devote all my time, like learning anything new sucks. Like it's always painful. Like you immediately notice all of the things that were so easy before and now like painful and frustrating. And if you don't like push through that, like you never get to all the good, the cool new stuff. It's like easier. And a lot of the pain just goes away because you get used to the new way of doing things. But again, you do have to like be like, okay, I'm not doing this old thing anymore for a while. I'm going to switch to this new.
Yeah, I I've I've done, you know, a number of small one off one off data analysis projects in in in Positron. So I've been doing development on I've been doing development on Positron building, working with the team, building the data explorer. So if you use Positron to look at a data frame or look at a parquet file, you're seeing a data explorer that I've worked directly on designing and making making reality.
But recently I've been interested in like analyzing activity on on GitHub. So like I built some programs with the help of cloud code to extract with the help of GitHub API keys, like lots of activity data to look at, like what's happening in many of the most popular popular projects on GitHub. Like I was just looking at actually need to wrangle all the data and make a blog post about it. But I was looking at activity across the hundred most popular Python packages on GitHub. And it was really interesting because there was a lot of packages that I've that I've never heard of. But it's been amazing how much Python has become just total AI land, like all of the popular projects, seemingly all of the popular projects on GitHub, at least based on GitHub stars, which, you know, who knows what that's worth? Are AI related that plus, you know, I I've always had had an interest in analyzing my personal finances.
And so so recently I built a little system also with the help of cloud code to ingest all of my Amazon and Whole Foods purchase history so that I could look at like, you know, is the is the price of my produce going up over time or like what are the things that I'm actually what are the things that I'm actually spending money on? And so to be able to be in Positron and be able to, like, look at pull up CSV files and look at them in the data explorer or like to kind of interactively, you know, make plots and things like that. It's just it's it's it's been really nice. So I'm happy, happy that it's there.
I do want to note it's kind of interesting, like the way, Wes, you talk about using Positron is like, oh, I have this more like iterative, integrated experience. And I feel like things are like like you feel more fluent in some of the things to It's interesting to think about that, because like Hadley, when you talk about using Positron, it sometimes you do sound a bit like it's like, oh, I really had to adjust like I really had to adjust. And I think it's interesting thinking about the tools that we come from, what they prioritize before, like like what have various tools prioritize and what that has what what has made that what makes that feel at a transition either pleasant or, oh, there's some challenge in it or like this, you know, like, like, oh, there were trade offs or, you know, I think it's kind of interesting to notice the way you two talk about using Positron.
I have to say, like, one thing's been really interesting for me is like the data viewer in Positron, because I don't think I never really used the data viewer in RStudio. But somehow the one on Positron, I've been like reaching out for a more offer. I'm like, I start writing like a little bit of code to just like find the row and like look at it. And then I'm like, oh, actually, I could use the data viewer for this. And I think something about the way you just like click on a CSV file or a parquet file and just loads up instantly. It just makes that like, like that analysis, which I would have written like tidyverse code for before just feel like a like it's it's faster now to, you know, explore that directly.
My sense is because Hadley over a long period of time was building and maintaining dozens or maybe even hundreds at this point of our packages. But RStudio was his primary development environment. So I could understand that going basically changing your entire development environment. Again, like Positron was built to support our developers, you know, equally as well as equally as well as Python developers. To go from, you know, a development environment where he's become very accustomed to for over over 10 years.
And of course, the other thing is like, I've had a much more direct line of feedback to the RStudio developers, like the VS Code developers. So the things that I really like, like, I don't know. You have to send them a pizza. That's the key.
I do. Actually, I was thinking when Julia was saying that, like, I have a technique that I use that I have, like, it's mostly. It's not it's mostly jokingly, but I have this, like, limited edition, like, gold Gigi Part 2 stickers that I sometimes offer to engineers in order to get them to implement a feature I really want. Wait, that's incredible. And did you you've kept them limited edition by design? Yeah. Yeah. Like you can only get them to be by being like great service to the tiny bus.
So if people are listening at home, there's we know pizzas work, gold Gigi Plot stickers work. Yeah. We're just getting a list of ideas. People do a lot of people will do a lot for a sticker. That's that's one of the things.
Building on VS Code: tradeoffs and benefits
Well, Hadley, one thing you mentioned that is that makes me think how interesting it is to be in a situation where we're building on top of a like a let's call it a substrate that we don't entirely control. Right. And I think like big picture, I think it's really interesting what like the VS Code team has done by like making code OSS MIT licensed. It kind of like it has lowered the bar to experiments in the IDE space. I like like and I think, you know, you see this flourishing. And of course, we can make jokes about like, haha, did you make a new IDE or another for you know, and you're like, yes, it's another for you know, like, but but it is I think it's quite interesting to be in a situation where people can do quite a bit of experimentation in the IDE space because it's like the the the building blocks are there like the building blocks are there to be able to kind of take your own make your own hypothesis of what may be a good fit for people.
It definitely is something that has tradeoffs, you know, like like building on top of already existing infrastructure like it reduces the amount of hours, you know, people hours you have to invest to have something that's working that people can actually get their hands on. But there's also like tradeoffs in there, you know, and of course, like the obvious one probably is like any bugs that are in VS Code like we have unless we decide to fix them separately or anything like that. But some of the slightly more, you know, other things come up that like like sometimes it's surprisingly hard to make a change because of this infrastructure that we just have kind of absorbed.
Another thing is like there's work every so we we merge from upstream once a month and that is work that it's kind of hard to predict how if it's going to be a lot of work or a little bit of work. And so it's kind of like from a planning perspective, it's actually a kind of an interesting challenge. Organizationally, technically, it's an interesting bet to have made. I'm still all in. Like I think we have something that we wouldn't have had otherwise and that we're able to make something we wouldn't have. But it's definitely not something that has no cost to kind of work through.
I mean, one of the big one of the big deals I see with the code OSS VS Code ecosystem is the is the plugin and extensions model. So in the past, you'd have an IDE and it would be this static, fairly immutable thing. Like maybe you would get some extensions or add ons from from the developer of the IDE. Maybe it's an open source IDE or a commercial a commercial IDE. But really, you wouldn't have this, you know, broad, like massive extension ecosystem. But now the table stakes is that people see something new and they're like, can I get in a VS Code extension or as a, you know, open VSX extension? And so in a sense, like that's that's created this massive gravity well for for people building IDE technology, like they build new open source or tools that support development. And then they they're the way they make that available to developers is through a through a VS Code VS Code extension. So it's definitely a cost. But but like, if we weren't, if Positron weren't building on on the VS Code ecosystem, we would have to figure out a whole new model for like, how does extensions work? And how do we get developers to build extensions and make them work with work well with Positron?
In the things in Positron that are like, clear, like a clearly superior to RStudio. The sort of data science adjacent things like, like every data scientist, at least I believe every data scientist has to be using Git. Like the VS Code Git pane like this had probably an order or two more magnitude of hours put into it than RStudio ever did. Or like the find in files, like all of this stuff is just kind of table stakes IDE stuff. Like we now get that for free and we can invest our time in making like really awesome data specific stuff. Which is a which is a which is a big win.
I think that's same with the extent like we had to develop our own extensions ecosystem that exists. It's interesting here. It's a lot of the like software engineering things kind of come in for free. And then you can really cook on the data science and some of those more specific parts.
Yeah, I mean, because that's the stuff we have like we have the institutional muscle and care and experience about like that. And those are the users we care about. So we now get to focus on that. You know, it's interesting. Some like a few of the people who work on Positron directly came over from the RStudio team. There is still an RStudio team, right? Like RStudio is maintained all this, but it's a smaller team now. And there's more people on Positron. And it's really interesting hearing them talk about how now we focus on data science. Whereas before in RStudio, any given week, any given sprint, I mean, given month, you know, you had to be like, what? Like, what are we going to do? Are we going to make some new kind of like general IDE feature that people now want? Or are we going to focus on something that's specific to how data scientists work?
Measuring success as an engineering manager
So we talked a lot about Positron and some of what it brings to the data science workflow and how we're using it. I'm really curious as an engineering manager on Positron and an IDE, which is a sort of complex thing to bring into the world and it seems tricky to kind of like see it in operation and track. How do you measure success and how has that changed over time?
I think that when I think about success, say on any given like day or week or month, a lot of my time is spent thinking about how a complex system like fits together. And so I'm not someone anymore who goes really deep in one like narrow area. But right now I do spend my time thinking about how things fit together and identifying what is the shape of our success and what is the shape of our deficits, right? And are we comfortable with where we are or what are the places we're not comfortable and we need to invest more in?
Because often I find that rough edges happen at the intersections of tools or of teams or of projects. And it comes to mind for me that I actually invest a fair amount of thinking and talking and literally writing code, talking to people. This is just one example. But like the intersection of Positron and Quarto. These are two separate teams. They're both at our company, but it's like two separate teams. They kind of have different, you know, like visions or different sort of like things they feel like they're in charge of.
But they like for Quarto, they want, of course, to work in VS Code. It might be good to say what Quarto is a little bit. Yeah, yeah. So Quarto is an open source scientific and technical publishing system. So it is a piece of software that you can use for reproducible dynamic documents. So picture a report or a website or a dashboard that involves executable code in it so that your whole report or website or document can be generated using Python code, using R or Julia code or even just JavaScript and observable. So it's a system for so obviously like really important to the work of data scientists.
So like for a Positron user, Quarto is really important because like it is an engine for the kind of like reporting, like making websites, that type of thing. And so like when we're at that intersection, like both of us are important to the other team, but we don't quite report up to the same people, you know. And so it's somewhere where I feel like it takes actually quite a lot of attention and specific energy to make at the boundaries of tools or teams to try to make that experience as good as possible.
Because often I find that rough edges happen at the intersections of tools or of teams or of projects.
So when I think about success, I often think about like am I putting my attention at the right places? Is it the things that are important to users? Is it the places where we kind of have a bit of a deficit or a rough edge? I think that's how I think about it.
One thing I'm curious about too is just to go back to kind of a more basic question, what would you say gets you excited about data science? So you said my background is in like academia. Like I, you know, I did like a physics undergrad and then an astronomy.
