Moar badgers! Kevin Webster has entered the chat.

Ben: That's just reminded me of the Holy Hand Grenade. To three thou shalt count to two unless it is immediately followed by three, and four is right out. 

Josh: I think we just got our intro. we're, we're back after a, Thanksgiving break. I think we didn't release one last week. hope everyone had a nice, uh, holiday break. and we're back today, with Kevin Webster, who is a, engineer at Honeybadger. And, Ben Curtis is also here. as always. 

But we're gonna, we're gonna chat with Kevin, pick his brain about, some of the things we're working on, which is like his, I'd say, is it fair to say that Insights is Kevin's baby? 

Ben: I think that's fair. I think Kevin was the big motivating power behind. Diving into that. 

Josh: Yeah. Yeah. There's like a, there's like a whole, uh, I don't know, like rabbit hole in, in notion that is just like. Kevin's documentation on this thing. And it's really, I gotta say it's really impressive. it's like a wealth of information. and yeah. We'll have to, we'll have to get into some of that. 

Ben: Josh, you're killing me now. And then that with the Monty Python stuff, the rabbit and you know, the things, 

Josh: Yeah. 

Ben: I guess I'm on a kick today. So welcome Kevin. Welcome to the podcast. 

Kevin: Thank you for having to be here. 

Ben: I, I was thinking about the, our schedule. we're trying to do a weekly schedule, but we're not holding ourselves to it. We're not slaves to the schedule. And, I think we've got a grand total of two episodes back to back before we took a little break. So 

Josh: I blamed it on the holiday. The holiday, but it wa, I think that was just naturally, it was fortuitous that the holiday was there. 

Ben: The other day I posted on LinkedIn for the first time, I think ever. but I posted about founder quest and, I said, I was typing it out. I'm like, yeah, our weekly podcast. I'm like, wait a second. I went back and put [00:02:00] mostly in parentheses. 

Josh: Yeah, I've been like saying weekly ish or, yeah. but that seems to be a thing these days, like a lot of the weeklies have gone to like semi-regular. 

Ben: Maybe we should move to fortnightly just so that we can say it's a fortnightly podcast. 

Josh: Does that fit with our Monty Python 

Ben: Yeah, totally. 

Josh: Yeah. I don't know. 

I'm cool with being the one, the ones that are like the regular hosts. if we can, I think like we, it's pretty easy for us to like, sit down and just like chat about things that are happening in the week or whatever. So I like our, like our little format. 

Ben: So this week though, it's all Kevin. It's all insights. So Kevin, why did you decide to embark upon this quest that did eventually become insights? 

Josh: Well, also, I wanna know, what is insights? we've heard my version, we've heard Ben's version. I'm sorry if people are getting sick of this. Um, I promise like this, we're not, it's not gonna be the insights episode every episode of Founder Quest, but I'm really curious to hear Kevin's version of what it is. 

and then yeah, like why are we doing 

Ben: yeah, me 

Kevin: I want to hear, I want to hear your guys [00:03:00] version. I don't 

Josh: you'll have to go, listen, you'll have to go listen to the last two episodes. 

Kevin: Great. Uh, so what is Insights? That's a good question. I think, um, I think we get to talk about like what, how we, I don't know how, if you've talked about how we even got to what this thing is, cause I remember it was about a year ago, maybe longer, that we had decided that logging was a thing that we wanted to tackle. 

Right. And Josh, you had done some work. On this feature logging, and you did a mock up and you did some research into, some competitors and then like, I don't know it happened, but I was like, yeah, okay, but what if, what if we did something completely different than, than what you had proposed 

Josh: if we don't do the, like, the boring, like the boring traditional thing 

Kevin: well, no, I didn't boring isn't the word that I would use, but, uh, 

Josh: I thinkit was like, like paper trail. I [00:04:00] think, now that it's, now that you mention it's starting to come back, like we are thinking we should have some kind of logs that we can like correlate to errors and things, but we weren't thinking, 

about the, 

Kevin: right. And I think that was the original idea. Like that was kind of the, we were looking over at that problem. Like, how do we surface logs for our customers? was thinking maybe we can do more with it. And that's that was the impetus. Like what, more can we do with this logging product? and that's, and then it just, I had used Splunk. Had a previous employer and it had some really good experiences with that. I use it for debugging and, there was something about just being able to massage your log events into any shape you want them to be, to figure things out that was really appealing and really came in handy. 

