Subscribe
Share
Share
Embed
Kevin Kuchta is the lead product engineer for DuckTools at The Duckbill Group, a company that you may or may not be familiar with. Prior to winding up in this spectacular position, Kevin worked as a software engineer at Brex, Joyable, Threadflip, and Expensify. He also worked as a web developer at the Rochester Institute of Technology and an applications software developer at GE Energy.
Join Corey and Kevin as they talk about DuckTools and why Duckbill decided to sunset the suite of tools, what the genesis of the product was like, how a Slack message led to Kevin joining Duckbill, why Kevin created a URL shortener with Lambda and why you shouldn’t try that at home, how tricky it is to find the right price point for a SaaS tool, why it’s so important for product developers to talk to customers early and often, why startups become scatterbrained when they focus on too much at once, why the key job of any CEO is to fire yourself repeatedly, the curse of being a full-stack developer, what’s in store for Kevin’s future, and more.
Screaming in the Cloud with Corey Quinn features conversations with domain experts in the world of Cloud Computing. Topics discussed include AWS, GCP, Azure, Oracle Cloud, and the "why" behind how businesses are coming to think about the Cloud.
Transcript
Announcer: 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.
Corey: This episode is sponsored in part by LaunchDarkly. Take a look at what it takes to get your code into production. I’m going to just guess that it’s awful because it’s always awful. No one loves their deployment process. What if launching new features didn’t require you 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.
Corey: 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.
Corey: 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 in Security. To sign up for the newsletter or to find the podcast, visit meanwhileinsecurity.com. coming soon from The Duckbill Group.
Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by my colleague, Kevin Kuchta. Kevin, welcome to the show.
Kevin: Hey, Corey. Great to be here.
Corey: 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?
Kevin: Yeah, that was a fun ride. DuckTools 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 the 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.
Corey: 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.
Kevin: Yeah, I remember you reaching out to me much earlier, in 2020, as 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.
Corey: In fact, we first met 10 years ago now when we work 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 on to that whenever we can find it, and hold on with two hands in a death grip.
Kevin: 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.
Corey: 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.
Kevin: You know, actually, you can take some personal credit for inspiring that. I was reading your newsletter, and I saw an article on creating a URL shortener with Lambda. And I thought, “Oh, wait, how'd you do that? That sounds amazing.” And I looked into the article that you'd liked 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. It was one of my more popular projects. It's horrible; you should never do it in real life.
Corey: 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 immediately by, “We never want to see that person again. 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 got 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@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; we just update it once a minute and render that HTML to a static site, we don't even need to use Lambda@Edge. And the best feature of Lambda@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.
Kevin: Nice.
Corey: 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.
Kevin: Yeah, I think that's exactly right. It was an interesting experience because I had 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 CloudHealth or CloudForecast, but cheaper.
Corey: Right. The entire problem is 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 a fixed fee per customer. And again, we're not a 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.
Kevin: Yeah. Finding the right price point was definitely tricky. We've 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've talked to other people who would say, “Yeah, this tool is going to save me tens of thousands of dollars per month. I’m happy to pay a couple thousand a month for it.”
Corey: yeah, some of the stuff we built too is, “Oh, 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 described 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 the AWS bill. And that is a difficult thing to wind up selling. I would prefer 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 us running into as well.
Kevin: 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, and 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 will 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.
Corey: And traditional SaaS models of subscriptions and whatnot are also challenging in this space. For example, one of the tools that we built—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.
Kevin: 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?”
Corey: 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, “Great. 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 boil down to scenario modeling. “Well, this past month has been weird because, I don't know, it was a 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 do 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, [growling], “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.
Kevin: 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 spending in 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 planning 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.
Corey: 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.
Kevin: Yep. And that was actually a sort of a misstep I made early on when I was trying to sell DuckTools. When I first joined, I sort of assumed, “Well, they 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, 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 with our 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.
Corey: 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 with 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 mistakes sooner or later, and sometimes the only way you learn is by the hard-won experience of getting it really wrong.
Kevin: Yep. In this case, I think that the best-case scenario, if I’d talk to customers sooner than I did—talked to them more and sooner—the best thing that would have happened was we realize 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 just 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.
Corey: 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. 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?”
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.
Kevin: 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 this SaaS tool that we're building. And trying to build three different lines of business at the same time, 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 tools, we're going to be able to focus a lot more on the media wing and the consulting wing.
Corey: 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 percent faster, and helps you act immediately. Ask for a free trial of detection and response for AWS today at extrahop.com/trial.
Corey: 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. And 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.
Kevin: 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 is good at selling SaaS products and someone who's good at selling consulting engagements, but 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 could 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.
Corey: 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.
Kevin: You know, I once spoke to a CEO a couple startups ago that I was working at, and 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 find yourself in a lot of interesting jobs over time. [laugh].
Corey: 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.
Kevin: 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 first on my list of people to call to help me interview people.
Corey: 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 you to fill that role, so kind of a problem. Two, we've been working together on and off for 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 of 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.
Kevin: 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, and an infra-engineer. And, no, 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.
Corey: 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 that 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, “Oh, 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, 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 to someone if they're not already conversant with who you are, and how you operate.
Kevin: Yeah, it's a tricky problem to solve. If you're starting a new company, 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.
Corey: 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 but the understanding that there is always a production delay, and some of this may be out of date.
Kevin: 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 bootstrapped 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.
Corey: 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, 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.
Kevin: I think you've illustrated all 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 the 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 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 it a much larger or more stable organization rules are a little bit more ossified, you're a little 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.
Corey: Oh, yeah, when 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.
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, spend some of the most fun six months—actually it’s been well more than six months at this point. It's one of the better one of the best tenures at a company I've been at. I’ve really enjoyed everyone I've worked with here from the sponsorship team to the consultant team to the leadership.
Corey: Except for my business partner, Mike because he's not on the podcast to defend himself.
Kevin: Absolutely. We can definitely talk crap about Mike now.
Corey: 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.
Kevin: Sure. So, probably the first one I did. I was stuck on a train—actually with Mike—in Belgium, and the train had no WiFi, 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 meta-programming 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 it into a few talks I've given at RubyConf.
Corey: I do things that are super similar but on the other end of it. Yeah, it doesn't matter if you're using this in Python, Ruby, or JavaScript, it won't work in any of those.
Kevin: [laugh].
Corey: Yours worked, and that's the scary part.
Kevin: Oh, yeah. Well, I feel like I've gotten 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.”
Corey: 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 [depending 00:29:36] on how you described it—and he said, “Oh. And it is also the other one.” And then just watching people sit there and nod, and like—oh—they just—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.
Kevin: [laugh]. Exactly. Probably the other one that is probably my favorite and was the most popular one I've ever built, went a little 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. Just Google CSS-only chat. I think it probably comes up at this point.
Corey: 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.
Kevin: That's not even a Chrome extension. It's just a—it's actually just a webpage. Is it still up?
Corey: 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.
Kevin: Exactly.
Corey: And of course, it's hilarious and nothing you should ever do, so I'm certainly at least one bank somewhere is kind of running their transaction database on top of it.
Kevin: Oh, god, I hope not. There we go. tabdb.io. I had to actually look up the URL for that. But yes, it actually just uses the tab titles to store DB content.
Corey: And we will, of course, put a link to that as well as these other nonsense things into the [show notes 00:31:02]. 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?
Kevin: Sure. kevinkuchta.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.
Corey: Excellent. Kevin, thank you so much for, I guess, tolerating the slings and arrows and on some level, I think, disappointment of this not being the thing we'd hoped it would be.
Kevin: No worries. Thanks for having me both at the Duckbill Group and on this podcast.
Corey: Kevin Kuchta, 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.
Announcer: This has been this week’s episode of Screaming in the Cloud. You can also find more Corey at screaminginthecloud.com, or wherever fine snark is sold.
This has been a HumblePod production. Stay humble.