Ep. #10, Data Modeling Matters Most with Toby Mao

Dori Wilson: Hi, I'm Dori Wilson, Head of Growth and Data at Recce. Welcome to another episode of Data Renegades.

CL Kao: And I'm CL, CEO and Founder of Recce and your co-host. Today our guest is Toby Mao. Toby is the creator of SQLGlot and co-creator of SQLMesh, two open source projects that have changed how the data industry thinks about SQL.

He built them into Tobiko Data, which was acquired by Fivetran last year. Before that, he led data infrastructure at Airbnb and Netflix. He's also a former Rubik's Cube world record holder who once taught Will Smith how to solve a cube for the movie The Pursuit of Happyness.

Hello, Toby. Welcome to the podcast.

Toby Mao: Hey, thanks for having me.

CL: Yeah, it's good to have you. So let's dive into your involvement in data. Can you take us back to the beginning? What problem first pulled you into the data space?

Toby: Yeah, so that's kind of a long story, but I graduated with a degree in math. I was looking for whatever company would hire me. Ended up landing at a pharmaceutical consulting company called Beghou Consulting. And that's where I got my first foray into data programming and data analysis.

So at that company, I was mostly using SaaS and Excel and basically crunching pharmaceutical numbers like prescriptions and sales data. And I actually enjoyed SaaS a lot. I enjoyed crunching numbers and building reports and all that kind of stuff.

Eventually I got tired of that and decided I wanted to become a real software developer. So I spent a little bit of time doing iOS and then I managed to land a job at Scribd, kind of like documents and ebooks online. And I started to do Spark there. I started working on recommendation systems.

And so that's kind of how I got into big data. And then from there I went to Netflix, Airbnb, and then started Tobiko Data.

Dori: How do you feel your consulting background initially played it into your later roles?

Toby: I'm not sure. But working with clients, they have needs. And you kind of learn how to talk to them and how to have relationships with them and build stuff for them. And so I think that it definitely helped me later in the career because it's not just about your technical skills. Right? It's also about dealing with customers and sales.

Dori: Yeah, definitely sales. I think I've heard it like the larger companies, my own experience, internal sales can be another way of talking with stakeholders, pitching them on different ideas.

Toby: Yeah, exactly.

At Netflix and Airbnb, I did a lot of internal sales. And so starting my own company trying to sell a SaaS product was honestly very similar. T he experience of technical selling was very relatable. I think the biggest difference is just that you don't have the same kind of political motivations or internal alignment that makes things easier internally versus externally.

Dori: Oh, interesting.

CL: Okay. So you started studying math and then went into consulting and then wanted to do more of the software side. Right? And then going to these big companies, figuring out the internal data infrastructure. So what was the spark that led you to kind of launch ideas like SQLGlot and SQLMesh?

Toby: So when I was at Netflix, I worked on the experimentation platform and that revolved around data scientists basically adding queries to the metrics repository. And that was mostly SQL. But at Netflix, they have unimaginably large data. They also have multiple engines. They use Spark, they use Trino, they use Druid. And all of these engines have very different dialects. Right?

Even though there's a SQL standard, nobody really adheres to that and everybody has their own implementation. So when I was at Netflix at the time, there weren't any real good solutions. And so I used a library called PyPika. PyPika is kind of like a Python SQL builder. And I extended that to do transpilation so that they could use PyPika and we could then compile the Python code into Trino SQL or Spark SQL.

Towards the end of my tenure there, I realized that data scientists don't want to write Python. It's hard, right? They want to just write SQL, but there was no way to parse a Spark query and then run that in Trino. And so that's kind of where I got the idea for SQLGlot, building a SQL parser and transpiler so that you could write SQL in one dialect and run it in a different one.

Dori: That's cool. So you built that out internally then?

Toby: Yeah.

Dori: What was something that, building it out internally, you found different, easier or harder than when you went and started Tobiko Data?

Toby: You know, I built it as a kind of side project and then I later decided to go to Airbnb and they had a very similar problem. They also use Trino and Spark, amongst other engines. And so I decided to leverage SQLGlot when I was at Airbnb and that gave it a lot more use cases and made the product more mature.

And so it was nice because I could kind of just use it because it was fully open source and it basically got automatic adoption. I had a great use case for it and it drastically improved both the platforms I was working on and SQLGlot itself.