And so I wanted to try and give somebody a tool that lets them massage the data however they want and, extract insights out of the stuff they send us.[00:05:00] 

Josh: Totally. 

Kevin: Yeah, 

Josh: Yeah, I remember, I think we were, 'cause we, yeah, we were talking about logging, but we were also talking about, observability tools and, like open telemetry. the project to like standardize reporting observability data, which is like metrics logs and traces typically,it's been gaining popularity for a while now. 

but we were looking at that,we were thinking I don't know if we can handle adding a full a PM or application performance management, or monitoring tool to Honeybadger. but like, 

how can we get some of the benefits of, you know, being able to extract metrics and even some performance data from. a more advanced logging solution without building the entire thing that is like New Relic or Datadog, or Splunk. which I think everyone, is realizing that not only are they wildly expensive, but they're also complicated tools to use. 

And, we kind of wanted to build like a simple yet powerful [00:06:00] version of that. and hopefully cheaper 

If, if anyone wants to pay us $8 million a year, I'm just gonna throw that out there. Like, you're welcome to come to Honeybadger. or whatever. 

We'll, maybe we'll charge you six 60 million. if you like switch from Datadog. 

Ben: or if you bring your Splunk receipts, we'll give you a guaranteed at least 20 percent discount from what Splunk is charging you. 

Josh: Love it. Yeah. 

Kevin: it's like best buy price matching 

Ben: That's right. 

I think what really sold me when you were proposing this, Kevin was, taking that idea that we had started with, which was now let's just give a display of logs like paper trail so that we can have that alongside. You can have more context around your errors. 

And then, Kevin, you're like,what if we did Splunk instead, basically, like if we took this structured logging approach and you could actually query your logs and do some cool stuff, and I thought that was. Pretty freaking cool. And, being able to get the metrics, like Josh mentioned, like that was just pretty compelling to me, definitely more compelling than just having a tail dash F in a web browser. So one of the things that you did though, starting off, I [00:07:00] think Josh mentioned this earlier was this rabbit hole, rabbit cave of Notion docs. talk a little bit about that. Like, how'd you get from what was in your head to Notion to eventually what you're seeing today? And how does. How does that compare? 

Like, do you feel like, uh, you've been true to your own vision, in the intervening months? I 

Kevin: Yeah, I have and I think I need to say both you and Josh and Honeybadger as a whole You were very Accommodating to new ideas, which I love, right? if I have something, if I have a different way, I want to do something nobody's is necessarily, sometimes we get like into our ideas, but for the most part, like we're free to kind of solve a problem how we want. 

And so this idea that I had was really big and I think we took some risks on working on a big idea like this. but like I can't think of another place I've ever worked where I'd be able to do that. So first off, I want to say thank you and I [00:08:00] appreciate letting me solve this problem in the way that I have. 

but yeah, I, so I'm a big feedback. Person feedback, meaning I don't want to build something until I know what I'm building and I usually will share that idea with people. And so I do that through documentation. And a lot of times it's through drawing. 

Before I did this, I did art and I was going to be an industrial designer. And so drawing is like a really big part of that. And so a lot of those notion docs are full of drawings. I, I, like when I was first working on this, I remember I would, was waking up early and working cause I had young kids. 

And I would spend probably the first two hours from six to eight, just documenting, just thinking about a problem, drawing things, writing out notion docs, trying to, think about edge cases. Think about architecture, drawing boxes, draw a lot of boxes, kind of 

Josh: are good. 

Kevin: it. Yeah. And then usually that's a, was a pretty [00:09:00] good way for Ben, you and I to communicate over an idea, whether, sometimes. 

You didn't like an idea, and so I had to go back and try to like either I didn't make it clear what I was trying to do or say, or maybe it wasn't a good idea, but like, it's a good way for us to interact before I start coding anything, because then things slow down real fast. so yeah, that's a huge part of my process just in general. 

And it usually ends up with, I mean, Roel was talking about how, like he's looked through like four docs. I think it's way too much. It's just like, it being inundated with, with information, when you look through that little, my little play area of Notion docs. 

Ben: I think the fun thing for me about this whole thing is You know, Kevin, you're our first developer hire that we've had full time besides the three co founders. And this is the first major, product really that we've done that didn't come out of the brain of one of the co founders, right? 

