The Python Podcast.__init__

Share on social media:

[00:00:14] Unknown:

Hello, and welcome to podcast dot in it, the podcast about Python and the people who make it great.   When you're ready to launch your next app or want to try a project you hear about on the show, you'll need somewhere to deploy it. So take a look at our friends over at Linode.   With the launch of their managed Kubernetes platform, it's easy to get started with the next generation of deployment and scaling powered by the battle tested Linode platform, including simple pricing, node balancers, 40 gigabit networking,   dedicated CPU and GPU instances, and worldwide data centers.  

Go to python podcast.com/linode,   that's l I n o d e, today and get a $100 credit to try out a Kubernetes cluster of your own. And don't forget to thank them for their continued support of this show.   Your host as usual is Tobias Macy. And today, I'm interviewing Ben Stancil about the perennial frustrations of working with data and thoughts on how to improve the experience. So, Ben, can you start by introducing yourself? So I'm Ben Stansil. I am 1 of the founders of Mode.  

[00:01:11] Unknown:

Mode builds products for data analysts and data scientists kind of a code first BI tool. And so my role at Mode, I am Mode's chief analytics officer. So I focus on on being involved in our own internal data efforts, as well as spending a lot of time,   kinda talking with folks in the community, trying to understand the problems they have, you know, kinda figuring out where where we think the space is headed and and what kind of problems Moe needs to be solved in the future.  

[00:01:33] Unknown:

And just being a general thought leader, it seems like every week I see an article that you've written in 1 of the newsletters that I subscribed to. Yeah. And I mean, now now I spend a fair amount of my time, yelling into the void on the Internet,  

[00:01:45] Unknown:

on on a substack,   like everybody else, I guess, in in 2020 and 2021.  

[00:01:51] Unknown:

And so do you remember how you first got introduced to Python?  

[00:01:55] Unknown:

Yeah. So I   my original   career like, I started my career,   working in in data in DC. And so while I was there, I was doing basically policy analysis on top of economic data. It was not a technical field,   in the sense that most of the people I worked with were not not people who had deep backgrounds in any kind of technical languages. I had learned a little bit of R in college, and so I essentially did a lot of analysis through R. This was kind of back in the pre tidyverse days. So it was R was wasn't the easiest thing to use. Eventually, when I moved, from DC into   into the tech world, started kinda doing more of the same stuff, but then basically the the more of the gravity was towards Python and doing doing analysis in Python. So I started using it for that. The other kind of I think that the way that I really started to to pick it up and I, like, by no means would would classify myself as is a, like, Python developer or someone who is sort of deep in those, you know, I I can't I can't go as deep as a lot of folks I'm sure can on on the specifics of of different elements of Python and how to use it for for a lot of technical stuff. But I I started using a lot for kind of lightweight   data apps, data management type of stuff. So we built a lot of, like, little internal tools or scrapers or things like that,   and found Python to be very useful for that. So most of my   my experience with it and my sort of learning of it was I had some sort of small problem solving a job, whether or not I was collecting data from 1 place or piping data from this place to this place, and kind of pre sort of the modern data stack world. And so trying to build these little apps for myself, to be able to do that. And so a lot of, you know, essentially learned Python by copying and pasting things off of Stack Overflow for  

[00:03:31] Unknown:

a number of years, to be able to solve those problems. And you mentioned the modern data stack, which has become sort of the latest buzzword, particularly   data engineering and analytics community. And   despite the sort of panacea that it promises to be and the level of sophistication   technologically that we've been able to achieve over the past, you know, 10, 20 years,   there are still a number of frustrations that exist when you're trying to do anything with data. And I'm wondering if you can just start by discussing   what you see as being the kind of main frustrating elements that come up in an organization when you're trying to work with data, you know, in your day to day, and just some of the main pain points and contributing factors that you see.  



[00:04:14] Unknown:

Mhmm. So   there there are kind of 2 ways I would answer that. The the first 1 is that if you're a young company and you're trying to get things set up and you're trying to start to make sense of your data, start to do more rigorous reporting, start to do the kind of analysis that you believe you can to make better decisions and things like that,   Often, the the first problem that people seem to run into is   you have to glue all this stuff together in a way that actually makes sense, and data is still messy. And not messy in the sense that that   these fields aren't clean or whatever, but it's still kind of scattered at a bunch of places. It's difficult to to kinda make sense of all of it.  

1 of the easiest examples that I feel like comes up all the time with young companies is trying to figure out how much money they make. Like, it should be a simple thing. It shouldn't be that hard to say, okay, we report this much revenue every month,   but you end up having to look at data that potentially comes from Stripe receipts. You have to look at data that comes from Salesforce that's manually entered by a bunch of sales reps.   You have to reconcile that with, like, a billing system or with data that's in your product. Sometimes you wanna be able to do things in whatever's happening in kind of the marketing world about how you actually track where that revenue came from. There aren't hard technical problems in that now. So the modern data stack is solved. It's easy to get data out of Salesforce into a database. It's easy to set up that database. It's easy to query it. But there's still just a lot of kind of,   like kludginess around getting that to actually tell you something sensible in a reliable way. And so I think that that is still kind of the fundamental problem is, is there are all these tools that that you can set up, and there's a lot of tutorials out there for how to get these things spun up very quickly and stuff like that. But they still don't provide   sort of value on day 1. You still have to know how to kind of wire them together and and what to do with the data to actually make sense of it. And that requires   not just some technical ability of understanding how these tools work, but it also requires a fair amount of savvy about your business and how you're actually tracking different things in that business. So   part of it is is I think the early stages of the biggest problems are just kind of making sense of all of it and and figuring out kinda what how to interpret different pieces. Over time, for for more mature companies   that that have a lot of these tools in place, there's there's a lot of gaps now about   we have all these tools that do different things, but they don't sort of work together super well. What we've done is taken what used to be great, you set up a big BI tool.  

It it handles a lot of different elements of the stack kind of as this all in 1 tool that's difficult to set up. But once it's going, it kinda solves all your problems   into a bunch of little pieces, and those pieces are really good at what they do,   but you end up with somewhat of a disjointed   series of workflows, or you have a tool that's ingesting data, a tool that's storing data, a tool that's transforming data, a tool that's, like, sending data to other systems, a tool for analyzing it, a tool for dashboards, a tool for monitoring it. All these different pieces,   don't really talk to each other yet. And so figuring out how to kinda make that system a coherent 1 that isn't,   kind of a bunch of disparate pieces is something that a lot of companies are trying to run into as well. And given the fact that there is so much  

[00:07:09] Unknown:

disconnect between   where the data is coming from and when you're bringing it together, figuring out how to wire it together. Wondering what you see as some of the compounding elements of frustration when you're also trying to go beyond simple descriptive analytics,   simple in air quotes,   and move that into a sort of machine learning workflow, and do some, predictive analytics or prescriptive analytics.  