Dori: So it was almost like you're getting to do some early design partner refinement at another company.

Toby: Yeah, exactly. And then, around that time as well, other companies started using SQLGlot heavily, like Google, et cetera. And so the project started having more traction.

Dori: And that's because you had made it open source, right? You'd already had it available?

Toby: Yeah. SQLGlot has always been MIT licensed.

CL: So you kind of filled the PMF pool internally for adopting that across different companies, right? But SQLMesh tries to solve a slightly different, downstream problem where the Actual user has kind of daily use of managing those queries. So how does that manifest into its own product?

Toby: Yeah, so SQLMesh is a little bit of a higher level tool than SQLGlot. Right? So SQLGlot is just the parser, transpiler and SQL general framework. But in terms of running DAGs and scheduling and understanding what has changed, that's where SQLMeshes come in. SQLMesh is really a full transformation tool that lets you run SQL or Python code.

CL: So yeah, when I had my hands on SQLMesh, I really felt it's like really well designed for idempotency. But I can see that where it's coming from, like it's pure function, like mathematics.

Toby: Right, Right. Yeah. So at companies like Netflix and Airbnb, there's a lot of data, Right? Processing huge, huge amounts of data and so doing things like full refreshing your data every day just doesn't really work. And so all these companies have date based or batch based processing where you process incrementally one day or maybe a week of data at a time, but it's done in a very parallelizable way and done incrementally.

And so I wanted to kind of build a framework, a transformation framework that first-class tracked state, understood time and all these kind of things. And being a software engineer who works on data platforms, I wanted to bring software engineering best practices to data. Things like deployments, checks, testing, all that kind of stuff.

CL: So I feel we've been down this trend of bringing software engineering best practices to data for at least five years now. Right? And then you are on the level, like the SQL Transpiler and then also the orchestration level, working with actual data consumers and authors.

So what do you think is still the hardest problem of data engineering today that nobody's really talked about or tackled properly?

Toby: Well.

I think at the end of the day, your data modeling abilities and how you structure things is the most important part. And that's probably only getting worse with the advent of and reliance of AI and LLMs.

I myself have been using AI very heavily the last couple months and it's been great. But I can see how it's a tool that benefits people who know what they're doing and kind of, although it enables people who might not know things like architecture and data modeling as well, and it can let them be productive. I'm curious about what the long term impact of that will look like in the next couple years.

Dori: What have you found it to be most useful for?

Toby: So my team at Fivetran has been highly leveraging Claude to refactor SQLGlot. So SQLGlot is a pure Python library and that's the design goal. I want it to be Python, no dependency, so that any data scientist or analyst can install it, run it, it's easy, right? But Python is not the fastest programming language, as everybody knows.

And so, it's honestly not that important for it to be fast because it's fast enough. Because the bottleneck for a data pipeline isn't the SQL parsing, right? It takes, I don't know, a couple milliseconds to do that and it takes seconds, maybe minutes or hours to run your SQL queries.

But when you're parsing a lot of SQL it can add up. And also people like things to be fast. It's kind of a hot marketing topic. Everyone wants to rewrite stuff in Rust. And so I had the idea in January to leverage Mypyc. So Mypyc is run by the folks who do Mypy, the Python type checker, and it is a very cool project.

It takes normal Python code that has been annotated and they can compile that into C code. C code that leverages the Python C API. What that effectively means is you can get anywhere from a 2-5x speed bonus just by having proper types.

Dori: Wow.

Toby: We've been using Claude to refactor SQLGlot to be fully type annotated and to compile with Mypyc. And it's an exciting day because today is the day that we're going to release v30 of SQLGlot and it is now up to five times faster than the previous version, which was written in Rust.

Dori: Congratulations. That's got to feel incredible.

Toby: Thank you. It's so exciting. Not only did we get rid of Rust, simplifying the build process, now we have a pure Python library that can compile to C that is arguably one of the fastest packages in the Python ecosystem. It is comparable to pure Rust libraries that have Python wrapper. So it's super exciting.

Dori: Yeah. Can it be used for other things as well? Like, how applicable could that be, like, I guess more agnostic than your use case?

Toby: So Mypyc can be used for any Python code that's typed. But AI was really, really helpful here because first of all, SQLGlot has thousands of tests, a ton of tests of all these different crazy edge cases. And so the LLM can refactor very well because it's not trying to do anything new.

