Screaming in the Cloud - The DuckTale of DuckTools with Kevin Kuchta

Episode Date: March 2, 2021

About KevinKevin's the Lead Product Owner and Engineer on Ducktools, a recently-released set of AWS Cost Management power tools.Links:Stop Lying Cloud: https://stop.lying.cloud/TabDB.io: https://tabdb.io/Personal website: https://kevinkuchta.com/

Hello, and welcome to Screaming in the Cloud with your host, cloud economist Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud. This episode is sponsored in the Cloud. to do a full-on code and possibly infrastructure deploy? What if you could test on a small subset of users and then roll it back immediately if results aren't what you expect? LaunchDarkly does exactly this. To learn more, visit launchdarkly.com and tell them Corey sent you, and watch for the wince. If your mean time to WTF for a security alert is more than a minute,

it's time to look at Lacework. Lacework will help you get your security act together for everything from compliance service configurations to container app relationships, all without the need for PhDs in AWS to write the rules. If you're building a secure business on AWS with compliance requirements, you don't really have time to choose between antivirus or firewall companies to help you secure your stack. That's why Lacework is built from the ground up for the cloud. Low effort, high visibility, and detection. To learn more, visit lacework.com. Ever notice how security tends to be one of those things that isn't particularly welcoming to folks

who don't already have the word security somewhere in their job title? Introducing our fix to that, Meanwhile Insecurity. To sign up for the newsletter or to find the podcast, visit meanwhileinsecurity.com. Coming soon from the Duckbill Group. Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by my colleague, Kevin Kukta. Kevin, welcome to the show. Hey, Corey. Great to be here. So you were the lead product owner and only engineer on our internal DuckTools suite of projects, which we have recently announced that we are going to be sunsetting. So let's start at the beginning. What's the deal with that? Yeah, that was a fun ride. Duck Tools was a suite of tools that we were trying to build around AWS cost management. The plan was to sort of have them as tools that would focus very specifically on individual problems people

might have in the cloud. So you need to figure out what your AWS savings plan commit level should be. We have a really cool tool that tells you exactly what you want to do for that. We tried to make this set of tools work, and we built some really cool stuff, but also we didn't find product market fit. And so now we are sunsetting them. That's the sort of super high level view of that. Oh, yeah. In many respects, I basically take ownership of that because this whole suite of tools idea started years ago when it was just me. And tools is kind of a lofty term, as you can well attest. It was a bunch of crappy shell scripts that I tied together that took every good programming practice and tossed it out and then took what was left and made a muddling mess of it. But on a good day, I could run these things on an account

and get some semblance of an answer, which at least gave you a direction to go in. It was an initial, oh, cool. So what is this thing supposed to be doing? Great, okay, I can build that thing, but I'm starting from scratch and let us never speak of this again. That's the direct version of our conversations.

Because again, I'm not good at computering things. Yeah, and remember you reaching out to me, you know, much earlier in 2020, just sort of a Slack message in some joint Slack we were in saying, hey, we've got these internal tools. You're looking for work. Want to come work for Duckbill? And that was a lot of fun. That's how it all started. In fact, we first met 10 years ago now when we worked together at the same startup. And we've kept in touch ever since. And you've always been top of my list for engineers to work with, just because on the one hand, you've got the technical chops. That is undeniable for anyone who has even seen some of your ridiculous projects, which we'll get into in a little bit.

But you also, in a relatively uncommon way, are able to grasp business nuance, understand the context behind the larger picture of why something is being done in a way that very often engineers like to frankly ignore. And finding both of those skill sets that are incredibly valuable in the same person is one of those, let's grab onto that whenever we can find it and hold on with two hands in a death grip. Well, thank you. I've been equally looking forward to working with you and Mike again at some point for as long as I've known you. Mike's brought me on for a few random

contracting gigs over the years. And of course, I've worked with you both on some silly side projects and Expensify way back in the day. Oh, yeah. One of my favorite side projects of yours still remains the Lambda URL shortener that you built, which, okay, fine, doesn't sound super