[00:07:34] Unknown:

Yeah. I mean, so it it feels just like this sort of thing where basically the further out you get from the the core of it, the further out you get from sort of the more basic stuff,   it's it's the the vibrations become bigger, basically. Like, each each sort of step away, the the small variance, basically, like,   you're shooting an arrow and you're shooting it from 10 feet and you're off by a tiny bit. Like you don't miss the target by that much. You shoot it from 50 feet. That tiny angle of difference is gonna miss it. If you're, you know, shooting a rocket to Mars, like it can't be off at all.   And so   the further out you get from kind of the core definitions of what your data is and making sure all those fundamentals are right, like the more sensitive those variants are. And so   that's kinda where, like, a lot of it feels like there's these kind of pyramids of different things that people do. The first thing is, like, get your data in order, then kind of foundational reporting, then   the the analytical, the kind of descriptive analytics and then predictive and all that kind of stuff. The further you get up from that sort of the more sensitive is to all these things. And so being able to say, okay, we have a machine learning pipeline. We have a something in production,   that's monitoring these different things, and now we're we're, you know, affecting recommendations in our product or we're   predicting,   response times or whatever in our product.  

All of those things have to be built on top of that same foundation. And so the more that those things wiggle underneath, kind of the bigger this way is at the top. And so like what what it feels like happens in a lot of cases when people do that is you end up kind of trying to figure out ways to to kind of shortcut a lot of it. You end up building more of a system that's that's not necessarily as robust because you're like, alright. How do we stop this way at the top rather than sort of improving the foundation, which is a lot harder?   You sort of try to shortcut it, which makes sense. I think like that's a lot of these things get built in in kind of iterative ways, and and you don't wanna have this huge investment of of finishing everything underneath the kind of pyramid before you get to the very top.  

But that's how I think you end up with these kind of like pipelines that are all crisscrossing and things like that. So   it's hard,   it's hard to do that stuff well, but I think it's, again, the tools are improving so that it's gradually easier to build a more stable foundation.   But I think we still got got some problems to figure out there. And again, part of it is is also not just tooling.   It's that it takes some sort of organizational savvy about your business and things like that to actually get it right. Like tooling doesn't solve   us being able to build great products on the web, certainly helps. Tools like rails and AWS and all those things certainly help us be able to build great products. But at the end of the day, you still gotta make use of them in a in a good way. And so data tooling is is always probably gonna still be that where sort of it's only a skill as is the the developers using it. And on that point of the sort of level of skill necessary to be able to work with the data and understand how to tie it together, I'm wondering what you see as some of the disconnect between, as you said, the level of sophistication of the tools that we have and the ability of the people who are using them to be able to  

[00:10:28] Unknown:

build   meaningful   analysis for their business and some of the, maybe organizational challenges that come up as a result of the different sources of data and the ways that it's being generated and the ways that it's being requested in terms of how to apply it. I think this is 1 of the really big kind of challenges of this space is you have people who run the gamut of different technical abilities  

[00:10:53] Unknown:

and trying to figure out how to make them all work together well. And so I think and then that that to me materializes its way itself in 2 ways. 1 on the actual kind of tool construction side. So if you think about the vendors,   a lot of them are we're seeing some transitions. I actually have a conversation with someone about this with someone last night where   there are a lot of tools that that are these kind of open frameworks for ways to be able to do things in code. And they they are built with the idea of   this is what an engineer would want. That that an engineer would wanna be be able to write their own sort of arbitrary scripts, do certain things with those scripts, and it's sort of like a very   kind of developer centric approach. So   1 1 example of this is is something like Airflow. Airflow is very powerful, but you have to kinda code your own stuff up to make it work. And it's and it's basically a platform for writing your own your own code on top of it. And it's very good for that. Tools like Fivetran came along and said instead of that, instead of giving you a way to, like, very easily orchestrate,   you write your own scripts to extract from an API, you write your script to write it to a database.  

We're gonna forget that flexibility. We don't want that flexibility. We'll just give you a button to push that says, sync it from Salesforce to Redshift.   Yeah. Okay. There's not really any flexibility in that, but that's probably not what you need. Like, you just want the push button thing. And what the result of that was I think it opened up a lot of, like, data tooling to people who wouldn't have access otherwise. It really expanded the market from this isn't just a data engineering thing, this is something that that   anybody can use. Now what you do with the data on the other side is maybe a little bit different question in somebody who's comfortable in SQL, but put that aside,   Fivetran as a tool basically said, forget the flexibility. Instead, we're gonna be kinda rigid in what we give you, but we're gonna make it super easy to do.  

And so   I think from a tooling perspective,   that's kind of where things are headed of, okay, how do we, you know, tools like Census or or these reverse ETL tools are kind of following the same philosophy.   Whereas there becomes more kind of a sense of what data looks like and what data stacks look like. We stop trying to build these generic flexible tools, which are very powerful kinda again for a certain subset of the audience, but instead build things that just say, you probably need to connect these different tools together. Why don't we just give you a push button way to do it? We'll be kind of prescriptive on what that looks like, but the result of that is a lot more people can have access to it. The same thing I think happens inside of companies a little bit about how do you make technical people and and the sort of nontechnical folks who are trying to consume data work together better. My belief is that we'll get to a point where it's less about giving people sort of open access to data and say, go explore it, do whatever you want with it. But it's more of figuring out, we'll give you more prescriptive ways to look at it. They're trying to solve the problems that you actually need to solve, where you don't need to learn. Certainly, you Python, you don't need to learn SQL, you probably don't even need to learn something as complicated as Tableau. It's more of, let's just let you consume data in the way that   that sort of more naturally fits what you're trying to do. So I think it makes sense in the early stages. It's basically give people very flexible tools and let them figure out what they want. But I think these things mature, what we end up finding is   we'll end up being much more prescriptive in it and just say, here's exactly the thing that you probably need. If it's not perfect, at least you get it right away and it's probably good enough and you'll end up working with  

[00:14:00] Unknown:

it to to make it work. And particularly as you move into the sort of machine learning space, I think an analogous set of tooling is the growth of these AutoML libraries that will take your input data and you say, this is what I wanna try and do with it. And so it will automatically apply, you know, linear regressions or k nearest neighbors or, you know, gradient boosts to decide, okay, this is giving us the best, you know, performance   for this particular model. These are the parameters that I'm going to optimize on. And, you know, it allows somebody who isn't a full blown data scientist or who isn't a machine learning engineer to be able to apply these techniques to their data, but then you also end up with the, you know, the foot gun of I've done this thing and it's given me this answer, but I don't necessarily know why or have a lot of confidence in the level of accuracy that it's generating because I don't understand everything that's happening under the covers. And I'm wondering what you see sort of as people move from, you know, along that hierarchy of needs of, I just need to get my data from point a to point b. So I've, you know, I've bought Fivetran to, you know now I want to be able to do sort of predictions on my stock levels so that I can make sure that I don't run out for Black Friday. So I'm going to apply this AutoML algorithm and sort of where those challenges come in as you get these levels of sophistication and the tooling that let people who don't have all of the foundational knowledge apply these more sophisticated techniques.  