It came from your brain, right? And, there were a number of times along the path [00:10:00] where you would come up with something and be like, ah, I don't know. I don't know what I think about this. And so I'd have to go back and think about it a while. And there were times where you convinced me and there was a time or two when I think I convinced you on something that should change, but it was really neat going through that, experience that I think it's the first time we've had that really here. 

Like we had a really good idea, the three of us, when we started this kind of battery, like what the product was should be. and we just kind of built on from there. And this is the first, like. Something really kind of new, I think, that had a lot of like exploratory work and decision time and all that kind of stuff. 

Josh: Yeah, I wanna, when you were talking about, like waking up before the kids and, doing like brainstorming and like planning and things like that totally reminded me of when we were. Building Honeybadger initially, like I would do the same thing when I was, excited about working on this new thing that we were doing. 

like that was what we did. at least Ben and I know we were like early, Ben's al always been an early, an early riser, but I kind of like bounced between routines. Um, but when I'm like really excited about an idea and I just need the time to focus on [00:11:00] it, I, that's like a great way to do it and that's what I did. 

When, back when we were, also like juggling consulting and, and building this new thing. but yeah. that's really interesting what you just said, Ben, about, this is like the first, like internal product almost that we've built that 

That came from someone else. And that's, that's a really exciting milestone. I gotta say. this is, this has been really cool. 

Ben: I think, 

uh, one of the, the reasons we could move forward on this now is really comes down to using Clickhouse. And, uh, Kevin, I think you were like the first one to really say, Hey, we got to do this. And I think you were saying that, probably a year or two before we even started on an insight. so tell me about your love affair with Clickhouse. 

how did you stumble into that? why'd you fall in love with it? 

Kevin: I think like maybe. Maybe a year before that, I had done a proof of concepts, just looking at how we could, because the problem that I wanted to solve, and the problem that we've tried to solve with Elasticsearch is how do we accept any shape of [00:12:00] data, store it, and allow it to be queried in a somewhat efficient way. And we did that with Elasticsearch through. Kind of a hack of, you know, the whole array of objects thing, which we can talk about, but I really wanted to try and find a different way to accept any shape, any size of data store it and let our customers query it without exploding a database 

And so I was thinking Clickhouse could be useful for that. And so I did a proof of concepts, like I said, three years ago, and it did what I wanted. And then there was an article that came out about how, Uber used Clickhouse to store log data. And it had the technique that we. Ultimately went with, and that was the thing that pushed me over the edge as thinking this could be a viable database to build. at that point, I think it was less about logs and more about how do we accept error data and store it and let [00:13:00] people search it. 

But then it just became, well, if we're going to do that, let's let them send anything and they can use these same tools to look through. So ClickHouse. I like about ClickHouse is that it's, I like the fundamentals of the way it works. Like it's a columnar datastore. If you separate your data into columns, And you're very particular about how you want to look those things up. 

You can read a lot less data than you would if you put it in Postgres or some other data stores. And so as long as you can take your data and shape it the way that Clickhouse wants it, and you can structure your queries the way Clickhouse would like to see them, you can look over gigabytes of data relatively quickly. 

And so taking that, you know, Clickhouse, and then also can we accept. Any shape of data and give people a reasonable performance looking over that. It just all sort of [00:14:00] came and fit together in the end. 

Ben: Yeah, one of the things that I find fascinating about ClickHouse being an analytics database rather than a transactional database is that you really don't want to be doing updates or deletes, right? It's not, it's not, it's bread and butter, and with the login kind of data that we manage, that's fine. 

we don't care. We don't do updates and deletes of our data. We just store a heck of a lot of it, and it fits really well into that analytics paradigm that ClickHouse was really built for. And I love how, you know, we have a love at Honeybadger for data stores. Like we just can't get enough of them. 

You know, we've got, we've got Prosegres, which is our main hotness, we also love DynamoDB. And of course we use Elasticsearch. We have, we've even played with Cassandra in the past. so it just continues our grand tradition of trying a new data store every year or two. 

Josh: This is like the list of databases that you've swapped out when I was on vacation. I think we've mentioned that in past episodes, but that's the running joke at Honeybadgers. Whenever I go on vacation, Ben replaces a data store with something better. 