interesting until you realize that there is no data store. It is just Lambda, and it works, and it's a monstrosity. You know, actually, you can take some partial credit for inspiring that. I was reading your newsletter, and I saw an article on, you know, creating a URL shortener with Lambda, and I thought, oh, wait, how'd you do that? That sounds amazing. Then I looked into the article that you'd linked and it turned out they were using Lambda and DynamoDB. In the instant between seeing the link and clicking on it, I had some ideas as to how it could be done with self-modifying Lambda functions.

And that inspired that whole mess. And it's one of my more popular projects. It's horrible you should never do it in real life. Oh yeah, the outreach from the Lambda team was great. First, they're like, we want to talk to the person that did this, and followed me by, we never want to see that person again, and we'd like to salt the earth now that we've seen the code. I'm exaggerating only slightly,

but it was definitely a stop-and-take-stock moment of how to approach those things. And you've done a bunch of other stuff too. You were instrumental in the first version of implementing the stop.lying.cloud status page cleanup project. You took a Chrome extension and then wound up porting that into Lambda at Edge. And it wound up working dynamically on the fly. Somewhat recently, I wound up modifying that to be much more of a blunt instrument approach. There was some significant latency in it, gathering the original seven and a half megabytes of HTML that is the AWS status page,

and then dissecting the whole thing and making the modifications I wanted to make and then returning it. And the blunt instrument approach was, this is a status page. If we just update it once a minute and render that HTML to a static site, we don't even need to use Lambda at Edge. And the best feature of Lambda at Edge is you are not required to use it. And then it became something. We could just hurl up,

and it was a very simple, serve this static website, disable all caching on it, and it's good. Nice. Yeah, it was fun. But back to the whole DuckTools part of the story. The thing that I find so interesting is that I still maintain that there is a use case

for every tool that you've built and every tool that we were planning on building. The problem that you alluded to, and I want to dive into more, is that when we talked to a bunch of customers and prospective customers, the things that they wanted were not the things that we were building. And I'm never a big fan of having to educate your market and then trying to sell them something. Yeah, I think that's exactly right. It was an interesting experience because I'd never done serious customer research interviews before, like I was doing here. As the product owner, I was on calls, dozens of calls with people who might potentially want to

buy DuckTools and just sort of probing everything I can think of to hear about the problems that they have, the challenges they've got. And I ended up putting together this big doc a few weeks before we shut down. And it was just a list of here's all the problems people have. And none of them quite lined up with the things we were trying to build. And all of them were problems that, yeah, we could solve them if we were willing to hire two to five engineers and spend four to six years working on it. And we just decided that it wasn't really a good fit for our business. I think we were joking internally that a lot of people, what they really wanted was cloudability or cloud health or cloud forecast, but cheaper. Right. The entire problem of we're going to pay a percentage of our bill,

it doesn't work in some respects, because it means that companies grow out of being able to justify the tool that you're providing them. And any other approach that we've looked into is sort of a mess, too, because you're leaving an awful lot of money on the table if you just charge fixed fee per customer. And again, we're not VC-backed, so that's okay for us. We don't have to capture all of the value, but we do want to wind up charging reasonably for this.

Yeah, finding the right price point was definitely tricky. We talked to people who would say that, oh yeah, 50 bucks a month is about the right price point for an incredibly valuable tool that solves all my problems. We talked to other people who would say, yeah, this tool is going to save me, you know, tens of thousands of dollars per month. I'm happy to pay, you know, a couple thousand a month for it.

Well, some of the stuff we've built too is, what does this do? Well, it looks at all your DynamoDB tables, looks at the historical usage over a configurable period of time, and it spits out whether they're currently on a on-demand basis or provision capacity basis, and is there an optimization to be made for toggling some of those in some cases with certain constraints built in and certain guidance that is assumed or can be configured. And the typical answer when I describe that sort of tool to someone who's in this space or more commonly not in this space is, well, that doesn't sound hard. I can build a script to do that over the weekend. And there are a bunch of tools that do similar things on GitHub, and they're all limited and don't do it correctly on a wide variety of different bases here.