[00:15:22] Unknown:

I guess it's sort of a 3 step process. It seems like we're where we are, where we're going, and I'm not sure what's in the middle. It's a little bit of like the, you know, do this thing question mark profit. Where we are now   feels like   we do an okay job of this sort of thing. There are certainly ways that people who are less technical can use these kind of   models and that kind of stuff. I think on 1 hand,   it feels like there we still have a ways to go in that though. And part of that is that the models themselves can be can be sensitive.   They'll get things wrong.  

People, I think, are skeptical of kind of the black box. This thing is gonna tell me exactly what to do.   Looking more for something to sort of guide them, but not something that they, like, can't understand. And there's still still a lot of that. I also think that those things tend to be a little bit too generic.   So they tend to be focused on   not a very specific problem, but kind of specific   sets of problems. And that makes them hard to to actually like work exactly. Sort of like, great, apply   a predictive thing to what? Well, it's just generally a predictive model, and it's like, that's probably not gonna be   narrow enough   to really be something that that people trust. The other thing is, as you said, a lot of times they are prescriptive. You can't really tune them. I don't know that that matters that much in part because a lot of the people who are the the sort of quote unquote technical people, the way in which they tune them isn't that precise anyway. Like a lot of those folks that are people like me included can tune it, but we're largely looking stuff up on Stack Overflow anyway. And like, we're not exactly we're still kind of users of the of the application   ML parts are essentially buried where nobody even really knows they're there. Like like, it doesn't   at the end of the day, what a operations manager cares about is how many things should I have in stock? The fact that an email model is the thing that told them that, like, right now, I think that sort of works because it feels buzzy and it feels like it's smart and this is the right thing to do. In the future, who cares?  

Like when I log in to to   Salesforce to look at how we're doing in this quarter, I don't care at all what technology's underneath it. I just want the information it's gonna give me. And I think that's kind of the same where this ultimately is headed is right now when we think about kind of bringing   data science and ML applications   to the sort of masses.   There is a lot of putting the ML at the edge where it's like, look, this is this plus ML. It's amazing. And it kinda is buzzy and sells. I think eventually where it gets is like the ML part, who cares? Nobody's actually buying that. That's not the thing to market. It's not the thing to talk about. What's I wanna talk about is   you no longer have to think about this problem as an operations manager in your warehouse.  

Maybe you get there because of an ML model. Maybe you get there because you can predict the future. Maybe you get there because   your soldiers are sold down by the railroad tracks, and now you can tell exactly what's gonna happen. Like, I don't care. I just wanna know that that problem. And so I think, like, we'll get to that point where the ML thing just becomes   yet another tool for developing applications   rather than being this kind of like forefront, the edge of the edge of technology type of thing. Like,   I've never thought of this knowledge until now, but but, like, the crypto world, which is not a world I understand at all, feels like it's very much in this where every sort of crypto application is like crypto forward. It's like, it's the blockchain. It's like, I don't care if it's a blockchain. Solve the problem.  

You use the Blockchain to do it, great. But eventually, it'll get to a point if   the crypto enthusiasts believe it will, where   the blockchain is just an assumed part of the the way it works and and nobody's actually marking the fact that it's built on that infrastructure.  

[00:18:50] Unknown:

Yeah. It's very analogous to the evolution that the software engineering community went through and is still going through in some places, but where, you know, people get they get their identity very closely tied up with the code that they write, and they forget the fact that nobody cares about the code. Like, nobody cares if you wrote 10, 000 lines of Python code to be able to build this amazing application. What they care is that the application does the thing that you told them it would do. And I think the machine machine learning community is starting to go through that same experience of, you know, yes, machine learning is great and all, but nobody cares about that. They just wanted to do the thing that you said that it would do and and not have to worry about how it works.  

[00:19:27] Unknown:

There's this this conversation kind of among the the analytics community, which I guess is, like, adjacent to this. It's the analytics folks tend to be the, like, fly the SQL flag, doing more of the, like, insight analysis type of stuff, but all kind of the same world. But there's kind of this conversation now about analytics as a craft and sort of the focus on   the quality of the analytical work that you do and the quality of the code you write and things like that, which I think is as   a kind of I think it's a useful thing to think about as an analyst and sort of how to do a good job of what   you're doing. But I think to that point, there's like this overemphasis sometimes on it where, like, the result is what matters. Nobody cares.  

Nobody's choosing to use your analysis because they think it's beautiful. Like, they want it to work. And engineering is kinda like that where, like,   yeah, it's a craft of sorts. The beauty of it is not the elegance of the code you write. It's just like make the thing work. And if you can the code is elegant that does it, cool. That's great. And that probably makes it easier to extend and all  

[00:20:28] Unknown:

sorts of things. Like, that's not really what we're here for, and we shouldn't sort of elevate  

[00:20:30] Unknown:

the craft side of it outside of the the sort of end result of the application. I think ML, yeah, is is still in that phase of, like,   ML, let's celebrate it. But I think we're transitioning to, as you're saying, where it's, like, eventually it's   ML as assumed or it's not, but nobody really cares. The point is what it does. Absolutely.  

[00:20:46] Unknown:

And so to that point of being able to focus on the experience of working with the data and not just the specifics of the technical craft of it or, you know, the the data elements of being able to get everything wired together properly. I'm wondering how you see   that shift in focus being beneficial   to the practitioners   and the consumers of the technology and how that might help in terms of the overall alignment throughout the organization   of how the data is consumed and applied.  

[00:21:18] Unknown:

As the sort of data stack has evolved,   different tools have sort of carved out their their different   niches in it and things like that. And I think especially for   folks who aren't the the technical users, whether they're not data scientists or analysts or whatever, but the people who's people who are meant to be consuming all of this. So so there is somebody at the end of that that is what all of this is purportedly for,   where it's to help a decision maker make a decision.   It's to help   power an application to to do something, whatever the case may be. By focusing a lot on, like, the individual tools of, okay, how do we get data from point a to b, point b? How do we transform it when it's there? How do we analyze it?   We're we're basically serving each individual need rather than this broader experience. And so my view is once to to really serve those in folks, to serve the people actually trying to make use of the data, kinda to the point of, like, they don't care about the craft or the analysis or the email models. They also don't care about the tool chain that's underneath it. It doesn't matter, like, was it 5 Tran that did this thing, or was it GBT, or is it is it Snowflake, or is it BigQuery, or whatever. Like, they care about, do they get the data when they need it, the time when they need it? Are they able to communicate with it? Are they able to solve the problems that you solve with it? And I think   now that we've sort of solved a lot of these component parts of the stack, 1 of the big things that people are gonna start having to think about is how do we make that experience   better? That there's this this famous phrase, this is like a a sort of Silicon Valley   pop management   sort of phrase about it. I I Conway's law, I think is what it is, which is basically you ship the that may be wrong, but you ship the you ship your organizational structure.  