and it's just done. And I come back and I'm just happy. I did think it's interesting,from a [00:15:00] business, Standpoint, the, the trends like of technology, like a new thing comes out and it enables this new use case that is much easier than it was before And, it changes a lot of things for the industry. 

so I, I feel like click House might be one of those types of things where like, I don't know, like I'm not as close to it as you and Kevin, but from my perspective, I started hearing about it. and then like we started realizing we could build this thing on it, in a way that we it would've been harder, I think, more difficult to build this with the existing solutions. 

but then there's, there's been, startups popping up everywhere now. and maybe we're biased towards this because we're doing this, but it seems like a lot of, people are leveraging this new technology, to build, similar analytics type tools. 

Um, and, and be able to do it cheaper than, some of the larger players. 

Ben: Yeah. There are a lot of, probably because I watched this base too closely, but like you said, yeah. It seems like there's another one coming out every week. They, give you Clickhouse and slap a query box on top of it and call it a day. 

Josh: Yeah, it's [00:16:00] almost like LLMs or, like people building startups on open ai. it's not quite that prolific, but, it's easy to just throw something on it and package it into a SaaS or whatever. 

Ben: yeah, one of those, things, talking about Clickhouse and querying and stuff, and a lot. a lot of the approaches have been just exposed click outs because it has a SQL syntax, but Kevin, you decided early on that we should not use that approach and that we should go with the query language. 

And I pushed back against that idea for a long, long time and you finally brought me around. so talk about like, why did we have to have a new query language for this product? 

Josh: This is a great segue too, because like, how are we not doing what I just said? Like how are we like, using the technology and making it better, making it like more, accessible to the user and, what can we do that Just, having your own Click house database doesn't give you. 

Kevin: There's a lot of things I think that come with it, both positive and, negatives. One of the, of the big positives for me is just control. We have control over the stuff we send to [00:17:00] ClickHouse. Uh,we don't have to worry about security, but like we have. 

Many more filters to ensure that we're not bleeding data from other customers. so from that perspective, having control is really nice, but also we can understand the intent a little bit more. since we're parsing the queries outum, we know every field you're looking up and we can do analysis on that and we can then. 

Based on that analysis, then write a, maybe a ClickHouse SQL query that's more optimized than another one. We can move things around. we can utilize ClickHouse as best we can.so what Insights does is you write this query, BadgerQL is what we call the language, Badger query language, and it translates that query to a single ClickHouse. 

SQL query. And so we go through a bunch of different, ways to transform the data and make sure that you're looking at fields that are available and all these different sort of things that we go through and really [00:18:00] without,writing the language ourself, it would be challenging I think what I'm excited about in terms of insights. As a product is, there's that base layer. Like now we have this query language that is like a DSL into your data, but now we can put the fun stuff on top of it now that it works. And so one of the, one of the things we have this ability to capture columns. 

And whereas, most databases have indexes, ClickHouse doesn't necessarily work like that. if you want to get at your data faster, you want to have it in its own column. And so we allow you at real time to specify a field that's in your data that you want to capture. 

And we put it in a column. And so when you query for it, it's much quicker. That would be. Pretty painful to set up and write in with just raw SQL, you could do it, but like I look at the SQL that gets translated from this tool after we go through and do all the,[00:19:00] the rewriting that we do, and it's usually 40, 50 lines long. 

At least for a three line badger QL query. there's a lot that happens in the background to pull out, to provide some of these features that they get writing badger QL. in the end, I think control is the biggest thing to be able to provide nice features that don't require needing to write raw SQL. And then I think another big part of it is. Being able to service errors earlier in a way that is friendly to the user. So ClickHouse is a typed language, therefore BadgerQL is a typed language. And so we do type checks before we even send a query out to ClickHouse. And so if you are trying to provide the wrong type to a function or, you're looking at, a field that just doesn't make sense in terms of whether it fits a signature for something, then we error early and we show that even before we send it out to Clickhouse. 

Yeah, there's lots of stuff I could talk for ever about I think it's, it's great to, have [00:20:00] a query language, but also on the, I got to talk about the negatives. 

It's also complex. I was just walking. So Roel, who's another team member of ours, we were walking through the code that builds out the query thing. And he, it was, it's complicated to say the least, there's a lot that goes into it. like, it's isolated to a part that is pretty volatile and changes all the time and breaks all the time. 