It's nuanced and challenging. What we fundamentally wound up building internally is a set of power tools for folks who are steeped in this space to use to become more effective at analyzing what's going on in an AWS bill. And that is a difficult thing to wind up selling. I would refer to it internally from time to time as Photoshop for the AWS bill. I mean, sure, anyone can buy Photoshop. Me, for example. And does that mean that I can build professional-looking graphics? No. It means I can make graphics that looks like I used a tool a professional might have used had I had the good sense to pay them. I'm not an artist, and no tool is going to change that. And that was part of the problem that I saw running into as well. Yeah, that's definitely true. And our original vision for this product

was to be Photoshop for professionals trying to solve these problems. Whereas a lot of competing cloud tools that charge an arm and a leg, they instead try to sell you a painting. They try to say, we will solve your cloud cost problems. You don't have to have in-depth knowledge of this sort of stuff. And I think we were trying to differentiate ourselves from those products by saying, no, no, we're going to offer you a scalpel. We're going to offer you a really sharp tool that would do exactly what you want. And unfortunately, the people who want really sharp tools are also the people who think that they can solve these problems with a shell script that they wrote last weekend or with a free GitHub product. And so selling to those people was kind of tricky.

And traditional SaaS models of subscriptions and whatnot are also challenging in this space. For example, one of the tools that we built, and you built, and is working. It analyzes which reserved instances a customer has that are expiring, and then calculates out what the savings plan commitment should be so you don't have to wind up waiting for a week of on-demand

so that AWS's native analyzer can look at it and finally make a recommendation that may or may not fit. Instead, it winds up letting you figure this out in advance so there isn't a gap where you're paying through the nose. And that's great. It's helpful. But it's generally used only when there's a batch of reserved instances expiring. In some companies, that happens once a year. People are going to need that tool once. They're not going to need it on an ongoing, sustained basis. Yeah, we had that problem with both of the tools that we put out for our beta. The tool that you just described for migrating reserved instances and savings plans and our tool for just picking savings plans commit levels. People would say, oh, that product looks

great. Can I use it for a month to pick a savings plan commit level, then not worry about it again for three years because we just bought a three-year savings plan. Right. The savings plan calculator is something that we've been using for a long time because there's nothing out there that does this. If you ask the AWS system, what savings plan commit should I buy? It's going to come back with a recommendation that is, okay, it's directionally correct. But here's the thing that I think they lost sight of. For large accounts, that's going to come back and say, all right, for the best savings, go ahead and click here and commit to spending $24 million. And then, I'm not kidding, there's an add to cart button.

No one on this planet is going to say, okay, click the button and hit buy without first asking a few other questions. Namely, they all boiled onto scenario modeling. Well, this past month has been weird because we're, I don't know, it was the holiday season and now we're dropping back to baseline load. Everyone's favorite lie they tell each other. So then it was, okay, what if we go back three months and look at that timeframe? Great. Oh, okay. That's a much lower number. Cool. What if we only bought half of that? How much would we save? And the answer is, of course, some money. How much money? And the answer of, I don't know, doesn't work when you're asking someone to spend

eight figures, as it turns out. So there's a lot of nuance and scenario modeling and helping to justify the recommendation because no one wants to be left holding the bag on that kind of mistake. Yeah, exactly. I think you described the use case perfectly. We had one internal customer we were trying it out with and their spend was incredibly seasonal. By seasonal, I mean daily. Their spend would increase about 8x during peak hours during the day versus its lowest hours in the night. And so they were looking at their spend on our savings plan calculator, and they said, well, you know, we want to take these big peaks every day, and we're going to put that all into spot instances. And so they wanted to be able to figure out, okay, what's our savings plan if we only look at the baseline below these peaks?

Of course, Amazon's built-in tools will not tell you anything about that. And our savings plan calculator was really great for that. I still believe that there's a pretty good value that this tool provides, if only we could have found a way to attach it to a useful business or a viable business. Right. And the challenge, too, is the person who really cares about getting that number dialed in specifically is very often not the people that we're speaking to in most other contexts. It's very often someone in FP&A, financial planning and analysis. It's someone who's being told to model additional scenarios that their business just wants to make sure they check off the list. And that's all fine.