It's not trying to create something brand new and novel. It's simply reorganizing things, things that are very tedious for the humans, but it's very good at. And because there's so many tests every step of the way, it's able to check itself, iterate and figure out exactly what to do.

And you know, I didn't really use AI too much before January, but I think after January something really changed with the model. I think the agents got a lot better. And so I had these ideas to do Mypyc, right? But I wasn't sure which one would be the right idea. And so with Claude, while watching Netflix, I was able to try 10 different things.

I said, hey, try this, try this, try this. And nine of the 10 things I tried, didn't run faster. But on the 10th attempt, while watching my cooking show, I was able to get significant speed ups. And so I think that's kind of the real power of it is like, you know, I was still giving it ideas, I was still directing it, but it was handling all the coding and I was able to do that because it was a well defined refactoring problem with thousands and thousands of test cases.

Dori: Yeah. So when you say well defined, were you using skills, workflows, like how did you make sure that the LLM didn't go off track too much?

Toby: Yeah. That's an interesting thing. So I don't really use any of that stuff. I just tell it what to do and I think my kind of talking style really translates well to it because I tell it exactly what to do.

And so I don't give it open ended problems. I try to break it down for the LLM and I say, hey, let's do this first. And then only once I'm satisfied with that one step do I move forward, because there's noise. Right?

Whenever an LLM does something, it doesn't do it perfectly. And if you keep just compounding off that, it gets worse and worse. And so I basically have the LLM do one thing at a time and then I review its code as rigorously as I would a human. And so that's my workflow.

Dori: So extensive planning and then a deep dive in the kind of the review stage.

Toby: Not even that much planning. Right? I do more iterations. Like I'll try different things and when I'm satisfied with a particular approach, then I'll do full implementation, benchmarking it, reviewing it, and then going on to the next step. So honestly, I don't really leverage planning that much.

Dori: Fascinating. But it sounds like you have a pretty-- It's almost like truly you are doing the planning itself because you have each stage and doing that iterative process until it gets there.

Toby: That's right. I obviously have a strong intuition for how SQLGlot is architected, because I wrote it. And I'm leveraging that to basically guide the LLM. But I do ask the LLM for tips as well. Right? I might not necessarily know what to do and so I'll ask you for different options.

One of the cool things that we've been doing is that Mypyc is still, it might be labeled Alpha, I'm not sure. But it doesn't work perfectly. Right? And we've created seven or eight PRs on Mypyc, which have been merged pretty quickly. Thanks, kudos to them.

Dori: Yeah.

Toby: But we were able to fix Mypyc bugs with LLM even though we've never used Mypyc before. And so that was really cool.

CL: Yeah. I'm definitely hearing a lot from very experienced software engineers leveraging AI in different ways and it all sounds really amazing in the past few months. But what are your thoughts about how that translates to data work? As in, the work you talk about is really deep in the transpiler with well defined test and then also maybe patching upstream like Mypyc.

But what happens to applying AI to data work? We touched on that. You think there's going to be maybe some slop generated, or how do you feel that it will work in real world data work?

Toby: Yeah, it's interesting. I think that data is interesting because the consequence of running a query is higher than running a unit test. Right? Because you have real world cost with BigQuery or Snowflake, especially if you have a lot of data and time. I think AI's optimizing that workflow is all about decreasing the loop time.

So you want your test to be fast, you want it to fail fast and get results. But if every time you run a query it takes minutes, it can slow things down and it can also cost you a lot of money. And so I think in order to improve the AI flow in data, you really need to figure out how to make that iteration cycle cheaper, both from a time and money perspective.

Dori: To shift gears a little bit, what is the hardest part of data engineering today that no one's talking about?

Toby: It's probably always just the data modeling, figuring out the best way to structure your data to make it so that change is easy.

I think that data from a lot of companies is a big advantage. And especially with AI becoming more prevalent and AI thriving with more context and more data, having a data pipeline that can grow with your business is very important. And so I think a lot of people in data, they might not have a software engineering background. But building a good data pipeline is very similar to building good software: understanding high level flows, architecting it in a way that changes aren't breaking or that changes aren't very difficult to make. These are all things that I think have very similar pattern recognition to building good software.

CL: I think you touched on how to plan things that are easy to change. I feel this is an under-appreciated thing because a lot of the time that things are built, it's kind of one off. So what are your thoughts on making that a more accessible, approachable kind of mantra for people building out things that's ready for more changes coming?