But, that's just the nature of taking something complex and untangling it and making it simple for the user. 

Josh: Yeah. what about the, the learning curve? Because,this is a brand new query language, 

what are we doing to, to help people clear that hurdle? 

Kevin: Well, uh, docs are important. So one thing we're doing with insights is we're inlining our docs in the app. So you can look to the docs with the app right next to you. we don't make you go out to an external doc site, which I think will helpwhile you're in the middle of trying to figure something out, it also lets us do cool stuff [00:21:00] like. 

When we return an error, there's a link to the, a doc that will open up inline. So you can click on the error and it almost like in an IDE, but you're in Honeybadger. 

Josh: Yeah. 

Kevin: So that is really helpful. there's also just going to be a learning curve for this type of thing. There, I remember at the company I used to work at, Splunk was a thing that they wanted everyone to use. 

And a lot of people just didn't want to, because they just didn't want to learn another thing. Which I get, and I know I'm trying, we're trying to make this,make this seamless for people because I think, yeah, you could just say, why don't we just give them SQL? Cause everyone knows SQL, but you're not going to get analysts, people learning SQL to write queries for some of your data. 

So I think that the same argument would go for whether, you expose something directly or you write something that's made for whatever space, that sort of data space, I would say for querying. And then the thing I'm working on now is like IntelliSense, 

Josh: I 

was gonna say 

Kevin: calling [00:22:00] Badger. So we just have to put Badger in 

front of everything. 

Josh: Yeah. Badger sense. 

Kevin: Yeah. Autocomplete. but I also there's autocomplete, but then have it sort of walk you through while you're typing, like. If I'm, in a certain function, like I can alias it. So it's, it provides that documentation as you type kind of thing. That's like the experience that I'm trying to go for. 

So one thing when I was building insights was I didn't necessarily like, I wanted to focus on the query, which I've talked about, and then have that be kind of the driver of the things if we can, and the reason being, I think. This syntax is, if you're used to Splunk or CloudWatch Insights, it's like functions and then pipes and functions. 

And it reminds me a little bit of like Unix pipelining, like it's that kind of thing where you flow through a process 

Josh: I love the 

Kevin: a really powerful way. Yeah, it's you're you can do whatever you want, for the most part. And what's nice about it is,it's not a WYSIWYG, [00:23:00] drag a thing and set it, like, it's text. 

And it's a lot easier to add features and play around with things when you don't need that interface part to figure out. And so I think that autocomplete, like the IntelliSense thing will be big because I think we'll get the flexibility of a query language, but yet the good parts of WYSIWYG at the same time, 

If it really can anticipate what you're wanting to write or give you suggestions as you're writing it, or even stuff like, as you, like, we have a syntax for, curly braces, which means you want to input a date. And then as you do that, the date picker pops up while you're typing, like things like that, where you get the, the native feel of it, but yet you still get to manipulate the text and be free to build out however you want to build a query out, 

Josh: Yeah, that's super cool. And also I think, it, it's also integrated with the inline docs as well, like for functions and stuff. As you're, can you like jump from the, the hints to the docs [00:24:00] basically? 

Kevin: Yeah. You can click on a link and it'll open up the doc to whatever function you're currently writing. Yeah. 

Ben: Another cool thing that we're doing is, with the dashboard charts, right? Every chart is backed by a query, right? So you can look at that chart and Oh, how does that you click the edit this query and all of a sudden you see the syntax that was used to drive that chart, right? 

oh, I can modify this and I can tweak it this way and now I can save that and get a new chart, right? And so I think that also be helpful and people getting up to speed because we'll provide some default dashboards with some charts in there That do some basic kind of analysis you'd be interested in and so you can see oh This is how the language is used in a real example 

Josh: Yeah, so if we detect if you have a Rails app and you're like reporting Rails logs or something, then we can just give you a. Just a typical Rails, a PM style dashboard. based on the structure that we already know exists in those logs, which is, it's pretty cool. 

yeah. I love how the really, the query is the underlying thing for that powers everything in this new feature, [00:25:00] um, include from dashboards to, uh, in the future. we are, we're planning to add, I think what we're calling observers, but basically alerting on different queries. so the query can power? 

Yeah, like just, you know, it's, it's underlying your charts, but it's also underlying your alerts and things like events that you might need to monitor. say you have a, a, uh. A sidekick or a rescue queue that you need to make sure doesn't go over a certain,depth for your backlog. 