There's a need for that. And it's great, but it doesn't lend itself to the audience that we're talking to. And further, these things also don't really lend themselves to our current sales model of having one of our account folks reach out and talk to people as they move through the process. It turns out you can't have a high-touch enterprise-style sales conversation when you're trying to sell something that is a reasonably affordable SaaS. Yep, and that was actually sort of a misstep I made early on when I was trying to sell DuckTools. And when I first joined, I sort of assumed, well, we have this great sales team. We'll just have them sell DuckTools along with consulting engagements.

And as it turned out, that didn't work for the reasons you described. And it took me, I don't know, maybe three months to realize that. And at that point, we sort of switched our model. We decided I'll be doing the sales directly. I'll start talking with customers more directly. And that sort of got us on this whole trip to realize some of the flaws of their business plan. Because until that point, I hadn't been talking with our customers nearly enough. That's a piece of advice that every product

development book will tell you. Talk to customers more. And I wish I had taken that advice a little earlier. This is one of the weird things about starting a business that I've learned the fun way is you hear all the tropes and all the advice that people give and you think, ah, I'm not going to make that mistake. There's a reason everyone winds up making that mistake. It's like that old joke you see going around of a comment of, below this line is madness. No one understands it. But you're going to tilt at it anyway. When you're done, please increment the next line so that it remains accurate. And the next line is some high number next to hours of people's lives wasted on this. It's the same model where everyone is going to make the same type of mistake sooner or

later. And sometimes the only way you learn is by the hard-won experience of getting it really wrong. Yep. In this case, I think that the best case scenario, if I talked to customers sooner than I did, talk to them more and sooner, the best thing that would have happened was we realized that this product isn't viable a little bit earlier. I don't think we could have turned the product around or just suddenly figured out that, oh, yes, here's this one strategy that will make DuckTools perfect. So at worst, we lost six months of time. It's a bummer, but I certainly learned a lot doing it.

We learned an awful lot. There are things that we'll carry with us, absolutely, as far as just some of the IP we generated along the way. But there's also the experience we get that will inform future product decisions as we look at various aspects of it. This is a constant struggle on some level here, where people come up to us and ask us to do all kinds of things. And if you're in a mindset of trying to say yes to everyone, you'll wind up going in circles. Can you expand to doing Azure instead mindset of trying to say yes to everyone, you'll wind up going in circles. Can you expand to doing Azure instead? You want to say yes to that, but we're not really equipped for it. Hey, how about you go ahead and do an implementation project for us? Just it'll be quick while we have the time and you've got the expertise. Down that path lies ridiculous problems.

And it's difficult to say no to that, especially if you're in the early stages where you want to say yes to every customer, because there's a mindset you have to grow out of that every lead might possibly be your last one ever. And it takes a certain level of repetition, at least for me, to get past that. Yeah, that's definitely true. One of the other factors for why we decided to shut down DuckTools was that it was sort of a bit of a distraction in that DuckBill has three distinct business lines. It's got the consulting, it's got the media arm, and it has the SaaS tool that we're building. And trying to build three different lines of business

at the same time is, it reduces our limited pool of focus, especially for the CEO, Mike, who has to deal with all of these things at once. And so, yeah, when you say yes to everything in an enterprise business, you end up scatterbrained, jumping at a whole bunch of different opportunities to the detriment of any individual one.

And so I think by shutting down DuckTools, we're going to be able to focus a lot more on the media wing and the consulting wing. This episode is sponsored by ExtraHop. ExtraHop provides threat detection and response for the enterprise, not the starship. On-prem security doesn't translate well to cloud or multi-cloud environments, and that's not even counting IoT. ExtraHop automatically discovers everything inside the perimeter, including your cloud workloads and IoT devices,