Toby: I think maybe the first part is less is more. Right? If you have fewer things, fewer models and fewer dependencies, then the changes will obviously be less because there's less stuff to change. If you've got intertwined spider DAG where everything depends on everything, when you make a change, of course you're going to have to change a million things.

Dori: Yep.

Toby: I guess tying this back to AI once more is like AI is very good at one shots. Like if you give it a problem it can solve it, but it might solve it in a really ugly hacky way. Right? I don't think at this stage AI can really make maintainable decisions.

There's actually an interesting study done, the Software Engineering CI Benchmark, and it showed that with a different kind of metric for AI competency, what it did was it took like existing open source repos and instead of one shotting problems for the LLM to solve, it would use its solution and have it face the consequence of those solutions. Right?

And so it would then go on to the next step and over the course of like one or two years in the experiment it would be like, okay, how many bugs have you introduced because of your previous decisions compared to the original source code? And it showed that even the best models today still introduce bugs one out of every four commits.

And so it's still not really there yet to do long term architectural planning. And so I think that kind of skill set is something that experienced developers grow an intuition for. And generally it's just things like doing less, keeping things dry, don't repeat yourself and understanding your data, how your industry could possibly change, and architecting for that.

I know it's kind of vague, but this is kind of an art form.

Dori: Yeah, no, it makes sense. I've had it where the LLM, instead of using an out-of-the-box test that's baked into like DBT utils created it as a macro which is just adding a point of failure that is so unnecessary into my repo and my workflows.

Toby: Exactly.

CL: So just to reiterate, I think it's like: no code is the best code, so fewer code better. Right?

Dori: Mhm.