you'll be able to send an alert to PagerDuty that will wake you up in the middle of the night. hopefully, we can help you fix that and we won't be a bugging you too much. but it's gonna, like with our existing integrations and everything, like it really, I think it has a lot of, things it can do. 

Kevin: Have we talked about how we're using it not just for logs, right? And we started talking about logs, but then we sort of expanded and now HoneyBudger data is going into it. have you mentioned 

that in 

Josh: I did, we. 

Ben: Briefly, we talked about how we can pull out the, you know, the structured information like from the errors that we're using Honeybadger and also [00:26:00] the metrics, like you were talking about the sidekick or the rescue backlog depth. So we talked a little bit about that, but yeah, not just, I think, trying to help developers understand, it's not just about strings in a log file, right? 

It's about the data enriching that, those logs with some good structured data so that you can then do some useful queries on that and do some analytics. 

Josh: Yeah, that's, I think that's a pretty interesting, thing we're doing, that I haven't seen elsewhere like that. We're like feeding our internal data from other features of the product into this thing. And it is the analysis engine, that even provides like. 

Features that we have struggled to provide in the past. people have always wanted error rates based on, requests. And because we didn't have a PM, we weren't like logging, every request, we didn't, it was harder to calculate that. But this basically like, we're sending data in,we'll have all that data together in one place, whether you're sending in your own logs, and then we can correlate that with the internal data that's coming from, errors that you're reporting. 

and, uptime events and things like that. Outages. so there's like basically like an [00:27:00] internal stream of events that we're providing you for free, basically. And then you can have your own stream of events that you're, can be whatever you want that you're sending in. and those two things can like, work together in interesting ways. 

Kevin: Like I think about how people have wanted to know what,what browsers were affected by an error, right. And at this point, like we would write some, we have some things that we would write that people could see what, we would aggregate some data for them, but we can't anticipate. Everything that anyone may want to know because we let you put your own contextual data and all your errors. And so you may have some data point in there that matters to you and you want to know for all these errors, what was that set? And so we didn't have a great way to expose that. 

And now. You just go to insights and you write a query that says, filter by this error and count how many times we saw these values and it'll give you a table that shows you what, what those values are and you can chart them. And so like it really opens up.[00:28:00] what people can do, not just with long data, but with the error data that we're capturing for them. 

Ben: Yeah, I think one of the examples that comes to the top of my mind is we have some customers have their app deployed across multiple subdomains, like for a multi tenant kind of situation where each customer has their own subdomain, and they want to see, which subdomain is Causing all these errors, right? 

Instead of going through each error, like they have to do today, they can click on maybe someday they can have a UI button that says, oh, the host name, and they can click on that and that drops them into the insights query UI and with the host name as one of the filters, and they can see a chart, boom, right there, aggregated across all that host name data, right? 

So I'm pretty excited about being able to do cool stuff like that, that we just haven't been able to do before. 

Josh: Yeah, or even haven't, have not have decided not to do because it would complicate the, the simple, product experience that we want to give people. by default, especially like our thing is we want this to be like a, less than five minute setup and and then you have basically [00:29:00] everything done for you. 

for the most part, like when you set up air tracking or something. there's a lot of things like, we don't wanna overwhelm the ui, but this kind of gives us the ability to like, provide that more advanced functionality in a, in, basically in that simple way, through this tool that honestly, I think it'll become, like the hub of Honeybadger, that a lot of the other things can revolve around. 

I kind of think of it a little bit like expert mode, like you, we still have everything that. Like the way that Honeybadger works that people love. But then we also have this place they can jump into if they have this problem that they really need to dig into. 

Kevin: So it doesn't, like you said, it doesn't sacrifice the way that, it doesn't change the way Honeybadger works necessarily. It just adds another mode. Helpful 

Josh: Yeah. 

Kevin: for people that have these issues they really need to dig into. 

Josh: Yep. It's like we've talked about like the, it's like enabling x-ray vision or something. we talked about having the Honeybadger with the,the goggles or something but yeah, the [00:30:00] expert mode. I like that. 

Ben: Totally. Well, Kevin, to wrap it up, maybe, one last question about insights, what has been like the most challenging bit or the most fun bit, or maybe the most surprising thing you encountered? take your pick. Just something novel that's come up as you've been building this out. 