That if you have an org chart that's like you have a back end engineering team and a front end engineering team, the product you build will have, like, a a back end element and a front end element, and your customers will realize that. Your customers will see that split because the back end team works together and front end team works together. The modern data stack is essentially a single experience to most customers. Most people, it is a place for me to access data and make sense of it. There's 10 tools underneath that, and we are going to ship that org chart. And that org chart that org chart isn't just like departments. That org chart is different companies. And so there'll be very distinct lines between   ingestion and storage and transformation and consumption and observability and all those sorts of things. And I think that makes for a very, like, disjointed experience for those people who ultimately what they care about is the singular product that they're using. And so I don't know how exactly we solve that. I think companies are starting to try to figure this out. Like, do we integrate with each other? Does there become sort of wrappers that go around it? Does it all consolidate under,   like, the Google overlords? But at some point, there there if we think about sort of data consumption as as the kind of ultimate experience of this,   we need to start building that experience rather than building just a series of parts that eventually lead up to it. And so, you know, I I don't know exactly what that looks like. I kinda have my own perspectives on it. Obviously, from from Moe's perspective, we have our our kind of opinions there. But I think over time, that's where we wanna get is thinking about the data stack as a singular experience that you can move fluidly around as opposed to,   15 tools all glued together through through some, like, kind of weak APIs.  



[00:24:19] Unknown:

And another interesting   perspective on this that I've seen when talking to a company called Cinchy recently is   completely,   you know, rotating the view of what the ownership of the data is essentially, where right now, the data is a component that all of these different   pieces of the stack and applications that we build   take ownership of for certain periods of its lifetime. And so you have to hand off that ownership as it traverses the various systems.   And instead,   using a a term that they used called dataware, where rather than having hardware or software, you know, data is the central element.   And so it is   what is the core of the infrastructure and the architecture, and your applications just interact with it versus the other way around. And so I I think that's another interesting way to think about maybe   how the data can be the more central element and all of the different players in the space are just, you know, contributing their capabilities to it, whether it's for being able to analyze the data or generate and mutate the data where it lives and have these different views of it. So it's another interesting perspective to this way that we think about the experience.  



[00:25:30] Unknown:

Yeah. That's actually a really I've never never heard that particular framing. That's actually a pretty interesting I don't know exactly what that looks like. That's pretty interesting what I think about it. Because it is there is   a lot of, like, telephone effectively happening between these things where it's like Fivetran takes it and they hand it off here, and then Redshift takes it and they do something to it and they hand it off here. And it's sort of like there isn't a clear sort of owner of any of that. I I have thought of this before as is there eventually needing to be something that is kind of a single place everything plugs into. I've referred to this before as like an OS. I think it, you know, you can call it whatever you want, but but basically   something like that where   if I am mode, I am I'm being able to connect to part of the system that has awareness of the rest of what's happening. Because right now, the warehouse is effectively that, but the warehouse isn't doesn't know what else is going on. You're just, like, querying stuff. All you're doing is accessing the the bucket of stuff that it's holding.  

But it's not it's not aware of the stitch jobs that are running before. It's not aware of the airflow flow jobs that are powering it. It's not aware of   the the metric stores that are sort of downstream from it. I thought of there being, like, some way to sort of bring that stuff together to give Millet a single place to talk to that says, okay. Here's all the things that are going on the system. This is the moving parts. We can kinda help coordinate with that. But there's, like, data where kind of analogy is interesting where instead of thinking about it is we need to get another application that is   the switchboard for this game of telephone.  

It's more of what if the data itself   was the thing like, what if what if the information was contained in the data itself and we all just sort of read from that that source system? I don't I don't know I don't know. That that's I don't know exactly how that goes, but that's actually kind of an interesting approach to it is instead of thinking of, like, applications as as being the owners of this, it's like, why not just imbue ownership into the data itself?  

[00:27:12] Unknown:

Yeah. It it definitely brings in some interesting   sort of questions and, like, how do you go about the implementation details of that? And to some extent, I feel like the current focus of the kind of metadata fabric as this connective tissue across all of the different   elements of the data experience is starting to go in that direction. But then, you know, you still have to deal with those changes in ownership and making sure that there is immutability at different stages of, you know, working with the data so that you can kind of go back in time or have different views of the data. So there there are a lot of complicating elements of it, but it's it's an interesting   ideal.  



[00:27:49] Unknown:

Yeah.   Yeah. And, and, you know, there's a, there's a lot of the sort of like data mesh type of stuff   here now of, of maybe the way the studio is sort of decentralize it. This is, this is now, like, edging on   being able to actually make some sort of data mesh on the blockchain plane,   which I have no idea what that would mean, but I'm sure some VC would throw a whole bunch of money at it.   But   but yeah. There's there's a lot of stuff there that's interesting. And I I I imagine that gets even more kinda to the to the point about, like, you shake the bottom of the tower, the top vibrates even more in in, like, a a productionized   ML world that seems even more important where   all of these pieces, you know, you have you have production systems built on top of this. It's 1 thing to say, hey, or, like, this stack makes sense for the dashboards that our executives are looking at or for for the kind of operational managers or whatever, is another thing when   those are the pieces that power your product or those are the pieces that that sort of define whether or not your business is successful or not, that you need that   system, that sort of nervous system a little bit more. And so I I don't know. I don't know how we would solve that. But but the this yeah. That approach of, like, the data being the the key to it is actually kind of interesting.  



[00:28:59] Unknown:

And to the point of this sort of pyramid and the quote, unquote hierarchy of needs that you see applied to basically every area, you know, with with the sort of data hierarchy of needs is, you know, being able to have the data in 1 place and access it, and then moving up the stack of being able to analyze it, and then further up the stack of being able to build machine learning models on top of it. And to your point, a lot of times people will try to kind of, you know, skimp on the base of that pyramid and just go straight to the top because they just wanna get to the ML. I'm wondering what you see is some of the potential pitfalls and shortcomings of taking this technology first approach to the data experience and some of the ways that thinking about the desired end goal as a means of constructing that pyramid and that hierarchy,   how that can   improve the end to end experience of building these systems and working with the data? So yeah. So I think, like,  

[00:29:53] Unknown:

there's there's a technical answer to that and kind of a practical answer. And I think the technical answer is the easier 1, but but the less impactful 1. So the technical answer I think is basically   if you build if you build ML models and and systems, so not just like the model itself, but kind of the production system and stuff that powers it,   On a shaky system, like, that thing is not gonna tell you what it thinks you're thinking it's telling you. So an easy example of this is, say that you wanna build not in your product necessarily, but you wanna build, like, a customer health score for your sales team or your CS team. That's like, these are the health of all our customers. Let's try to figure out, you know, who's doing well and who isn't. If you haven't done some of the foundational work of   of being able to properly track the things that different customers are doing   or or defined   what an active user is in a particularly precise way, and you're just gonna throw in things at that, then then it's like a garbage in garbage out sort of thing where that that model will tell you something. It'll give you a bunch of scores, but those scores won't be reflective of kind of the reality on the ground. And so if your customer success team starts using that model to determine who to talk to or not, they're not probably gonna do a better job of finding the right customers to talk to that are on the cusp of churning versus the 1 that are really healthy that can expand. Like, sure, it'll do better than a random selection,   but   you haven't really solved much of a problem there. And so, you know, that doesn't mean that that you should, like, go   finish all of your reporting before you do that sort of stuff, but but understanding kind of what are the basics that drive customer engagement and things like that are the necessary pieces to actually construct that customer health score model in the first place.  

If you just throw a bunch of features into it and say, like, tell me who's healthy, you're not gonna get something that's terribly useful. Whereas if you understand the dynamics of your customers, which requires just kind of like basic analysis and reporting and those sorts of things,   then then you can say, okay. These are probably the features that matter. These are the ones that don't. Some things that that may not be obvious, may show up or some things that you think are obvious may not actually matter. The other side of that though, I think, is is more of the organizational 1, which is   the thing that makes the like, any sort of production model, whether or not that's internal production of, like, customer health score versus   or production in the sense that it's actually in your product, useful is you're solving a real problem. And and I think if you come at it from, like, the technical side, you tend to skimp on trying to solve what figure out what that problem is. That's a little bit of a cliche. Like, everybody sort of gets that intuitively that, like, don't build the technology, solve a problem.  

But I think there's there's kind of a   we often get sort of half fooled by that,   where   we're trying to solve a problem that, like, a customer asked us for a solution, and we're kinda like, okay. Yeah. We'll do that without realizing what the real root of that is. And so even things like dashboards, I think, show up a lot like this, where people be like, I need to look at a dashboard of these metrics. Right? Great. Here's your dashboard. And then nobody ever looks at it. And you're kinda like, why didn't you ever look at it? And the reason is they're not they're not actually asking to solve a problem with that. They came to you with some sort of prescription about what they thought they wanted, then they got it, and they realized, like, well, that's not really what I actually wanted to do. And so those sorts of things, I think it's like you have to really understand what they're trying to do. Like, what's the actual ends for which this dashboard is a means, for which this ML model is a means, for which any of these things are means. And once you figure that out, then you can then you can actually build something that's useful. So I think if you start with the tool   or even kind of the the notion of the tool that this will be a cool thing to build,   it's easy to to basically hear somebody wants a dashboard and be like, great. Know how to build dashboards. I'm gonna go build that. Or people say,   I really would like to know which customers are healthy. And you're like, great. I'm gonna go build a model to figure out which customers are healthy. You build that, and then they'll use it, and you're like, why not? And it's probably because, well, what is they wanna do that healthy thing for?  

And can you actually solve that more more directly than than   you should've realized and and then asking for a particular solution? So so I think part of it is is really just that. It's like getting at what are we actually trying to accomplish here and being really focused on that part is where these things get really bad.  

[00:33:43] Unknown:

And   as far as the sort of design elements that can contribute   to   improving the end user experience and some of the ways that as data practitioners   and people working in the sort of analytics and machine learning space,   How can we get closer to   properly understanding that desired end goal and not just go straight to, you know, know, this is the problem that they said that they want to solve, so I'm going to solve that problem and do it the best way possible when when that's not actually going to actually generate any real   to the organization or to your customers?  



[00:34:18] Unknown:

It's legwork, I think. It's it's like just working with the people that you're you're working with and trying to understand their problems   rather than than seeing yourself as someone who's like there to just provide a solution. So so I I've used this analogy for for analysts. I think it probably applies in this case too,   which is we often have   a lot of analytics teams are framed as internal consultancies. It's like an easy analogy to say, you're an analytics team. Your job is to sort of come in. People are trying to make decisions. You bring some data. They bring some context. You get together. You help them solve it. And you're sort of a consultant in that way of, like, someone call McKinsey,   they're gonna come in, and they are experts on 1 thing, you're an expert on another thing, and Google together, presumably, you'll figure something out. I think it's kind of a flawed analogy or 1 that that at least sort of changes the connotation   of the way this should work, where   you it sets you up to be someone who is coming in as an expert of something.  

And while, yes, you need to understand what your client wants,   McKinsey's gonna have their playbooks that they run. Like, they're gonna have some sense of the way that a business should be run, and they will tell you these are the things you wanna do, and it's mostly, I guess, lay people off or whatever. I think the better analogy is like, you are a detective showing up to a crime scene and these people are all the witnesses. And like, as a detective, you don't tell the witnesses,   I don't think what you saw is right. We're gonna do it my way. Like,   you you learn from them. Maybe you have to piece together different things. Maybe they're not entirely reliable, whatever.  

But but as a detective, you would never tell a witness   that's not right.   You would tell them you would just, like, listen to them and understand what they're trying trying to solve, and then come back. And if you come back with something that's like, your story doesn't quite exactly match what they said, but that's okay because this other person's story didn't either and, like, you have to get a way to reconcile it. That's fine, but but your job is to under like, you they are very useful pieces of information for help you solve this puzzle. And I think that's, like, a better analogy because it's not it's not you kinda telling them   your expertise.  

All you're trying to do is learn from them. And I think I think that's really the way that you have to approach it is   go to different sort of business stakeholders, whoever you're working with, and your job is just to learn from it. Like, they understand this problem so much better than you do about what they're trying to solve, what their actual pain points are, what actually doesn't work, what they would actually use. And so you have to, like, absorb a lot of that. And, eventually, it doesn't mean you're gonna build exactly what they want or whatever, but it means that that, like, you need to treat that as something that they get better than you do even if you see yourself as kind of like the expert data person or or whatever. So I think it's like a lot of it is just you have to work with people, you have to understand their problems, you have to, like, genuinely ask the questions and try to learn from it as opposed to   kinda coming in with some some priors about this is the right way to do it, and then see if you can convince them of of that.  

Or   a lot of it's us convincing them, but more seeing it as like, no. They don't really get it. Here's the right way to do it is a process that I think at least subconsciously happens to a lot of a lot of analysts and data people. And so I think it's it's trying to avoid that as best you can. And to the point of being able to  

[00:37:16] Unknown:

help the, you know, the business people and the customers   collaborate on   reaching the desired end goal and, you know, achieve the outcome that they're actually aiming for. How do you see the sort of design and capabilities of the tooling that we build and specifically what you're doing at Mode being able to contribute to that kind of iterative journey of, you know, I have a problem, so I'm not going to jump straight to an ML model. I'm first going to say, you know, here's a 5 minute query that puts me directionally   in the position of, you know, what they're trying to answer for. And then I can say, here is   a thing to look at. Is this what you mean? And then be able to iterate on that and then progress along that journey of I have a problem to now I have a machine learning model that's able to actually sort of maintain the desired status quo.  



[00:38:06] Unknown:

Yeah. And so so there there there's, like, 2 big pieces of that workflow that that are things that we believe in, and and it's reflected in the way that we want to build Node and kind of what the product is today.   1 is the the kind of iterative nature of asking those questions that   you you often start   not quite knowing what you're gonna do or, like, you have some notion of it. You take some approach to, maybe I'll try to solve it this way. It doesn't work at all. You have to go back and, like, you learn something in that process,   kind of iterate your way through it. Analysis of any sort, whether or not that's answering a question that your CEO sent you of, like, why are sign ups falling off a cliff? Whether or not that's building a model, whether or not that's even building sort of dashboards of core metrics.  

You can't really plan those things ahead of time. That you may approach it as like, oh, let's try it this way, and then you realize, oh, wait, that didn't quite work. And even just on the dashboard case, if you wanna have a dashboard of something like your sales team's win rate, you may first be like, well, let's just look at how many deals we started and how many deals we closed. And then you're like, wait wait. What do I do about these deals that are free trials for nonprofits? Like, do I include them? I'm not sure. Let me look at, like, what happens if I include them or if I don't. Does it really matter? Then you may be like, well, how long do I let trials run? What if this trial this 1 trial went for 4 years? Like, somebody in Salesforce didn't close it out. What do I do? So you end up with all these, like, weird things to figure out. And ultimately, the point is, what's the win rate for? What's it designed to measure? Gotta figure that out, then you can answer these questions. And that's like the simple case of just defining a metric, especially if you're doing analysis or trying to build a model, those things get even more complicated. So I think that that   part of that is being able to iterate through those questions really quickly with with the tooling that that doesn't sort of force you to build everything upfront. Like, you can't you can't write a blueprint and then go build it. You have to have a tool that sort of lets you build the blueprint as you as you build it. The second part is is really to the to the detective analogy bit, which is you have to be able to work with other people on it. It's not something that you can somebody can ask you ask you even again on the simple example, go build a dashboard of our win rate.  

You can't go into a cave, build it and come out with the right thing. Because you'll run into these questions like, I'm not sure how to handle this. And then you have to go back to the people who ask for it and be like, hey, do you do we care about this because we wanna know, like, the probability of us closing a lead because we're trying to figure out, like, what the value of a lead is, then probably the nonprofit thing should be included in the win rate because those look like leads initially, and then we end up not making any money. Or are we trying to measure, like, the efficacy of our sales engineering team? In that case, we probably don't care about the nonprofits because that's they're not losses. They're not things that should count against us for for a deal we lost. Just we didn't make any money, and and that's different. And so in those cases, like, you have to handle it differently, but that under requires understanding what the problem actually is and and, you know, what it is you're trying to solve. And so you have to have a platform to me that that brings those people together.   Anything that is   the analytical process as a group of technical people that writes SQL in Python,   and then   they're sort of just, like, assets that get ejected from it periodically to other people   is not actually reflective of what the actual analytical process is. The actual analytical   process is technical people or analysts or data scientists trying to figure some stuff out, hitting a bunch of things they don't understand, talking to somebody else to me, like, what do we do about this? That person helping them out, them going back and trying to figure like, you need to have a more inclusive process than that. And so if the tooling doesn't allow that, then then I think it makes it way harder to actually solve these problems.  



[00:41:21] Unknown:

And given the iterative and experimental nature of being able to build these analyses and understand   what is the actual goal that you're working towards, I'm wondering what you see as the impact of how we name these roles and these techniques where, you know, in the early 2000,   data science was all the rage. And everybody was talking about data science, and, you know, that's   still a term that's used in a position that exists, but it's been fading in terms of its,   sort of monolithic prevalence, where now that   role has been fragmented into, you know, the analytics engineer, the machine learning engineer, and, you know, it's not data science anymore. It's machine learning and artificial intelligence. And I'm wondering if you see the sort of phrasing of these things   starting to impact the way that we think about how we actually achieve these answers, where it's not an experimental process where we are collecting evidence and then iterating on it, and it is we just throw all of the data at the at the computer, and it does the learning for me so I don't have to understand the problem I'm trying to solve.  



[00:42:23] Unknown:

So I was initially   skeptical of this. Like, I I I am a I am a, like, sort of the   ML will solve our problem all of our problems skeptic, but I'm kinda coming around.   So so I think the reason that I am a skeptic   is   the ways those tools have largely solved problems before   has been they they you give them a dataset or you give them a set of things, and they basically, like,   just   sort of blindly try to find a bunch of stuff in that dataset and tell you here's some stuff that's interesting. And so   Google Sheets even does this, where if you give Google like, you put in a big CSV into Google Sheets, and it'll you can push a button, and it'll be like, here's some insights, and it basically finds a bunch of correlations and things like that. And it does this kind of, like, auto build some models to say, hey. Did you know that cars with 6 cylinders tend to even horsepower the cars in 4 cylinders? Look. We found this relationship in the data. And you're like, that's cool. That's not really how the like, the analytical process in somebody's head doesn't go that way. It goes with you see that of cars with 6 cylinders and 4 cylinders have, you know, more horsepower or whatever. And then you think about, like, where do I go from there? What's the next step in that? Like, what's the what do I sort of drill into   to to learn more from that? And then you figure out something there, and you kinda progress down the tree until you find something actually interesting. And I think that, like, the easy approach from, like, a ML model doing all this stuff for us is the first 1. We're just, like, sort of fan out, ask a bunch of questions of correlations, and then find some interesting stuff. For the most part, it's not that interesting. Occasionally might be, but it's really a starting point. It doesn't seem that   far of a reach, especially with how far a lot of, like, the ML stuff has gotten and and the AI, you know, things like   like open AI and stuff like that, that you could start to mirror more of what the analytical process looks like, where you are you are instead trying to sort of, like,   spider your way through the series of questions that you might ask to get to something that's actually insightful.  

