The home team is joined by two folks who help us build and design our frontend platform: Ben Kelly and Aaron Shekey. They talk about the genesis of Stacks, Stack Overflow’s design system; this year’s April Fool’s Day gag; and the power of a consistent design system.
If you’re not familiar with Stacks, Stack Overflow’s design system, it’s a robust CSS and JavaScript Pattern library that helps users create coherent experiences in line with Stack Overflow’s best practices and design principles. Explore more on Netlify or GitHub.
Missed our April Fool’s prank this year? Relive the hilarity and the pain.
Atomic CSS is a CSS architecture approach favoring single-purpose classes named based on visual function.
Today’s Lifeboat badge goes to user ceejayoz for their answer to How do I do a database backup on Amazon RDS every hour?.
Connect with Ben Kelley.
Learn more about Aaron Shekey’s work.
Ben Kelly Yeah. People really were like, "Oh yeah, that sounds cool. I'm not really so sure." So I whipped up a quick proof of concept and whipped up that terminal theme that actually ended up going into production for the April Fool's Day theme. And people were just kind of blown away. They were like, "Oh, wow. I didn't realize that this was so powerful, that we have so much control here." So we were able to really get in there and shake things up because everything was all using the one system.
Aaron Shekey So for that specific theme you made everything pretty much stark black in the background. You changed the font to a console font and then made all the text like lime green, not even like a modern terminal, to be clear, right?
BK I actually went and looked up the color codes for the VT, what is it 26 or something like that? I actually went and looked up the original manuals for that and pulled some of the color codes. I was going to take it even further and do like the red and blues, all those original colors, but I didn't get to it.
AS We even turned off the anti-aliasing on the text so it was like super jagged and hopefully looked like a super old machine. I say, "We." I mean, "Ben."
[intro music plays]
Ben Popper As large organizations find themselves navigating their way around hybrid cloud, developers are being asked to shift their priorities as well as their mindset for this new world. For insight on new cloud architectures, deployment strategies, and the shifting culture landscape, tune into Cisco's podcast, Cloud Unfiltered. Here comes the URL, it's cs.co/podcast.
BP Hello, everybody. Welcome to the Stack Overflow Podcast, a place to talk all things software and technology. I am Ben Popper, Director of Content here at Stack Overflow, joined as I often am by my wonderful co-hosts, Matt and Cassidy. What's up, y'all?
Cassidy Williams Hello!
Matt Kiernander Hello!
BP It's my favorite time of year. We're going to talk about the April Fool's joke. Why we did it, how we did it, why we will never stop doing it. So we're going to welcome to the show Ben Kelly and Aaron Shekey.
AS Yeah! Nailed it.
BP Ben, Aaron, welcome to the show.
BK Excited to talk about the April Fool's Day prank.
BP Yes. So before we get going on the April Fool's stuff, we always ask folks, just give us a quick flyover. Who are you? How'd you get started working with software code design, and how'd you end up in what your current role is and what is that?
BK Yeah, actually, I started programming for real in college. I did some dabbling a little bit before that, but got started programming for real in college. I figured out pretty quickly that the easiest way to get like a GUI app that people would actually use was web page. And so it was super easy to get started, way easier than WX widgets and C++ which is what I was doing at the time. And the rest is history. I pretty much just got into it and I just really got into it. And then from then on I was like full stack with a focus on front end. And nobody who is a full stack developer wants to do front end, so that earned me a little niche.
BP And for folks who are listening, what is it you do? What's your title and sort of your day-to-day here at Stack Overflow?
BK Oh, my title at Stack Overflow is Senior Front End Developer, Tech Lead on the Stacks Design Team, something like that. I give designers the tools to push pixels around.
BP The pixel pushers. Aaron, you have been on the show before with me to talk about dark mode, which again, takes us back to Stacks. Before we get to defining for our listeners what Stacks is, Aaron, just give us your quick flyover. What got you into this world? What have you been working on at Stack? I know you're heading off to work on something new, you can tell us about that. And then let's dive into what is Stacks. That'll help folks understand why you two work together and April Fool's and how we do front end design here at Stack Overflow.
AS So I'm a designer that codes. Code has always been a way for me to further what I'm working on. It's way easier to communicate in that medium when you're at a company full of engineers. Also it's Stack Overflow.
BP It's frickin' Stack Overflow!
AS Yeah! To be able to talk in that medium has always been super important to me, so I cut my teeth making websites, and then I moved over to Adobe to make tools for people who make websites. Then I headed to GitHub to make tools for people who make tools. And then the next gig was Stack Overflow. So I was a designer, I got hired as a designer, still a designer. And I quickly went to all the different lines of business at Stack Overflow and worked on the front end there and realized very soon that there was an opportunity to formalize a lot of the code into a design system. And at the time, design systems weren't really called that, it was just CSS libraries or what have you. And so myself and some other designers at Stack Overflow formalized that into a design system that we call, maybe somewhat confusingly, Stacks.
BP Yes. Nailed it.
AS So you can look at that, it's open source. You can look at that at stackoverflow.design. And we host that on Netlify and it's sick. We really love it. So we publish right to that website and everybody can use it to build the front end of Stack Overflow.
CW Stacks is super interesting and I don't think I fully realized that it existed. I knew there was some instance of something on Netlify because I used to work at Netlify and everyone was like, "Ooh, Stack Overflow and us! So fun!" But how did you use it for the April Fool's prank? And also, could you describe the prank because not everybody knows what it was.
AS So Stacks is a shared CSS library that powers all of the Stack Overflow stuff. Ben and I worked on a theming API that anybody could hack into. And so Ben really took the April Fool's prank and implemented it. So, Ben, talk about that. How did you do that? How did you use Stacks?
BK Absolutely. So I had been approached on an April Fool's Day prank saying, "Hey, we want to do like a filter for Stack Overflow, like a Snapchat filter or something. We want to make one of the pages look like an old Omega or something like that. Is that doable?" I'm like, "Well, we can do better than that." Almost the whole site, we've got some legacy stuff out there, is powered by our Stacks design system which gives us a whole consistent set of the components, buttons, links, modals, whatever. And it's actually backed by a really powerful theming API, both with like static colors, which are like red, green, blue, and shades of that, but also custom 'theme' colors, which are like what Collectives, Teams, and Enterprise tap into to do custom dynamic theming for their users. So I was like, "Yeah, we can do one step better, really. We can just do the whole site all at once in one go with not too much work, hopefully." People really were like, "Oh yeah, that sounds cool. I'm not really so sure." So I whipped up a quick proof of concept and whipped up that terminal theme that actually ended up going into production for the April Fool's Day theme. And people were just kind of blown away. They were like, "Oh, wow. I didn't realize that this was so powerful that we have so much control here." So we were able to really get in there and shake things up because everything was all using the one system.
AS So for that specific theme, you made everything pretty much stark black in the background. You changed the font to like a console font and then made all the text like lime green, not even like a modern terminal to be clear, right?
BK I actually went and looked up the color codes for the VT, what is it 26 or something like that? I actually went and looked up the original manuals for that and pulled some of the color codes. I was going to take it even further and do like the reds and blues and all those original colors but I didn't get to it.
AS We even turned off the anti-aliasing on the text so it was like super jagged and hopefully looked like a super old machine. I say, "We." I mean, "Ben specifically."
CW It really kind of shows the power of a consistent design system though. Anybody could do something like this if a design system is actually obeyed, which can be rare in a big company.
AS We describe it as we've installed all the knobs that one could twist to make Stack Overflow look like anything. So rounded corners as a tiny example, shadows, all of the colors, typefaces, we now have this control panel that, for lack of a better metaphor, that you could make it look like whatever you want. And so when an opportunity like April Fool's comes along and we want to really stress the system and see what we can do, some of those themes were wild.
CW For sure. And I imagine because this is a capability, do you see Stack Overflow potentially using it more in the future to make more themes? I know that there's a design system for a reason, there's rules and stuff. But do you see something like this being more permanent or used in the future?
BK Yeah absolutely. We actually already use it for Teams, Enterprise, Collectives, to do the theming there, but we actually also use it to theme our network sites in a diminished capacity. So it would be really nice to see, and I'm not gonna make any promises here because I don't control roadmaps, and I don't want to tip our hand a little bit because we do have some really cool stuff coming up from this, but I would love to see us lean into that more and use it to theme more network sites.
AS We can commit to accessibility stuff, like we do have a beta of high contrast modes right now.
CW Oh, nice. That's great.
AS So we shipped that, and that works in both light and dark modes. I've dabbled in changing typefaces to make it easier to read for people who are dyslexic, that kind of thing. So beyond product features there's just base accessibility stuff that we could do.
MK So I was having a look at the stackoverflow.design website before, and it was really, really cool. The design is fantastic, first of all. But you've got the option to change dark mode, custom theme, high contrast mode, and all of those look fantastic. One of the things I would love to hear about is, from a business perspective, implementing a design system as comprehensive as what you've described is a huge investment. I would love to know how you approached that from a business case perspective, what hurdles you encountered, or how you kind of sold the value that a design system like this can bring to a business.
AS Yeah. So the design system came out of the design org, and originally the way we came about it was to create an Atomic CSS library. Atomic CSS libraries were very new at the time. I think with both design systems and Atomic CSS, those were pretty radically new ideas that most companies have adopted, at least design systems have. But it was an unpopular idea at first. So when I first encountered Atomic CSS, I was really dubious, I was really skeptical of it. It kind of flew in the face of all of the current best practices, until I used it. Diana at GitHub was amazing and she actually introduced the Atomic CSS library that they use, Primer, there. And I used it and it was amazing. It was this huge gasoline to a fire that quickly got out of hand and we were shipping stuff amazingly quick. So I wanted to do the same thing at Stack Overflow and convincing people was tricky. Part of what I did was I just had to build the thing. So I took those afternoons that are in between meetings and shipping stuff and really just built the first versions of the Stacks design system. And then, I, hopefully in a friendly manner, just kind of road showed it a little bit. I challenged people, "Let's build something with Atomic classes and let's build something traditionally. What are you working on? Let me show you how you could build it in this new system." I did that enough times where it just kind of took off and we were able to convert more and more of the UI to this Atomic system. Now, the weird thing about Atomic classes is, you wouldn't want to describe buttons or popovers or these more component things with just Atomic classes. So once we started to formalize things like buttons and all of these other components, that's when the design system took a more traditional shape.
CW This is relevant but also not relevant. Something that I think is interesting about Stack Overflow is it's one of the few companies that really uses top-level domains differently compared to other companies, where it's stackoverflow.blog, stackoverflow.design, all of these different URLs instead of all branching off of stackoverflow.com. Is that because they use different design systems or is it like a different site, different teams, that sort of thing? Or is it all part of a big codebase? I know that's somewhat off topic, somewhat on topic, but I'm interested in that.
AS So we have a single repo that powers most of Q & A. When we were building the design system we were a scrappy company, believe it or not. We were a scrappy team, it was really just me in my free time. And I wanted to use tools that didn't require a procurement team to get, stuff that didn't require too much oversight or a credit card. And so I was very easily able to spin up a Netlify site to host the documentation at this domain, and that was very easy for me to get feedback across the company. Instead of say, going to some engineer, borrowing some cycles and [asking,] “How do I spin up a new URL at stackoverflow.com?” And it also helped to just focus it. This is a design effort, this is what it's about. You go here, it's only about that. And then there was some other benefits to redundancy. The design system would always be independent of Stack Overflow in case one went down. But to answer your question about multiple design systems, all of those URLs use Stacks as a library. So we don't really care where it's hosted, you can just NPM install Stacks, and you get all the stuff.
MK For people who might be curious about Atomic CSS and building their own design libraries like this, would you say that there's a definite point where something like this becomes really viable or necessary? Or what kind of use case, what kind of company and product would benefit best from implementing a system like this?
BK I can talk about that a little bit. I think that pretty much any company of any size would benefit from doing this. The major benefit it gives you is that all your designs are going to be consistent. We've got padding classes and let's say you look at a big one like Tailwind. Very, very, very popular Atomic CSS library. And all the padding classes are consistent. You've got padding 1, 2, 3, 4, and they're consistent all the way across the site. A designer shoots you mockups and you say, "Okay, well, look, that's definitely padding 2 and that one's definitely padding 4." I don't have to guess. I don't have to guess what button to use, what colors to use. I don't have to go ask the designer, "Which colors did you use here?" It's super, super nice to have just this one design language that you can use everywhere. But I also remember when I first started here, four-ish years ago. I started on the Teams team, actually, full stack. We were still running a little bit of CSS at the time, and we were still kind of getting over that hump using the Atomic CSS. I was a little dubious at first, too. I had never really done anything like that, and I found the benefits of it very quickly outweighed the dubiousness. I really started becoming a champion of that internally, and I think that there has not been any new single line of CSS written by any of the devs in just an incredibly long amount of time. And it's very impressive because CSS is one of those things that's really easy to screw up, really easy to get a very slightly subpar design out because the padding's a little off here.
CW Right. Or just reality is different from a screenshot or a design document. It's something that I've seen a lot of debate about online, where it's just like, "Is this just recreating Inline CSS? Or is it just another language you have to learn on top of the dev languages that you already know?" But at the same time, if you do know that language and can learn it relatively quickly, it saves you so much of reinventing the wheel.
BK Yeah. My argument there is, it's not like Inline CSS at all is something that I thought, too. But the benefit there is that it's consistent everywhere. P4 means you've got four pixels of padding, four Ems or something. And you've got background-danger and it's always going to be the same color everywhere. You're going to have a class for background-danger anyways, why not make it something that's consistent throughout background-danger, background-success, you know what I mean? So that's my argument to that. I'm a sold convert.
CW It reminds me of a friend of mine who used to work on Internet Explorer back in the day. And there was a point where she was saying that they were switching over to Edge and transferring some stuff but not other stuff. And they realized that they had 45 different blues. Just the color blue in the browser. And she was just like, "People were just making it up and eyeballing it and we just let this happen." And so when they ended up scrapping all of it to just make it something on top of Chromium, they had a much more consistent design system for that because like you said, if you're going to have a background-danger anyway, it might as well be the same everywhere.
AS The interesting part about that is we have 10 blues. We have true blue and then we have powder and then technically we have theme secondary, which is configured to be blue, and that's how we power everything, really. So we have all of these steps that you can say, "I want Blue 400," which is like the purest blue. And then if you want to go darker you can do Blue 900. And the thing that really busted the theming wide open for the API was that we can build those steps using any arbitrary color now. And so in the terms of theming, if we want to change primary and secondary to whatever color that we want, we have the full expressive API there. So at the lightest end, you can say theme primary 50, which would be in our case, a really light orange if you want to have just a thing behind some text that says, "Alert" or what have you. And then you can also have that very expressive Orange 400, which is our branded color that's in our logo. And then we can do all that swapping on the fly for dark mode, for high contrast mode, for wild April Fool's themes. If we want it to be lime green for an afternoon we can do that.
BK Or for say your team, your Stack Overflow for Teams team. Your primary color is green, let's say. All the tags go from that blue with a darker blue border, to a green with a dark green border, just automatically.
CW It's like Lego pieces it feels like, where you can use all of these building blocks to create a site and not have to make one out of clay to fit in your castle.
MK This appeals to me for a number of different reasons, because I'll be completely honest, CSS is not something I terribly enjoy doing for just general formatting and business logic. I like creating cool stuff in the web browser, like p5.js and like 3D things, that sort of stuff I can really get behind. But for me, I get much more enjoyment out of building the actual functional building blocks behind a website that actually makes it do stuff. I'm much more heavy and invested into the JavaScript side of things than the CSS side of things. And that might be partly because I haven't spent the time to fully appreciate and use CSS as a tool and that I’m getting frustrated with it because I don't know how to use it properly. But I just enjoy working through all the state management and getting things to actually do stuff. So everything that you've just said about Atomic, where you do the work upfront and then just use that as Lego pieces for your castle just to plug things in and it should all just work. I love this idea a lot.
AS We also have a JavaScript layer, too. So things like popovers and modals and those kinds of things, we do offer APIs for hiding, showing, and doing all that. And we actually use Stimulus as a library for that, that's from the Basecamp folks. Mostly because it just doesn't really care what your markup is or where it came from. So as Ben was alluding to, we've got a lot of legacy stuff at Stack Overflow. We've been a product for 14 years now.
CW Time flies, man. That is wild.
AS I know! Well that's the thing with Oxygen. It's just very old, it's been there forever. And so there are parts of the app that, let's say we wanted to adopt React. That would probably be pretty tricky unless we're really diving in. And so Stimulus allowed us to get some reactivity out of our layouts and interfaces.
MK Do you think there comes a point where you have a product that's been around for so long, and moving forward into the future of a website like Stack Overflow where there's a lot of new technology that comes out that solves a lot of problems that historically have been there. Do you think it'll get to a point where it becomes like you're wrestling too much with the legacy and it becomes a business case to build new? Do you think products that were built 10-15 years ago will continue to stay the course or they'll eventually have to be rewritten and built from scratch?
AS I think about that every day. In my darkest moments I want to throw the whole thing away. There is some truth to, "I could do this in a weekend, I swear!" when you're adopting new technologies, but you can't recreate the 14 years of folks being there and falling in love with the product, and even if they don't love the product, they know how it works. There has been quite a bit of internal conversation about if we can redo parts of the site using newfangled technology. What would happen if we spun up login and signup as a React app, for example? Could we consume Stacks using React? The answer is, yeah, we could. It's a tricky debate and it's well above my pay grade, I'll tell you that much.
CW It reminds me of the concept that the Astro framework has been pushing out about islands architecture, where you have different islands of tech stacks. Where you could have one website where a big section of it is Vue and a big section of it is React and other various frameworks, and because they all connect at certain base layers, you can kind of build these islands where you could add Stacks to each one, or different CSS libraries or frameworks to others.
AS Well, what do you call a framework and where do you draw those lines? I could make the argument that Stack Overflow is built in .Net, which is a framework, and we're using Razor, it's not static HTML, of course. So where do you draw that line and would we ever adopt maybe just a backend API that then is hydrated in a Vue app, for example? Maybe. I don't know.
BK Yeah. It's definitely something to think about, but I'd be a little cautious about chasing the shiny. Because what happens is that you chase the shiny and you get it in one place and then a new shiny comes up and you put it in another place. And then suddenly you've got a big pile of refuse that's covered in shiny and none of it works. I've seen this in the past. I don't want to experience it again. So you've got to be careful with that as well. You also have to be careful with like, "Let's do a little bit of this in Vue, a little bit of this in React," even if that's the only two things you did. I'm just using two things randomly, I don't have a specific opinion on either of those frameworks in this case. But then you have developers who are okay at Vue and okay at React and no one's actually good at anything. So you've got to be really careful about how you do things holistically, but there's definitely some point where you have to say, "Okay, this version of jQuery from 2015 has got to go. We've got to at least get on jQuery 2, right?" Things like that. And also adding something like Stimulus over the top and stuff like that just to get a little more shiny.
MK I've seen that happen quite a few times. Especially, I think it's quite common at agency environments where you have a whole bunch of different projects and developers and you're trying to pick the best tool for the job. And then even if you've got like a main product site and somebody gets the idea to try and implement React or Vue or whatever it happens to be at that specific time, and then you get all these different microservices that come through, and then you've got to support all these different languages. You get front end devs coming in who don't know Vue or they don't know React or they're on an angular dev or PHP, whatever else. And then you just have these really fragmented skillsets where nobody's really able to contribute in a meaningful way quickly, and it becomes quite disruptive. I've seen some agencies as well that describe themselves as full JavaScript shops. So that means that anybody who does know JavaScript can come and can contribute to each different area as they come in. But it's interesting, like the whole landscape of front end and everything that's going on with CSS libraries and everything else. I'm curious as to where it's going to go long-term to be honest and how I'm going to manage the scale and all the different tools that we have to learn to do our jobs.
BK Yeah, the front end ecosystem is really growing at a very quick pace and in some ways that's good. We're getting some really cool stuff out of it. In some ways that's bad, we're getting a lot of turnover and people are getting fatigued and in some ways that's worse. Like, Redux is what's hot right now, what was hot before Redux? I don't even remember the name of it. I wish I could because I was going to make fun of it. I didn't use it personally, but that's what you're supposed to do, right? You're supposed to make fun of it because it's old and busted.
AS Yeah, and it was like two years ago.
BK Yeah, exactly. But it's not that long ago, right?
CW Right. It kind of ebbs and flows where I think five years ago we were just like, "Ah! There's a new framework every minute." Then it felt like it slowed down. And then suddenly they all popped up at once and we're in that peak again of just tons of frameworks coming out and lots of ideas. Which I think ultimately will be good because we are only getting better, but, you're right. It's going to be a lot of fatigue, rollover, people not sure what they should learn. I pity the newbie who has to figure out which thing is the best thing to learn at any given time.
MK It's so hard!
AS The low-level frameworks are getting better and better each day as well. CSS this year alone, I've seen more stuff come out that I'm cautiously optimistic for, but the browser landscape is such that what used to take five years, you're like a release away from being able to realistically target. So a lot of the stuff that we're talking about with the theming API feels like it's right around the corner.
BK Yeah, CSS Colors 4, I think it is.
AS Yeah, just native in the browser. Similarly, there's a lot of interesting stuff happening around web components and we might be building stuff natively and then spitting it out to these frameworks because the native low-level libraries are getting that much more powerful.
CW Right. Well, even with React, for example. This new Version 18 that just came out took years to develop. It used to be like, "Oh, there's a new React version every few months." And React is now, it's hard to believe, almost 10 years old, which is crazy, but now every single change is much more deliberate and it's much more backwards compatible and it feels like it's trying to be more like, "We're being smart about this thing that you can use in the browser and take advantage of its capabilities." And I think that is a good thing that they're being thoughtful about because they're so big and millions and millions of developers probably use React. And I think all of these other frameworks are going to be following, where the browser is very powerful, it's basically an operating system when you compare it with mobile applications, for example. And so being able to use it as such means that you want to build in a smart way that takes advantage of it.
AS Or to even be able to look at existing technology in a different way. There's nothing new about Atomic CSS. It's just a completely different rethinking about how to interact with it. We could see something like that with JavaScript. I'm looking forward to stuff like that.
[music plays]
MK Do we want to do recommendations today if anyone's got any cool tech shoutouts? Aaron, Ben, is there anything cool tech-wise that is top of mind for you?
BK Well actually, my first shoutout would be, if any of this stuff sounds cool that we're doing, we're hiring on our front end team. So if y'all think you have the chops, apply. We want you. As far as cool tech things, I've been working with Svelte recently. I'm really digging it, really digging Svelte quite a bit. And Tailwind.
MK Everyone I know who's tried Svelte just in the Twitterverse, I'm not saying it's a cult just yet, but everyone seems to be extremely passionate by how good it is.
BK Yeah. I just picked it up recently just to try it out and I'm like, "You know what? I like this."
CW One of those things on the pile– I'll get to it as soon as I can. I have been very curious lately about just kind of edge functions in general. It's been very hyped by all these different Jamstack companies and everything. And I've poked around with Netlify's beta of edge functions and there's Cloudflare's version of it and Vercel's version of it. There's all these different versions of it, but I feel like it could be a really interesting way to do static sites that are more optimized for your geolocation and for just things that might interest you in personalization and stuff. And I'm dabbling with it, haven't built anything serious with it, but it's been interesting.
BK I've dealt with that too. Just haven't got around to it, like you say.
MK Speaking of getting around to it, I found a lifeboat, which we can say and finish off the episode. So today's lifeboat, for those of you who don't know what a lifeboat is, a lifeboat is an answer score of 20 or more to a question score of -3 or less that goes on to receive a score of 3 or more. This badge can be awarded multiple times, and this one in particular goes to ceejayoz for answering the question, "How do I do a database backup on Amazon RDS every hour?" So, thank you very much to Ceejay for contributing to the site, and thank you everyone else for tuning into this podcast. Ben and Aaron, really appreciate your help and support getting April Fool's out of the way. Everyone really enjoyed it. I personally enjoyed the Mario theme that came out.
BK It's online.
CW Nice.
MK Yes, thank you. That was absolutely wicked, so appreciate your help on that one. Today, I've been Matt Kiernander. I'm a Technical Advocate at Stack Overflow. Thank you very much for tuning in. If you've got any questions, feedback, anything else, email podcast@stackoverflow.com.
BP I am Ben Popper, Director of Content here at Stack Overflow. You can always find me on Twitter @BenPopper, email us, podcast@stackoverflow.com with questions or suggestions. If you listen to the show a lot and you email us there I will shout you out. So long time listeners, send me an email and hear yourselves broadcast on this program. And last but not least, if you enjoy the Stack Overflow Podcast, go ahead and leave us a rating and a review on your podcast platform of choice. It really helps.
AS So I'm Aaron Shekey. You can find me on Twitter mostly, but it's @AaronShekey literally everywhere. Also aaronshekey.com, of course.
BK I'm Ben Kelly, Senior Front End Engineer at Stack Overflow. And you can't find me anywhere online because I'm one of those losers who doesn't have social media.
CW I don't think you're a loser, I think you're an actual winner in this case.
BK I appreciate the compliments.
CW I'm a loser with social media. I'm Cassidy, @Cassidoo. You can find me at that on most things.
MK Thank you very much, everyone, for tuning in. We will see you again next week.
CW Bye!
MK Bye!
[outro music plays]