Kevin: The beginning is always the most fun part. When you're, when you're, like those mornings that I talked about where I'd wake up and write. I feeluh, very inspired during those times. Like it just, cause it's a hard problem. And I like hard problems, like just trying to think through all the things. 

It's like my favorite part. Actually making it is okay. it's a lot of work and I love, I like solving the problem, but it's also tiring at the same time.I'm working on it for about a year and I wouldn't, I would lie if I said I didn't get burnout a few times while working on it. So I think the challenging [00:31:00] part for me is to be able to stick with something and. 

And not get, just get over, I don't know how to say it. I think burnout is really the one word I can think of. 

Josh: What, what, Got you through those periods. because I've been there too, 

like how do you how do you deal with the burnout and um, be able to move forward? 

Kevin: Yeah. So the burnout is also not a reflection of Honeybadger at all. Like I burn myself out on personal projects too. Like it's just sort of a thing that I, like, 

I'm very intense. And then I need, I need to, walk away. And so I think when I walk away It really helps, but I also have a hard time walking away. 

I have a hard time not just being like, I'm going to keep working on this. I don't care if I don't feel like working on it, I'm going to keep doing it. And that usually makes things worse. And so in those times, really, I just have to give [00:32:00] myself some space and that's the best. I think that's really the only thing that helps me, but yeah, it's hard to recognize it. 

It's hard to recognize. I just, I think I just, at times I just feel like. I'm not doing well, essentially, but really it's I just have been banging my head against this problem for a little too long and need to step away for a bit. 

Josh: Yeah, that's very relatable. I almost feel like we need a Honeybadger for burnout where we can get alerted to this. This problem sooner so we can like, address it and we just have, send ourselves on vacation or something. 'cause I do the same thing, I, hang on,I just I'm just like, I can push through this. 

I'll just hang on. And it's just like you, you get worn down more and more. until you need to take that time. and it, yeah, it would just make it easier if you could like just address it earlier, but also, maybe that's not possible too. it's hard to control,where this pops up and if it's actually going to be an issue or if it's just a, transient type thing. 

Kevin: And I also think the beginnings of insights were hard to, segment [00:33:00] like it, right now I think it's much easier for me to break pieces apart and just work on them. In smaller bits, but in the beginning, it was just such a ball of mud, it was really hard for me to say, I'm going to spend a week on this, and then two weeks on this, because I couldn't, I didn't even know what the things were yet. 

And I think that was, in those moments where I'm trying to work through something that's, I don't even know what it looks like yet. It's hard to then say, this is going to take me a couple of weeks. So I know how to break it apart and sequence it. So, like I said, that's easier now, but in the middle of it, it was not, it was, that was challenging. 

Josh: No, totally. I was gonna say like, um, you know, we've been kind of trying to follow loosely the shape up process, for things at Honeybadger. And I think like this type of project is the, I mean, I know they have a, they have an approach to dealing with like new big efforts inside of the company. 

That kind of require more of a, like less defined approach. but I know this has been difficult for us, to follow that process. And I'm [00:34:00] really excited, like, I think we're at the point where we can start like really getting into an iterating, like an iterative, routine again of, for this as well. 

we're at the point where we're, it's getting, we're releasing it to more and more people and,I see us starting to settle into, to more of a, product feedback loop type cycle, and I'm really excited to, to, Get into that groove. 

Kevin: Right. Me too. I 

Ben: Yeah. Always learning something at Honeybadger. This week we're learning how to do project management. 

Josh: Yeah. Next week we'll have to get Kevin back to talk about, uh, Photoshop Tennis in the late nineties. 

Ben: Well, thanks, Kevin, for joining us. Appreciate you taking some time to chat about insights. We promise that we will not make this an insights only podcast. We will talk about something non insights next time. Maybe we'll talk about bunnies and more Monty Python. I don't know. 

Josh: Nice. 

Kevin: me. 

Josh: Yeah. Thank you. 

Ben: Any last words, Josh? 

Josh: my last words are This Has Been Found Quest and, you can find us online@foundquestpodcast.com. you can find all our socials there. you should go to, apple Podcast or Spotify or wherever you listen to your podcast and rate us highly. give us a review if you don't mind. it will help us out and, we'll see you next week.