detects these threats up to 35% faster and helps you act immediately. Ask for a free trial of detection and response for AWS today at extrahop.com slash trial. Yeah, the ability to turn things off was sort of the driving issue in some respects, because as my business partner Mike and I continued to look at the business and reason about it for the last six months or so, it seemed more and more that we were really running three very different businesses instead of running only two very different businesses. It seemed like it was very much the, here are three things, good, fast, cheap, pick two, and you can never have all three. It felt that way with our lines of business. We can come up with a bunch of things that benefit two areas, but not the third.

So it was always a bit of an exercise in frustration, given how we reason about our own business. And not having to account for a SaaS product as a part of all of this does free us up somewhat significantly. It also means that I can be much more intentional with how I wind up directing the famed Duckbill Group's SPITE budget. True that. I remember specifically, not that long ago, we were looking to hire a marketing director or something along those lines. And I was talking with Mike and he would say, yeah, we can find someone who's good at selling SaaS products and someone who's good at selling consulting engagements. We can't find someone who's also good at those two things and being able to sell sponsorships for the media wing. Finding

someone who can do all three of those things very well at a high level is basically trying to find a unicorn. But finding two, maybe we could do that. Oh, absolutely. And remember, I started off doing all these things myself. And that doesn't mean that I'm this magical, incredible unicorn myself. It means that I am passively mediocre at a bunch of different things. And it does lead to the humbling experience where every single person that I hire is, by definition, better at the thing that I'm hiring them to do than I am. You know, I once spoke to a CEO a couple of startups ago when I was working at him. He said that the key jobs of being a CEO or any founder is constantly firing yourself. Because, yeah, you end up doing a little bit of everything and you fire yourself from a lot of interesting jobs over time. It's made hiring a fascinating challenge.

I mean, when it comes to hiring our cloud economists, yeah, I absolutely know what profile I'm looking for. I absolutely know what skills they can learn versus which they need to come in with. And I'm very competent at sussing those things out in an interview, but I have no clue how to hire someone who's a marketer, for example, and same story with hiring a salesperson and a common trap that people fall into when they're in this position that I'm thrilled to pass on. Please don't make this mistake yourselves, is you just wind up trying to wing it. And as a result, you invariably wind up hiring the person that sounds the most confident. And that is a dangerous thing. My way out of that trap is for those roles I don't understand super well, is finding a high

level person in that space whom I can trust and then paying them as a consultant to help me find the right people. I think that's exactly the right approach to take. A couple startups ago that I was working at a company, and that's pretty much the approach they took. I joined as the fourth employee. And so we spent a lot of time hiring our first sales hire, our first marketing hire. That guy was the second engineer. So at the time, they were also hiring their first engineers. And that was the approach they took. They had hired these outside advisors, ideally people in their network, or just people who are very well positioned to try to come in and interview people and help make that decision for them.

For that matter, I've always thought that if I ever found myself in the position of hiring a first ops person, you and or some of the other duckbills will be the first time I listed people to call to help me interview people. Oh, yeah. On one hand, I probably should have had a specific, focused senior developer come in and have them interview you to suss out your technical

skill sets. Now, there are a few problems with this. One, you would be the person I would reach out to to fill that role, so kind of a problem. Two, we've been working together on an offer a decade now. I'm not going to suddenly magically figure out in a half-hour interview that you've been faking it an offer a decade now. I'm not going to suddenly magically figure out in a half hour interview that you've been faking it all along

and don't actually know how to code. That is ridiculous. And thirdly, this role was so weird and strange and required a combination of things that you are great at all at once. It would have felt incredibly weird to bring someone in that we didn't have the longstanding

working relationship with because the positioning would be, this is a complete gamble. There's a terrific chance that this is going to fail. And take that on faith. And you did, because we have that shared context. It was an easier conversation, whereas someone who doesn't know me, it sounds honestly like a terrible job. Honestly, this job is pretty much exactly what I was looking for. My curse as an engineer is that I love being a generalist. I love working at every part of a stack. I love being able to build entire features and entire projects and entire products from scratch. And it's kind of hard to find that when you're just out interviewing at random dev jobs.