CL: And you talked about like do not repeat yourself, all these kinds of best practices. I found myself just telling the LLM, "do not over engineer," and then YAGNI (you ain't gonna need it) until that thing is actually needed. That's also helpful.

Okay, so, you work on big data infrastructure in large companies. I wanted to ask what's the most painful bug or failure you've seen in production that you can talk about?

Toby: I guess an interesting story was when I first started at Netflix, I joined the streaming experimentation team. So the streaming platform is kind of how you watch shows, and then experimentation is basically testing if different encodings causes the stream to be smoother, stuff like that.

And you can imagine that the streaming data set at Netflix is one of the largest streams. Right? Lots of people watching Netflix all at once, and every second or more you're getting millions of requests. And so analyzing all that data is very difficult.

Netflix is an interesting company because they really believe in data. They are very data driven. And every single decision is data driven. And when I first got there, their experimentation platform, it took like a week to crunch all the numbers and provide results for a given test, which is insane, right?

Dori: Yeah.

Toby: And half of the time I think it failed too, so you'd have to restart the job. And so it was very expensive. And it was also all done in Hive. Hive was an older--

CL: Older big data.

Toby: Older tool. Right?

Dori: Yeah.

Toby: Spark at that time was gaining popularity and I was like, hey, why don't we use Spark for this?

And so over the course of a couple weeks, I was able to restructure the Hive code into Spark jobs. And instead of taking one week, I was able to get an experiment to compute in about an hour. Obviously I had access to 4,000 cores, but still, one hour is much better than seven days.

Dori: Yeah.

Toby: So that was kind of a fun and exciting thing that I did in my early days at Netflix.

Dori: A curiosity, as somebody who worked on a video infrastructure product: How much of the experimentation was done on the video quality itself?

Toby: Oh, yeah. The video quality team are one of the top experimenters. Right? Because how can you really understand the changes across every single possible network, across every single possible device? And so whenever they would make changes, they would test everything. They did even have offline tests where they used simulators.

CL: Cool.

Toby: So I would say that they're very, very rigorous. And that's why when you use Netflix, it's great, it's so fast and it's just snappy compared to other streaming services, which buffer for a long time.

Dori: Oh yeah. Well, and even when the player first starts off, like that low resolution, sometimes you don't even have that initial loading thing.

Toby: Yeah, it's amazing.

Dori: Yeah. A question since you've had big experience consulting and then building your own company, I'm assuming smaller, more mid-sized teams. What is something that you have seen across all these organizations that is a similar problem? And what do you think is something that becomes more of an issue as you grow?

Toby: So I think that when I started Tobiko, my experience at the big companies definitely set me up for a disadvantage because my team were all former FAANG engineers. And so we kind of came at it with the mentality that everyone had big data problems, everyone's using Spark and Airflow. And that's just not the reality. Right? That's the 1% or 0.1%.

Dori: Yeah.

Toby: Most people out there, most companies, they just use Snowflake, they just use BigQuery and they barely have any data, relatively speaking.

Dori: I think for our listeners, relatively.

Toby: Yeah. And so I think that after talking to customers, we quickly realized that, yeah, not everybody needs to process a petabyte of data every day. And so knowing that, we moved away from things like Airflow and into making integrations with BigQuery and Snowflake easier and more seamless. Right? And so I think that was kind of an interesting framing shift that we had to do very quickly.

Dori: Yeah.

CL: Okay, so you've actually built quite a lot of things. Right? But looking at the entire data stack, if you were to kind of rebuild one piece of this stack from scratch, what would it be now?

Toby: I'm not sure. Given that AI is hot, maybe something there.

Another area that I'm interested in is a new UI for data. I think that over time, as the LLMs get better at generating code, writing SQL or writing Python code directly might not be as important as understanding what's going on.

Dori: Yeah.

Toby: So for example, you might not need to see the assembly, the machine code. Right? You want something higher level. And so similarly I'm interested in how can we design UX such that a human can guide and understand what the LLM is doing efficiently without having to dig into the nitty gritty.

So that's something that I've been playing around with, like visualizations of real time data, updates, how they affect things, where the bottlenecks are and that kind of area.

CL: Okay, so kind of new type of UX enabled by AI, working with data?

Toby: Yeah. As a simple example, data diff. Right? When I change the SQL query, what does that do? How does that change the data? I want to see it. Right? If I look at two SQL queries side by side, I'm like, okay, whatever. But if there's like a huge CTE, how do I know how that affects things?

But for example, if you had a data diff, you'd be able to be like, oh, okay, this value changed. Right? And so I could then leverage that to then iterate more.

Dori: Yeah, I think that's, for me, and I'm curious your thoughts here, a big difference between data analytics engineering and software engineering is the output matters so much more than the actual code itself.

Toby: Right? Sure.

CL: Okay. So we touched on AI a lot. And then you've been experimenting with lots of things with AI. I f we fast forward five years, what do you feel is going to be laughably outdated about how we deal with data today?

Toby: Honestly, I don't know. I think that maybe we've hit a local maxima and things will be like this with improvements or things will get significantly more advanced. I'm not sure. Things are moving quickly and there's still a lot of uncertainty there.

But I think with the way things are trending, I think that directly writing code won't necessarily be as important. But I still think that architecture, understanding flows and guidance are still going to be important. So I think that in the next five years we will see a difference in how people interact and develop code. I think that it's more going to be based on these text interfaces or even voice. And the systems for dealing with them is more going to be around displays and real time feedback of what's going on and how to optimize that.

Dori: Yeah. If you were starting out earlier in your career, what would you recommend that more junior analytics engineers, maybe new grads should be thinking about and working on?

Toby: You know, it's so hard to say. I think it's a whole new world. And so for the juniors out there, I think it's a very interesting time. I would say that the fundamentals are still important because as of today, in order to be effective with LLMs, you still need to guide it, you still need to heavily code review it.

And so I think that the most important skill is reading code and understanding it and understanding how to improve it. I also think that given the tools these days, it's so much easier to learn.

Right? Because you don't have to just Google things anymore and hope that someone in Stack Overflow seven years ago had the exact same problem you did. Now you can ask the LLM how to do things. And so I would suggest that for people coming into this to leverage the LLMs as a teacher, so you shouldn't rely on the LLM to do everything for you. Instead you should use it as like an ultimate guide and have that improve your knowledge so that you can then use your intuition and knowledge to guide it to build the best thing.

Dori: And then for mid level and senior level, what advice would you have. Same thing?

Toby: So for mid and senior, I think that leveraging your experience reviewing and architecting is even more valuable now. And so don't get lazy is my suggestion. Don't just accept whatever it is builds for you. You should always challenge it and be ruthless with your reviews. So these productivity gains, if you want to always improve, you shouldn't be satisfied with them.

You should use them to do more than you would have before. You should be doing more benchmarking, you should be doing more variations to find the best. And so sadly these days I've been working more. Right? I t's good for the capitalists out there, but bad for my mental health. But effectively I wasn't coding that much before. Prior to January, I was mostly in meetings, sales calls, talking to the team.

Dori: Yeah.

Toby: But because I still have ideas, I still know what I want to do now that I can tell my LLM to do it. Now it's like, oh, wow, now I'm also coding. Right?

Dori: You just added it back in.

Toby: So yeah, you know, it's like a double edged sword. The good thing for me though is that coding has always been my hobby, making stuff. And so yeah, I'm doing more now, but I'm able to do it because it's so much fun for me. Like it's just like a hobby of mine.

CL: Yeah, I can totally resonate. I'm coding more. Okay, what's going on?

Toby: Right.

Dori: It's definitely the most lines of code I've quote unquote written. And especially like before it was like Python, SQL and now with Claude it's like I can do-- I have so many side projects I just have going in languages I do not understand which, pro/con, can't catch the silly bugs that I can when it's writing SQL or Python.

But I can create stuff that I definitely could not have before and certainly faster than if I had tried to struggle through. Is there a side project that you're working on? Unrelated to work?

Toby: Not currently, no.

Dori: Full plate.

CL: Yeah, I think you had board game side project before and stuff, right?

Toby: Oh, yeah, yeah, that's still ongoing. So back during COVID I created a website called 18xx Games. It's basically a platform to play hardcore economic train games. Yeah. And so that's still going strong. I don't really contribute to it anymore. I have many open source contributors and I know that's still going well, but I don't really contribute to a day to day.

Dori: Yeah.

CL: Okay, before we wrap, we're going to put you in like data debug run. So we're going to do a couple of quick fire questions and then just short answer. You ready?

Toby: Yep.

CL: Okay, cool. First programming language you love or hated?

Toby: I guess I liked Objective C. I had fun with that back in the day. The one I hated was VBA. I hated VBA.

Dori: Excel shout out for those that don't know what that is. Horrible, horrible language. Okay, next question. What is your go to data set for testing?

Toby: It depends on what I'm doing. If it's like SQL parsing, I use TPC-H. If it's for the actual data, I don't have a go to data set. I just use whatever I have at work.

Dori: Pure production data. Love it. What's one lesson from outside tech that influences how you build?

Toby: If you have fun doing something, it's not work and you do better when things are fun.

CL: Okay, what's one hot take about data you're willing to defend on the podcast?

Toby:

The data world would be more advanced if people applied more software engineering practices to it.

CL: What's your favorite podcast or book that's not about data or tech?

Toby: My wife has a board game podcast called Board Game Blitz.

Dori: Ooh, wait, what's your favorite board game?

Toby: It depends on who I'm playing with.

Dori: Oh, I love it.

Toby: Right? Everybody is different and I like to play all types of games. So if I have a crowd that doesn't really play games, I like The Mind. It's very simple, it's easy to play. Anybody can learn it. If I'm playing with hardcore gamers, I'll play something like Rolling Stock. Very economic, very crunchy.

Dori: Yeah. Have you played Acquire? I'm a massive board game nerd.

Toby: Oh, you are? Okay, yeah. I have played Acquire, but it's not part of my regular play.

Dori: Yeah, my current favorite right now is Dune Imperium.

Toby: Okay, I've heard about that, I haven't played it yet.

Dori: It's great. You definitely gotta have people that enjoy deeper board games because you're talking like a minimum 3- or 4-hour commitment.

Toby: My favorite game 10 years ago was a game called Twilight Imperium. And that would take all day?

Dori: Oh yeah. 12, 13 hours.

Toby: Yeah.

Dori: Typically my partner, for his birthday, that's the only way we can wrangle our friends that can do deeper games into it. It's a birthday celebration. We're starting at 9:30.

Toby: Exactly. Right. Yeah. I've had many birthday parties playing TI3 all day.

CL: Wow. Alright. Programming, like tabs or spaces?

Toby: Oh, spaces, of course.

CL: Great. Okay, so one final question. Where can listen find you and be helpful to you?

Toby: If you want to find me, I'm on the Tobiko Data Slack. It's tobiko-data.com/slack. I also have an Instagram, but that's mostly like Jiu jitsu and bread. So I don't know if you want to follow me there. Haha.

CL: Wow, this was super fun. Toby, thank you so much for being on the podcast.

Toby: All right, thanks for having me.