So I could see us actually sort of getting there. No. I think the I think the hard part of that is it's really hard to then   know what is interesting and, like, you have to have a bunch of business context to do that. And how well do those things know that? I have no idea. Like, this is not my area of expertise of knowing the ins and outs of of OpenAI. But it seems actually conceivable that that could happen. That you could you could instead of building a thing that just finds a bunch of correlations in large datasets,   start to mirror the way that, like, what is the analytical process that people follow   and and have a a sort of meta AI that sort of conducts the the next steps of the analysis for you and then something else that sort of does it, like, does the actual comparisons   fit would actually get you there. And so I I don't know. I I have, like, been skeptical of this for a while, but but it seems maybe foolish to to sort of underestimate  

[00:45:03] Unknown:

where this stuff could be in 10 years. And as you have been building the mode product and working with the analytics community and the data community. I'm wondering what you have seen as some of the most interesting or innovative or unexpected approaches towards building these positive data experiences and the, sort of overall capabilities   that that brings to an organization.  

[00:45:26] Unknown:

I mean, I would go back a little bit to 1 of the answers I had before. And this isn't this isn't innovative. It's more   courageous, I guess,   where it's it's the people who are very prescriptive about how to do stuff and say, we're gonna make this really simple and not that flexible,   and that's what you're gonna get, and then stick to those guns. I think it's hard when you're building a product to stick to that, like, no. We're gonna do it this way. Sorry. We can't change those options or we can't make it that flexible. But I think the payoff is there if you get that right. And so,   you know, the 5 trans stitch, I think were early versions of this. Some of the reverse ETL tools are kinda newer versions of that, where they they   again, rather than saying, hey, we're gonna give you kind of an open platform for developing all these things.  

They're basically like, nah, you're gonna fill out some forms and push a button and the whole thing is gonna work. And so I think I think there are some lessons to be learned in that for for the rest of us around where you really understand the problem that's trying to be solved, be super prescriptive about it. And and I think on the ML side,   that that can certainly apply where, again, it's it's like let the model   do exactly 1 thing and just do it really well and and not worry so much about the specifics. So so for instance, there's I don't remember the name of this thing. I should remember this. But there's there's something where you can basically remove the background of a picture. So you have, like, a headshot and remove the background, and that's all it does. You upload, like, the picture, and it it might be called, like, remove dot bg or something. You upload a picture and it just strips out the background and gives you, like, like an image that's that's transparent behind the the person's head or the horse or whatever it is. It's like in the foreground.   1 thing does it really well. Like, that to me is the kind of thing that's a a super good application of this because it's not attempting to be,   okay, trace this thing or figure this thing out and and do all these, like, parameters. It's just like, we're just gonna we we have no options. The only option is you upload a picture and then we give you a better picture back. And, like, that to me is is where I think we'll start to see a lot of this kind of innovation that actually makes   data   and and ML applications more widely used is is again burying the ML   part and just focusing on what does this thing actually do for people? Let's just do a really great job of that, and the rest will take care of itself.  



[00:47:30] Unknown:

Yeah. It's the the the classic,   of forward sales model of you can have any color you want as long as it's black. Yeah.  

[00:47:37] Unknown:

Exactly.  

[00:47:39] Unknown:

And in your own experience of working at Mode and building the product and working with data analysts, what are some of the most interesting or unexpected or challenging lessons that you've learned in the process?  

[00:47:50] Unknown:

So   I a lot of things, I think. I think I think the thing that has been 1 of the most surprising   is just the   variance   in   the variance in desires to work with data and ability to work with data across organizations that it that they're   if you were to have like a 2 by 2 matrix of people who are like very skilled and not at all kind of technically skilled in data, and then people who really want to be able to kind of ask their own questions and answer them, and people who really don't wanna do that.   Those things aren't back related. And you have people kind of in all different quadrants. You have people who are technically very skilled,   but are now execs and, like, never make me do anything. I just want you to tell me exactly what to do. You have people who who have just barely sort of dabbled in Excel, but really like the idea of getting their hands dirty with it and and being able to to play with it and don't want something that's super prescriptive. They want something that,   like, they don't trust it until they sort of create it themselves. And so I think, like, as as a data industry, whether or not you're an analyst trying to provide stuff for folks in your company or trying to build models for people in your company or if you're trying to build products for those people, figuring out how to navigate that isn't easy because it's not   when we first started, I expected data to be more like design   where you have designers and you have non designers. And for the most part, those are 2 very distinct groups that that most of us are not like, yes. Give me the file that I wanna be able to drag stuff around.  

It's not a technical gap. I mean, in in my case, it is, but it's even for people who may not be, like, they're not they don't want to design something. They like there are designers who do the design, and there's other people who look at it. And and data is like not that at all. There are some people who look at it. There are some people who could do a lot more than look at it, but all they wanna do is look at it. And there are some people who are like just learning it, but they really wanna play with it. And so   it it makes it a much sort of more difficult kind of thing to to sell and to build for and to make the right products because you have so many different types of people that could be using it.  

It's not gonna be just like   the technical people or the nontechnical people. You have all these different overlapping people who are of different levels of comfort, wanna do different things, and and figure out how to navigate that so that everybody gets something that that works okay for them is is a pretty big challenge.  

[00:49:58] Unknown:

And so for people who are looking   to build sort of more effective products and solutions to the different applications of data, either for their own personal uses or within their organization?   When is the sort of experience first mindset the wrong approach, and they might be better suited just going straight for the tooling and technological aspect.  

[00:50:19] Unknown:

I mean, I I think that that   there are times like, don't don't overthink it, basically. I think there there are times when   you just need to solve a problem,   and   you can you can over design the experience too. Like, you can over overthink exactly how people are gonna use it. Sometimes people just like they just need the numbers. They just need a list of customers to call if they're a BDR.   They just need to know how many of these items are in their warehouse. Like, I I think there are there are times when in the same way that   that product designers   sometimes it's like, hey. We need to build this   thing. Product designers because and this is what they do. They want to be able to create something new and novel and something that's   that's better than what has been out there before.  

There can be a tendency to to, like, want to sort of overbuild.   In some cases, the right thing to do is just like, just go copy how somebody else did it. It's probably good enough. Like, we don't need to innovate on that thing.   You know, it's an invite flow, find a good invite flow and just use that 1. And so   in in that, I think there are some equivalent of that in in providing kind of data products or experiences for other people, which is there are times when you need to be innovative and think about, alright, how do we really make this work? But if it's just something that's that's   look, this exec needs a dashboard for their daily reporting on revenue. I don't wanna do it. It feels like grunt work. I wanna do it better than it's ever been done before, but chances are, like, that dashboard just needs to be built and that exec just needs it and just give them the thing and don't worry it too much. Like, I there there's I think, you know, think about where to be innovative and where not to be. And you don't wanna sort of box yourself in where now you have this this thing that's like a bunch of debt that you have to support that's gonna be hard to deal with. But but that doesn't mean that that everything has to be,   you know,   some cathedral for you to build. Like, there are times when you just need to build something quick and dirty, and and that's the thing that will do the job.  