Everyone wants you to be a front-end engineer, a back-end engineer, an infra engineer. And I want to build whole features. I want to build whole things. And so when you and Mike came to me and said, hey, build this entire product from scratch, not just engineering, but also sales and product and strategic planning, I thought that sounds exactly up my alley. And it was a lot of fun.

Yeah, it's one of those weird edge case stories. And for very specific roles like that, you almost have a specific person in mind when you're reasoning about them. Now, the problem, of course, is if you carry this to its logical extent, that's how you wind up starting a company. And the first thing you do is you hire all of your friends. And invariably, there wind up then being significant diversity issues down the road. And then people step back and think, ah, okay, now that we've hired 20 white dudes, all named Brad, maybe it's time we look at

hiring something different, like a, I don't know, a white guy named Steve. And at that point, it's almost too late because that sends a signal, a strong one and not a good one to people who are considering working there. But by the same token, it's also a very hard type of thing to open up to the outside world. Hey, do you want to take a massive gamble on a thing that probably won't work out and will leave you looking for a new job in six months? And that's a hard thing to sell someone if they're not already conversant with who you are and how you operate. Yeah, it's a tricky problem to solve. You're starting a new company, you know, you want to hire your network because those are the people you already have some amount of confidence in. Networks tend to look like the person who they are centered around. And so at some point you need to get away from hiring just from your network. How do you go about that? I

think probably the best approach, if you can, is try to build a more diverse network. Try to have more friends who don't look like you. It's hard to do, and I don't know that there's a terrific answer here. So what's next for you as of the time that we record this with the understanding that there is always a production delay and some of this may be out of date? That's true. Looking for another super early stage startup. Before Duckbill, I had joined a 400-person startup and they paid me a lot of money, but it wasn't quite what I was looking for. And so when I joined Duckbill, I was really excited to get back to a 10-person company where I could wear a lot of hats and have a lot of influence, have a lot of impact, be able to spend a lot of my time just building. And so I think that's probably what I'm going to look for next. Maybe it's a VC-backed startup that's five people, or maybe it's a bootstrap business that's going to be a bit more sustainable.

But either way, I think it's going to be pretty small and probably involve working with as much of the stack as possible. I'm curious that you're looking for specifically for an early stage startup. Tell me more about that, because that can mean some good things and some very weird things. Because if I look at this with the most cynical possible lens, what I hear you say is you're looking for a very small team that doesn't really know what it's doing yet, where the founder's personality quirks are now business problems, and the runway is very uncertain and shaky, and keeping your resume updated on a weekly basis is top of mind. Change my mind. I think you've illustrated all of the problems with going to an early stage startup. So let me talk about the other side of that balance. You've got a startup that's growing fast. There's a lot of opportunity. New problems arise every month or two. New technical problems,

new organizational problems, new challenges and opportunities to learn and grow. New organizational roles open up to be lead and to be manager and to try to jump into different roles within the organization. You're very close to your other team members. You are having lunch with the sales team, which is often one person. You're sitting one desk across from the CEO, hearing about all the business problems that happen. You can pick up a lot of context just via osmosis about what's going on in the rest of the business because you're just talking to everyone constantly.

Whereas in a much larger or more stable organization, roles are a little bit more ossified. You're a little bit more stuck in your lane. And yeah, I feel like the excitement of a small company like that is a lot of fun. Now, as you point out, there are problems. If the CEO is terrible, you're stuck. There's no team to transfer to. You have to transfer out of the company. If the company fails, well, you might get a month of notice at best to start looking for your next job. These are trade-offs you have to deal with. Oh yeah, we realized this wasn't going to be a success. We were very clear. We made commitments

to ourselves and nothing else. And we wound up giving you what? A little over two months notice that at this point we're going to be winding it down. Let us know how we can help. And that's true. If for some reason you're listening to this and Kevin has not yet announced he's going somewhere, I really can't recommend Kevin enough. He is one of the most insightful engineers I've ever worked with and is also incredibly human as he does it. And I think that that is a very rare thing to find, as I mean that. I work with an awful lot of engineers. I don't think of any of them the way that I do Kevin. Well, thanks. I really appreciate that. And likewise, if you're looking for a job and Duckbill happens to be hiring, you should absolutely go there. It's been some of the most fun six months. It's been well more than six months at this point. It's been one of the best tenures of a company I've been at. I've really enjoyed everyone I've worked with here, from the sponsorship team to the consulting team to the leadership.