[00:52:06] Unknown:

And as   you continue to iterate on the product at Mode and explore more of the data ecosystem, What are some of the things that you have planned for the near to medium term and some of the ideas that you have for how to help people   support this ideal of building   data experiences?  

[00:52:24] Unknown:

So yeah. So our our main   approach to this is   that in part because of what I was saying about there's all these different types of people that fit into different like, it's it's not a designer bimodal thing, everybody on 1 camp or the other.   You have to build an experience that can move kind of fluidly between different types   of work,   where   it's not just like, this is a very technical tool for technical people or this is a drag and drop tool for nontechnical people. Those tools will automatically hit sort of weird boundaries where there's an analyst who works over here who uses this other tool that's technical, and then I have to figure out how to, like, work with someone who's in the nontechnical drag and drop tool that they don't really wanna use. And so I think, like, we wanna build something that allows all of those people to work together in kind of an environment that makes sense to them. That if you are someone who's comfortable in in drag and drop charting tools and and sort of visual exploratory tools, we wanna go to give you that ability. If you're an analyst who's comfortable in Python, we wanna go to give you that ability and let you kinda hop between those different modes of working.   Our view is that that that helps in 2 ways. It helps, 1, by allowing everybody to work together. But 2, lets, like, people who   wanna use different tools for different jobs actually use them in a more seamless way. So if you're an analyst, for instance, you may wanna build a model in Python or or do a bunch of work in SQL because that's the language that you know.  

That doesn't mean that that pivot tables aren't useful. It doesn't mean that that end result isn't something where you could much more quickly figure out trying to figure out with a bunch of pivot tables. And so our view is, let's give you kind of each of those different   languages of analysis in, like, a lowercase l way where it's like SQL Python, visualization,   spreadsheet type of stuff, all those things so that people have the tools they need for whatever kind of piece of the analytical flow that they're in. Whether or not that's because they're an analyst who just would prefer to use a pivot table for this part of the job, or whether or not that's because they're a finance person who pivot tables are the way that they work. And if they see SQL, they don't wanna have anything to do with it. But they can, you know, they could build an ML model and a pivot table somehow because they know everything in Excel better than the back of their hand.  

[00:54:25] Unknown:

Are there any other aspects of the work that you're doing at Mode or this overall idea of building data as an experience and not just as a combination of tools that we didn't discuss yet that you'd like to cover before we close out the show?  

[00:54:38] Unknown:

I mean, no. Like, no. I think this this is pretty good. I the the only thing I would say is is it it kinda requires ultimately kind of an effort from everybody to to get there. I don't think I don't think 1 tool solves that problem. Mode on its own does not solve that problem. The other pieces of the data stack don't solve that problem. And   individual analysts and companies have to start also thinking about this. Like, we have to as as as I said, I'm at the beginning of the show, I'm both involved in building mode, obviously, but also am responsible for a lot of our own internal analytics work.   And so we have to think about how we actually serve that experience to our customers. The the the tooling again won't fully get us there. And so it kind of it all has to start to work together around, okay, we as as the people ultimately providing the things to our customers and to companies and things like that, As analysts, we have to think about that too where we can't expect the tool to sort of magically hand us this experience. It ultimately is is a thing that we are creating and sort of there's there's a a broader notion,   in the the kind of data community now thinking about, like, data data as as a product, as serving a kind of product. We should think of ourselves as product people, basically, where the data is our product, sort of all data and all of applications.  

And I think we, like, need to adopt some of that mindset too for this to work that that it's not just, again, the tooling won't get us there unless we're we also have that same mindset.  

[00:55:52] Unknown:

Alright. Well, for anybody who wants to get in touch with you and follow along with the work that you're doing, I'll have you add your preferred contact information to the show notes. And so with that, I'll move us into the picks. This week, I'm going to pick a podcast I started listening to recently called Venture Unlocked. And so it's a podcast by a venture capitalist interviewing a bunch of venture capitalists about their experiences of building and managing different funds. So it's definitely a very interesting view on that overall ecosystem that can seem very opaque if you're not part of it. So, definitely worth taking a listen to if you are in a startup   or, you know, involved in any of that ecosystem or just curious about it. So with that, I'll pass it to you, Ben. Do you have any picks this week?  



[00:56:33] Unknown:

Yeah. So there's there's I would say 2 things. 1 is data related, 1 is not. On the data related stuff as as, you know, I I've been involved in in basically writing a lot more yelling on the Internet.   And as a result of that, I've found a lot of things that other people are writing. There's a handful of, like, blogs that are that are people, I think, who are some people have done this for a while, some people less so, that I think are worth checking out if you're interested in sort of stuff. So a handful of names.   There's Bobby Pierneau has 1 called Rap Text,   that's associated with a startup equals. I think it's pretty good about this stuff. Randy Oh has 1 that's called Counting Stuff. There's,   1 called Ray Data Co. That's pretty good.  

It's it's really good at some of those things. And then and then the modern data democracy is another substack that's relatively new. That's good too. So there's there's a bunch of these sort of things out there where people have these conversations that if you're interested in it, I'd I'd recommend checking it out. It's it's like an interesting conversation to follow along with if you wanna be kinda   see what's going on in the data tooling landscape and things like that. The non data thing that I have I have been   invested in recently,   is basically everything with the Theranos trial and the the bad blood podcast.  

The bad blood book is really good. It's book by John Cario, who is the Wall Street Journal reporter who did all the reporting on it, kinda broke the story. And now he's having a podcast that's following along the Elizabeth Holmes trial. I find it fascinating. It's like a fascinating intersection of of sort of the tech and Silicon Valley world,   that I obviously been part of. But also just like how it all happened is crazy that, you know, they managed to raise a $1, 000, 000, 000 and, make a $10, 000, 000, 000 company on something that didn't even exist. It just is nuts to me that that was able to happen. And so I think, like, those that that whole story is is fascinating to me, and the podcast is good. So that's what I check out. And it does a good job of covering sort of the background if you haven't read the book too. So Alright. Yeah. I'll definitely have to take a look at those. So thank you very much for taking the time today to join me and share your perspective on this, overall space of building data experiences and how that can provide better outcomes for people who are working in the space. So definitely appreciate all the time and energy that you put into building mode and contributing to the ecosystem, and I hope you enjoy the rest of your day. Thanks, and thanks for having me. This is great.  

[00:58:46] Unknown:

Thank you for listening. Don't forget to check out our other show, the Data Engineering Podcast at dataengineeringpodcast.com   for the latest on modern data management.   And visit the site at pythonpodcast.com   to subscribe to the show, sign up for the mailing list, and read the show   notes. And if you've learned something or tried out a project from the show, then tell us about it. Email host@podcastinit.com   with your story.   To help other people find the show, please leave a review on Itunes and tell your friends and coworkers.