Except for my business partner, Mike, because he's not on the podcast to defend himself. Absolutely. We can definitely talk crap about Mike now. So one last thing I want to cover before we call it an episode. Tell me a little bit more about the other shenanigans you have built for fun. Sure. So probably the first one I did, I was stuck on a train, actually with Mike, in Belgium. And the train had no Wi-Fi, so I was just on my laptop messing around. We were traveling from, I want to say, Brussels to Ghent. And I came up with this horrible idea of trying to make Ruby look like JavaScript. Ruby has incredibly powerful metaprogramming syntax. You can do some truly terrible things with Ruby.

And so I managed to make some pretty complex code that was both valid Ruby and valid JavaScript just by massively abusing Ruby syntax. And that did actually pretty well. I've turned that into a few talks I've given at RubyConf. I do things that are super similar, but on the other end of it, it's, yeah, it doesn't matter

if you're using this in Python, Ruby, or JavaScript, it won't work in any of those. Yours worked, and that's the scary part. Oh, yeah, well, I feel like I've got up to several of these projects now, and I'm calling them the sort of cursed code projects. They're terrible, horrible things you should never do,

but they're also technically interesting. Ideally, someone should look at them and say, oh, my God, that's awful. But also, how did you do that? I want to see. That was a blast. I thought that was just fun watching people's brains explode when you showed them this and like, all right, so here I have some Ruby or JavaScript and how you described it. And he said, oh, it is also the other one. And then just watching people sit there and nod and like, it's so absurd, it sort of sails past them for a second and then you can see it hit them and they do a mental spit take.

Exactly. Probably the other one that is probably my favorite and was the most popular one I've ever built when a little bit viral was a CSS only bit viral, was a CSS-only chat. It's a web-based chat. It's asynchronous, doesn't require any page reloading. You can chat between two browsers, and there's no client-side JavaScript at all. It's entirely abusing properties of the HTTP protocol and CSS. And that's definitely one of those how-did-you-do-it things that people have been constantly asking me, and I've got a whole write-up on it if anyone's curious. It's Google CSS-only chat, I think, and it probably comes up at this point. And I got to say, there's one more that was my favorite too, given my propensity to misuse things as databases. You wound up building

a Chrome extension to use Chrome tabs as a database. That's not even a Chrome extension. It's just, it's actually just a webpage. Oh, my mistake. I didn't even realize that. Oh, great. You go to a website and it now is your database. Just make sure that you don't wind up closing that particular window. Exactly. And of course, it's hilarious and nothing you should ever do. So I'm certain at least one bank somewhere is now running their transaction database on top of it. Oh, God, I hope not. There we go. Tabdb.io. I had to actually look up the URL for that. Yes, it actually just uses the tab titles to store DB content. And we will, of course, put a link to that

as well as these other nonsense things into the show notes. Kevin, thank you for taking the time to unpack what we've been up to here. If people care more about what you're up to or want to see what nonsense you're doing next, where can they find you? Sure, kevincookta.com is probably the best URL. It's got my resume, it's got my email,

it's got all the useful contact information you might want. Excellent. Kevin, thank you so much for, I guess, tolerating the slings, arrows, and on some level, I think, disappointment of this not being the thing we'd hoped it would be. No worries. Thanks for having me both at the DuckTool Group and on this podcast. Kevin Cookta, product owner and lead engineer for DuckTools. I'm cloud economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice. Whereas if you hated this podcast, please leave a five-star review on your podcast platform of choice, along with a comment insisting that my thing that doesn't work in any of the languages I named also doesn't work in Rust.

This has been this week's episode of Screaming in the Cloud. You can also find more at screaminginthecloud.com or wherever Fine Snark is sold. This has been a humble pod production stay humble