Screaming in the Cloud - Memes, Streams & Software with Cassidy Williams

Episode Date: July 6, 2021

About CassidyCassidy is a Principal Developer Experience Engineer at Netlify. She's worked for several other places, including CodePen, Amazon, and Venmo, and she's had the honor of working with various non-profits, including cKeys and Hacker Fund as their Director of Outreach. She's active in the developer community, and one of Glamour Magazine's 35 Women Under 35 Changing the Tech Industry and LinkedIn's Top Professionals 35 & Under. As an avid speaker, Cassidy has participated in several events including the Grace Hopper Celebration for Women in Computing, TEDx, the United Nations, and dozens of other technical events. She wants to inspire generations of STEM students to be the best they can be, and her favorite quote is from Helen Keller: "One can never consent to creep when one feels an impulse to soar." She loves mechanical keyboards and karaoke.Links:Netlify: https://www.netlify.com/TikTok: https://www.tiktok.com/@cassidooNewsletter: https://cassidoo.co/newsletter/Scrimba: https://scrimba.com/teachers/cassidooUdemy: https://www.udemy.com/user/cassidywilliams/Skillshare: https://www.skillshare.com/user/cassidooO’Reilly: https://www.oreilly.com/pub/au/6339Personal website: https://cassidoo.coTwitter: https://twitter.com/cassidooGitHub: https://github.com/cassidooCodePen: https://codepen.io/cassidoo/LinkedIn: https://www.linkedin.com/in/cassidoo

Hello, and welcome to Screaming in the Cloud, with your host, Chief Cloud Economist at the Duckbill Group, 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 part by Thinkst. This is going to take a minute to explain, so bear with me. I linked against an early version of their tool, canarytokens.org,

in the very early days of my newsletter. And what it does is relatively simple and straightforward. It winds up embedding credentials, files, that sort of thing in various parts of your environment, wherever you want to. It gives you fake AWS API credentials, for example. And the only thing that these things do is alert you whenever someone attempts to use those things. It's an awesome approach. I've used something similar for years. Check them out. But wait, there's more. They also have an enterprise option that you should be very much aware of. Canary.tools. You can take a look at this, but what it does is it provides an enterprise approach to drive these things throughout your entire environment. You can get a physical device that hangs out on your network and impersonates

whatever you want to. When it gets NMAP scanned or someone attempts to log into it or access files on it, you get instant alerts. It's awesome. If you don't do something like this, you're likely to find out that you've gotten breached the hard way. Take a look at this. It's one of those few things that I look at and say, wow, that is an amazing idea. I love it. That's canarytokens.org and canary.tools. The first one is free. The second one is enterprising. Take a look. I'm a big fan of this. More from them in the coming weeks. This episode is sponsored in part by our friends at Lumigo. If you've built anything from serverless, you know that if there's one thing that can be said universally about these applications, it's that it turns every outage into a murder mystery.

Lumigo helps make sense of all of the various functions that wind up tying together to build applications. It offers one-click distributed tracing, so you can effortlessly find and fix issues in your serverless and microservices environment. You've created more problems for yourself? Make one of them go away. To learn more, visit Lumigo.io. Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by Cassidy Williams,

Principal Developer Experience Engineer at Netlify. Cassidy, thanks for joining me. Thanks for having me. So you're famous in many circles for things that have nothing to do with your actual job, or at least that's the perception. So let's at least start there, because I'm not sure we'll get back to it. What is Netlify, and what does a principal developer experience engineer do at such a place? Yeah, so the shortest answer is it's a place where you can host your website. The longer answer is it's a whole development workflow. You can build whatever types of complex websites that you want, and we make it very easy to get it up and running. And my job there is on the developer experience team. And

basically what we do is we are developer experience engineers. We try to build things and show developers how to make their apps, their websites, their various products and projects easier to build on Netlify. Sort of the whole idea of what I used to think of, I guess, as static websites and various ways to host it, which I think is now called Jamstack, but that probably also misses a fair bit of nuance because I'm going to be completely transparent here. I am crap at all things front end. You know, it takes all kinds to make a project work. Yeah, so it is more than static. I like to think of it more as like static first.

The way I've defined Jamstack that kind of clicks with most people is writing Jamstack. And for those who don't know, it initially was an acronym where it was like JavaScript APIs and markup stack. And so it's less about technologies and more about like the philosophy of building websites. But the philosophy of it is, it's kind of like building mobile applications, but in the browser, where you try to build as much as you can upfront and then pull data in as needed.

Because in a mobile application, when you have something native, you don't server-side render the UI every single time. The UI is built pretty... Well, not with that attitude, anyway. That's true. That's true. But when you're on a mobile app, you don't normally pull in the UI every single time. It's built in, and then you pull in data as needed. Sometimes it's local, sometimes it's on a server somewhere. And that's what Jamstack is all about. It's building as much as you can up front, and then pulling in data as needed. The idea is incredibly compelling, and it gets at an emerging trend that I don't think that there's

any escaping. And maybe this is overblown. I'd love to get your feedback on it. I can't shake the feeling that JavaScript is the future, not necessarily of front end in general, when it comes to effectively computers. We're seeing it on the back end. We're seeing it on of front end in general, when it comes to effectively computers, we're seeing it on the backend. We're seeing it on the front end. The major cloud providers are all moving in a direction of approaching folks who have JavaScript experience. And that's the only certainty in that persona that they wind up identifying. It is very clearly not going away while getting more capable. Is that fair? Is that missing something?

What's the deal there? I keep hearing there's like a rule that people are saying, like, if it can be built in JavaScript, it will. Because I think it started as kind of like this toy language that people didn't really take seriously. But it has not only become more powerful, but also browsers have become more powerful too. And you can just build more and more with it. And because it's kind of a low barrier to entry language, it's relatively

simple to at least initially learn JavaScript before you get into all the nuances of everything that I think just because there are more people using it and it's easier and faster to pick up than something like assembly or C++ or something. I hesitate to make generalizations because you never know, but it does feel like that sometimes, that JavaScript is just the way that things are going. And I admit a couple of times I have tried to get into the JavaScript world and it isn't clicking for me.

My lingua franca is crappy Python, and it's just crappy enough to run, but it's neither elegant nor well-designed. It is also barely functional, and every time I have brought in an actual developer to turn some of my scripts into something a bit more robust, they ask me what it does. They smile and nod a lot and never take their eyes off me for a second and then immediately get rid of everything I might possibly have touched. This is, of course, a best practice where I'm involved. But it runs. Like, this is the worst call I've ever run. Ah, yes, but it does run. The problem I have with JavaScript is that I do not understand it. The idea of asynchronous calls on a browser completely melt my brain whenever I look at it. That's caused a few of my early naive mistakes where, oh, go ahead and set this value and then use it here down below.

And wait, why is it completing before it has that value? And it's not, what is going on here? And now I understand the general principles of it, but I'm still getting lost and confused in the weeds. Now, is this just another expression of me being secretly terrible, or is there a nuance here that I'm not picking up on? I was smiling the entire time you were saying this because I feel like almost everybody who is new to JavaScript coming from another language has had the exact same issues. So you're not alone, and you're not a total idiot. So I decided that it was time to learn it the second

time. And I, all right, I'm going to break my own rule, which is the way I normally learn something new is I'll dive into it and start building something. And then we'll see what happens. Sure. It means I'm a full stack overflow developer and my primary ID is copying and pasting, but I can get something sort of functional that works. That approach wasn't working for me. So what I did on my second attempt was, ah, I'm going to go actually do the unthinkable for me and read some documentation and or some tutorials. And I was almost immediately blown off course there because suddenly I find myself just wandering onto what I can only describe as a battlefield between all of the different frameworks I could have chosen between.

And it seemed like the winning move was not to play. What am I missing? Are these frameworks hard requirements for doing anything that even remotely resembles front end in a responsible way? Are they nice to haves? Is it effectively a side current debate that I got suckered into and lost the forest for the trees? You probably got sucked into many debates because there are so many in this world.

I do not think you need a framework to do complex web apps or any web apps. I mean, my personal website, as much as I love React and I'm deep in the React world, I did that with Vanilla, HTML, CSS, and JavaScript, and that's all it is. And plenty of the projects that I do, I start with vanilla and then I add React as needed. I think it's something where these frameworks, you don't need them, but it's really nice once you start building large applications where you don't want to reinvent the wheel. Because there have been plenty of times on my own projects, on other projects, where I start to basically start implementing state-driven components and trying to parse templates and stuff that I end up making for myself. Where if I did React, I probably wouldn't need to actually implement all of those.

And so you don't need these frameworks. That being said, they can be very helpful as you make more complex projects. So I periodically post an architectural diagram of the pipeline slash workflow thing I use to write my newsletter every week. And I was on the verge of just hiring a front-end developer to build something front-end, because it turns out that there's not a great experience in using a whole bunch of shell scripts that require a CLI to post at random API endpoints. And then I discovered Retool, which is one of those low-code tools that more or less is visual basic for front-end. It was transformative because suddenly it's, oh, when I click this button, make this query that hits some API that I can define, and oh my stars, it was transformative and I was actively annoyed I hadn't discovered it years ago. Yeah, all of those low-code tools for web devs, they've been growing.

That is a really interesting realm of the web that I'm curious about. I've played around with quite a few of them, and some of them I kind of end up just wishing that I built it myself in the first place. And then for some of the others, I'm like, you know, this saved me some time. And yeah, I think those things are really, really powerful. I don't know if they'll ever fully replace having an actual developer, but for a lot of individual smaller tasks, it's really nice to not have to, again, reinvent the wheel.

And you're right. These tools are getting more capable. The problem I have is whenever I talk to the teams building these things, they're super excited about them and can't wait to show them off. And then I say, just quick question, of all your engineers here, how many of them don't know JavaScript? And the answer is

always the same. None of them. Great. Yeah. Now there's an opportunity to present this to existing front-end developers so they can get back to what they were doing when they build a quick internal tool for someone else in a business unit. But there's an entire untapped market of people like me who don't understand JavaScript. So when we see these things described in JavaScript context, it looks like it's not for us, even though it very much is. There's something to be said for making things accessible to an audience that would benefit from them. Yeah. I've actually given a few talks where it's geared towards a backend developer who might want to dip their toe into frontend but have no idea where to start. And that is a whole world of

people who are like you, who just don't understand the DOM in the browser and how the interactions happen and how the async await stuff works and how promises work and everything. And they're very weird concepts that just aren't in other parts of programming typically. And I think that's a marketing problem where a lot of these low-code tools or no-code tools don't understand the opportunity that's available to them. I think that there's a misunderstanding in many respects where I've also seen a fair bit of, I can only call it technical bigotry, I guess, is the best framing here of, oh, where front-end is easy and back-end is the hard stuff. And that's really where it's at. And having worked with qualified teams on both sides and looking at all the intricacies on both sides, where the hell does that come from?

You know, I think it just comes from the past. So do I! And I don't agree with it. It's just such a misunderstanding and a trivialization of such a valuable area of things. It kills me every time I see it. Yeah, it's frustrating, I admit, because I've faced that a lot in my career. I actually, I used to do backend. I used to do Python stuff and I have a computer science degree, but plenty of times there's some kind of backend dev who's just like, ah, well, I know HTML and CSS,

so I know frontend. And that's about it. Or they'll say like, well, do you really need to know this kind of algorithm or this way of doing things in an optimized way? Because you're just putting a pretty face on the data that we're producing for you. And it's an annoying sentiment. And I really think that it's just from a previous time, because a long time ago, from five to seven to 10 years ago, that might have been more true, because we didn't have some of these frameworks

that do a lot on the front end. And we didn't have things like GraphQL and really powerful tools on the front end where back then it was a lot of the back end doing stuff and then the front end making it look good. But now the work is distributed a bit more where our back end teams, I can say, build however you want. You can change your language to Rust, to Go, to whatever. Do whatever you want. As long as the data is exposed to me, I can use it and run with it. And then all the routing ends up happening on the front end. All of the management of that data happens on the front end. All of the organization and optimizing for the browser happens on the front end. And so I think both sides have been empowered in recent years in that regard because, again,

with that modularity, you can scale a lot better. But those lingering sentiments are still there and they're annoying. But unfortunately, we've got to live with them sometimes. So let's talk as well about, I guess, sort of the elephant in the room. Your Twitter feed is one of the most obnoxious parts of my day, specifically because every time you post something, I am incredibly envious about the insight it provides, the humor inherent in it. I wish I had thought to go in that direction is almost always my immediate response. And it kills me. Let's talk a little bit about that. How did it start and how is it continuing? That's a good question.

So I've always been a bit of a clown, both on and off the internet, but I was never very, very public about it for a while there. Either that or I just had a small audience and people were just like, there she goes again. Maybe she'll shut up someday. And so I've always had those little drops of humor where I can because I think I'm amusing myself at least. But about a year and a half ago, I discovered TikTok. And with TikTok, basically, it has such a good video editor. That was the only reason why I got the app because it made it so easy to make

videos on my phone where I was able to suddenly not just type my tweet jokes and my snarky humor. I could make a video about it. I could add music to it. I could make a dumb face and people seem to like it and it's worked out. And I try to approach things rather from a realistic or educational perspective first and then drop in the humor later. I don't try to lead with the joke, but at the same time, it's always fun to have a joke in there because people like to say like, oh, something funny is happening. I'm getting

ready for it. And it's kind of fun that I'm able to do that a lot more now that people actually expect humor. When I was an employee, which I was, let's be very clear here, terrible at, there is no denying that. It was always a problem for me where the biggest fear that anyone had, start to finish, was that I would open my mouth and say something. And credit where due, my last job was at a large finance company. And at that point, they're under such scrutiny that anytime someone opens their mouth on anything, it has the potential to trigger an SEC investigation, and no one knows what I'm going to say. Yeah, there's a lot of validity in being concerned about that. I felt like I couldn't ever just shoot my mouth off and be me.

And I always had this approach of no company in the world would ever be willing to tolerate my shenanigans. Therefore, I should never look to either do these things in public or later go to be an employee again. You're living proof that it is in fact possible to have both. Yeah. It brings a levity to our very serious industry. Like I used to be in fintech. I know how serious that can be. But then just in tech in general, a lot of tech people take themselves way too seriously. And I understand we're doing awesome work. Some people think they're gods because they can think something and make it into an app. There's ego there. But I feel like making fun of the problems, pointing out the problems in the industry and

kind of just making light of it, making certain tech jokes and making certain concepts humorous as well as educational. I think bringing that approach to things is just really, really effective. And I'm really happy to be on my team, honestly, at Nullify because a bunch of them are just dorks. Pretty much every single meeting, we try to make it a little bit fun. And it makes our meeting so much more enjoyable and productive because we're not just seriously staring at our screens and saying, okay, let's make this decision for our OKRs or anything like that. We have a good time in these meetings while being productive, and it makes for a really nice team dynamic. And

I think there should be more of that in general in tech. One of the things that you have always done with your platform that I am, I guess, slowly warming up to is that you're never mean. In the rare occasions where you punch at something, it's a dynamic, it's not a company, and it's not a person. I have a strong rule of not punching at people, but large companies have always been fair game from my perspective.

And that is a mixed bag. Yours is, how to put this, unrelentingly positive, where it's always about building people up and shining a light on things that used to be confusing and reminding people that they're not alone in being confused by those things. And that's no small thing. Yeah, I appreciate you noticing that. I do try to do that, not only necessarily to be just like, I want to be the positive star in tech, but also because you never know what someone is dealing with. And someone might be pretty mean. And there have been plenty of people who have said some not great things towards me or towards other people. And that cuts deep. And so I do try to avoid those kinds of pointed things. Believe me, it's difficult.

Sometimes I do just want to call people out and be just like, I know what you did to this group of people and I hate it. But you never know what people are going through. And I'd rather just make sure that the people who are doing well are the ones who are uplifted and they get the attention that they need or deserve, rather. I did a little research. I know, I know. Shock. Before I wound up inviting you here.

And it's not just your Twitter account. It's not just your TikToks. It's not just your weekly multi-hour live streaming on Twitch or Twitch or however it's pronounced. I'm an old and that's fine. It's not the platforms. It's the fact that no matter where you are, you're constantly teaching people things. And I want to be clear, that doesn't seem like it's in your job description, is it? No, but it's something that I really care about. I really like teaching in general. A lot of the resources that I provide and the things that I do are me trying to give people things that I didn't have when I was in

the industry, trying to give advice that I wish I had, trying to give resources that I didn't have, because a lot of times people don't know where to look. And if I can be that person that can help them along, some of the greatest joys I've ever felt have been when people say, this blog post that you wrote helped me get my first job. Or this thing that you said was the kick in the pants that I needed to start my own company. Little things like that. I love hearing it because I really just love making people successful and helping them get to that next step in their careers. And that's my passion project. And I try to do that in all the things that I do. There's really something to be said about being

able to reach people who have pain and have needs. I mean, the one crossover talk that I gave that really transformed the way that I saw things was terrible ideas and get, because if there's one thing that unites front end, back end ops, folks, data scientists, et cetera, et cetera, et cetera, it's Git as being the common thing that no one really understands. And by teaching people how to use Git, first it was sort of my backdoor sneaky hack into finally having to teach myself how Git works. But then it was a problem of, okay, now I need to go ahead and find a way to present this in a way that's engaging and fun and doesn't require being deep into the weeds. And I was invited to speak at Front End Conference Zurich, which was just a surreal experience. Incredibly nice people, very gracious community. And I'm sitting there for the first half of the day watching the talks, and it's a Front End Conference.

And everyone's slides are gorgeous. And this was before I started having a designer help me with my slides. So it was always a black Helvetica text on a white background. And mine looked like crap. And I only had a few hours until my talk. So what do I do? Because I'm feeling incredibly out of place. I changed the font on everything to Comic Sans and leaned in on that.

And it definitely got a reaction. The talk was great. It really did work. And it was fun. And in hindsight, I don't think I'd do it again because I keep hearing rumors that I can't quite confirm, but it's significant enough that I want to be clear

that Comic Sans is apparently super accessible when it comes to people with dyslexia. And I don't want to crap on something like that. It's not funny when it makes people feel out of place. Yeah. These kinds of things, it's delicate to talk about because you have to figure out, okay, how can I make this accessible to as many people as possible? How can I communicate this information? And then meanwhile, when you are this person, that just means your DMs are very, very full of people

who want one-on-one help. And you have to figure out how to scale yourself and how can you make these statements that are helpful for as many people as possible, provide as many resources as you can, and hope that people don't feel bad when you can't answer every DM that comes your way. And yeah, there's a delicacy

when it comes to all the different things that you could be poking fun at or saying you don't like and stuff. And my answer to pretty much everything has turned into just, it depends. Whenever people are just like, what's the best framework to learn? I'm kind of like, it depends on what you want to build. Because first of all, that's true. But second of all, there's enough opinions out there in the world saying like, this is the worst font. This is the best font. This is the worst way to build web apps. This is the only way to build web apps. I mean, you hear this constantly throughout the tech industry. And I think if more people said it depends, we would be a much happier industry in general. 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. I really think that you're right, and I think the hardest part is getting there. You say that the answer to what framework should I pick is, well, it depends. And that's very true. The counter argument is that it's also supremely unhelpful. It's, I'm looking to build a web page that has a form on it. And when I click a button, it does a thing. And at that point, it feels like it's, well, there are an entire field of yaks before you, all of whom need to be shaved before

the form will exist. And it just becomes this, oh my God, are you just trying to tell me not to bother? And no, that's never the response. But having a blessed, I guess, golden path of where you can focus to get something done and then where it makes sense to deviate gets signaled. I like that approach, but people are for reason, worried about being overly prescriptive. And I get that, too. Yeah, there's a balance there. But I should append to my previous answer. I say it depends. But here's how I would do it. And that gives some direction. Some people might be just like, oh, well, I don't want to use React or something like that. And I'm like, well, then, unfortunately, I can't help you. You're on your that. And I'm like, well, then, unfortunately, I can't help you.

You're on your own. But I'm sure it'll work for you. Just kind of roll with it from there because, yeah, you never know. Yeah, but I've never liked the questions that the asker already has an answer they want to hear and they're looking for almost confirmation bias. Yeah. Yeah, at that point, why bother? Just say, this is what I'm thinking about doing.

Please tell me it's not ridiculous. And if it is, people will generally try and be kinder about it, but we'll see. Yeah. A lot of times, too, and I hate to say it, but a lot of times, too, people come in with such an arrogant air. And oftentimes, that's either because they're insecure about something or they don't have a lot of experience in something. But unfortunately, that's

almost always the case. And there have been times on my stream, for example, where someone will say, if you use this framework, it will solve 99% of your problems. And I'm kind of like, will it though? And I don't want to just straight up say you're wrong, but I kind of have to keep asking questions and try to be just like, try to be one of those teachers where I'm saying, okay, I'm going to ask you these questions. Are you sure that this edge case is in that 1%? I think you're being a little bold here and not trying to specifically humble them

and know that they are wrong, but also turn it into a moment where you have to learn that nothing really solves 99% of your problems. And whenever someone says something like that, I always assume conflict of interest somewhere. It's like, what this framework you're suggesting, I don't know, just so happened to integrate super well with the thing your company does?

Huh, how about that? Whenever someone can identify an area that they're offering is crap in, I assume that they're effectively evangelizing something with almost a religious fervor and aren't really people to take overly seriously. I have technologies that I adore, but if I can't articulate use cases in which they would be wildly inappropriate, then I'm not really being fair either to the person I'm talking to or honestly the product itself.

Exactly. There's always cons. Like, yes, there might be a lot of pros and the pros may outweigh the cons, but you have to be able to speak to those if you're going to give a credible answer to any sort of recommendation like that. So let's talk about platforms a little bit. You have a newsletter, which I'm a fan of and will of course link in the show notes. You stream on Twitch, which is similar to a podcast, only it's video and it's live. So unlike here where we can edit heavily, if someone winds up breaking down crying, like I tend to every third episode. Yeah. We should cut out those farts earlier, by the way.

Oh yeah. Oh, we've already edited that out. We're already set. We do this in real time here, but you have to do things like that in real time on Twitch. As soon as something happens on camera, it's done. It's out there. And it's a very different experience. You do it also on hard mode, where you and I are having a conversation back and forth. Whereas when you do Twitch, you're doing it solo. You are effectively in an empty room, or what appears to be one anyway, and you're talking to the camera and there's no other audio other than you and a lovely backing track, there's no conversation. You're monologuing for the duration of that. People mention things in the chat with a slight delay, and then you can take action based upon that. But that feels like an awful lot of pressure to wind up filling the dead air while you're waiting for the next question to come in.

Yeah, it's something that has taken practice. And I think it's something that because I have done quite a bit of public speaking, I've done a bunch of teaching, I am comfortable with the silence. And the music also helps that a lot. Some people, when they're about to live stream or they're learning how to live stream for the first time, they kind of panic at the silence. They're like, oh my gosh, how am I going to fill it? Meanwhile, with me, I'm just like, ah, nobody's asking a question. I can take a drink of water now and try to keep it as natural as possible. I try to make this stream, I started doing it more regularly during the pandemic as something that's kind of just co-working and kind of having something in the background, because usually when people are in the office or working at a cafe or something,

you get to hear interesting conversations and a voice and you can chime in on occasion. And I try to make that what the stream is where people don't have to be paying excessive attention, but I open it up where you can ask me pretty much anything and I will give you an honest answer and just try to make it a space where people can

not worry about asking a stupid question because I think that none of these questions, whether it's about tech jobs or certain frameworks or opinions about things, none of them are dumb. Sometimes it's just people who aren't sure what the answer should be or they aren't sure if their biases are correct or anything like that. And I really enjoy the live streaming because it gives me a connection with the community that I can help teach further. And then as they ask questions, I can take that and run with it and build a demo, help them come up with project ideas, show how I would build something, something like that. Well, there's an incredible authenticity to what you do. And that is, I think, one of the most impressive aspects of what you do.

I've never yet seen you make someone feel like a jerk for asking a question. I've also never once seen you claim you knew how something worked when you didn't. You point people at resources to find the right answer. You are constantly gracious. You're always incredibly authentic. And it's become really easy to consume your materials because I know you're not going to make it up if you don't know the answer. And that's no small thing. Thank you. I appreciate that. It's not easy, but it's very fun. And I do hope that it makes people more comfortable with the concept of streaming coding and any of that. You also seem to have some of the same problems that I do, specifically, not the jerk problems,

that's unique to me, but the problem in the context of answering a difficult question, namely, so what is it you do? Because as mentioned, you have the newsletter, you have the job, you have the Twitch stream, you have the TikTok, you have the Twitter, you do courses from time to time, if I'm not mistaken as well. Yes, I do. I have a few online courses on Scrimba, on Udemy, on Skillshare, on O'Reilly. I like teaching JavaScript and showing people how React works and stuff under the hood. And you're right, it's hard to explain what I do sometimes. And that's the hard part is when someone asks, so what do you do? What's your default answer? I have created this tagline that I'm kind of just sticking with and we'll see how long it lasts me.

But I say I make memes, dreams and software. And I just kind of leave it at that. And people will be like, OK, Cassidy, shut up. And I leave it at that. But yeah, if someone asks me what I do, I kind of leave it at that and people will be like, okay, Cassidy, shut up. And I leave it at that. But yeah, if someone asks me what I do, I kind of start with I code. And then if they press further, I'll be like, well, I teach people how to code and I show people how to code best. And usually that's where my grandpa stops asking. He's just like, okay, it's that computer stuff. If it's a tech person, I start diving more and more into all of the things.

And it's very hard to explain. I wish there were a word for trying to make people laugh and teach and build things and stuff, but I don't know what that word would be. Yeah, it's a hard problem. My answer has always been to spin it depending upon who I'm talking to. True. If it's at a neighborhood barbecue and people ask what I do, I try and make myself sound like some sort of esoteric accountant because if I say even slightly incorrectly what I do, suddenly people are asking

me about their printers. And honestly, how do I fix a printer? I throw it away and I buy a new one, but that's not really helpful to people who are looking for actual help. So it's a matter of aligning what I do with people's expectations. I make fun of Amazon for a living is technically accurate, but boy, does that get some strange looks. Yeah, it definitely, definitely varies on the audience. If I'm, for example, going to some kind of church barbecue, I just say, oh, I'm a software engineer. Questions stop there, and I leave it at that. If I'm at a tech meetup, I'll be just say, oh, I'm a software engineer. Questions stop there, and I leave it at that. If I'm at a tech meetup, I'll be just like, oh, well, I specialize in front-end things, but I also do some dev advocacy and stuff, and I can generally stop there. But you're right.

Depending on the audience, I have to be careful because I don't want people to just ask me to fix their Wi-Fi all the time, even though they do anyway. And to them, I usually say, oh, I build computer things. I don't know how to work them though. And I leave it at that. Oh, hey, I'm building a computer too. Can you recommend some parts? Absolutely not. Nope. I don't know what I'm doing there. Yeah, I kind of just Google and accept whatever I'm told. Yeah. And the other side of it too is if you're not direct enough and say, working with technology, people tend to think that you're being condescending. It's like, oh, I do some cloud computing finance work. And they're like, oh, so what, you fix an AWS bill? That's it. Yeah, exactly. You could just say that, you know, well, yeah, to you, but there's a whole world of people out there to whom that sounds like I'm blowing them off with geek speak.

Yeah, yeah, exactly. And it's almost harder if it's a mixed group of people, too, because sometimes people who are in tech, but I don't know the rest of the people, they might say, oh, she makes text jokes on Twitter. And they'll say, oh, really? Say something funny. I'm like, oh, I don't know how. It's not that easy. It's interesting trying to figure out how you define that for other people. Oh, you're a comedian. Great. Make me laugh. Oh, God. Please, no. Yeah, that's the best setup for a good belly laugh is command performance of be funny when you weren't expecting it. Yeah. Oh, can't handle it.

I just freeze up and give up. Again, these are not common problems. One thing that I did find incredibly funny was that when we started talking, we talked about things that we had encountered as you said, this is ridiculous and no one ever does it. And then I responded with a screenshot of me doing the exact same thing, which is first, hilarious because I've never seen anyone else do that. And two, a bit of product feedback, perhaps for the team at Twitter. It really is. Yeah. When I found out you did that too, I laughed so hard because so many times people have been just like, you know, there's tools for this. You don't have to just write a number and a DM to yourself on Slack. But this is the tool that works for me. It's quick. It's done. I can see generally how things are going. Someday I

should put it in a graph of some time, but eh. But it's always forward looking too, because all those tools don't go back in time to your account's inception and, oh, you had this person follow you at this time. There's no historical record there. Yeah, it is totally product feedback. I have no idea how I'd be able to say, hey, look at this DM. Fix this problem to a specific Twitter person. But, eh.

Four years ago, I had 1,500 Twitter followers, and it had taken me seven years to do it. And people ask, what were the big inflection points when you wound up getting significant audience boosts? And if I had dates on that stuff, I could absolutely do some correlation like, oh, there's reInvent. Oh, that's where I was visibly thrown out of a bar on the news. Kidding. But being able to tie it to things like that would be helpful, but it's happened. It's gone. I just have to basically try and remember and assume I'm somewhat close to accurate. Yeah. And I don't do it consistently, mind you. There's definitely weeks where I just have to basically try and remember and assume I'm somewhat close to accurate. Yeah. And I don't do it consistently, mind you. There's definitely weeks where I just totally miss it.

But sometimes, for example, if I'm about to tweet something funny, I'll mark it and then make the post and just see where it goes. And it's more just interesting for me. I will probably never share this with people besides you when we talk about our strategies. But yeah, I mean, I guess that also speaks to building what's best for you is often the best solution. Yeah, and it changes too. And part of the reason that these conversations tend to happen behind closed doors, because the easy naive response is, oh, that'd be super interesting to watch and see how those problems get addressed. But so much of what we're doing and how we approach it

is not helpful until you're at a certain point of scale. If you have 200 Twitter followers, for example, frankly, you're making better life choices than either one of us are. But the things that we are concerned with and have to pay attention to just don't apply in any meaningful way. Conversely, if you have a small following Twitter account, that is a freedom that we don't really have. Because past a certain point, as I'm sure you can attest, you can't say that you like waffles without getting someone asking, well, what's the problem you have with pancakes? And then insulting you and following you around until you block them. It's so true. I was talking with someone about this yesterday because

it's not like I ever say things that are particularly controversial or anything. But word choice matters so much more when there are a lot of eyes on you. And so many times I'll make a joke and then I have to do a follow-up tweet saying, this is a joke. Please don't tell me how to exit Vim or something like that because, oh my word, people just will never take things the right way in mass. No. I have learned there is no possible way to say something without it being misinterpreted. And I try and wind up turning it back around, and every time I read something, I do my best to assume good faith. I don't always succeed. And sometimes I'd look like a fool for basically taking a troll seriously. But I'd rather that than the alternative. If someone asks a naive question,

and I assume that they're just being a jerk and block them, or I mock them. Because the failure mode of me looking like I got hoodwinked is better than making someone else feel crappy. Right, exactly. I remember a while ago, this was like a couple years ago, there was someone who was not being nice to me in the mentions. And I was just like, why would you respond to me like this? Just leave me alone. I said something like that. And it was a lesson for me and for them where they ended up getting really upset with me and yelling at me in the DMs because they were getting all of this negative commentary on their end for being the mean one. And then I end up looking like a jerk because I ended up spotlighting this person who might have been having a bad day. You never know. And the algorithm works against you when

you have a lot of eyes who are looking at what you're tweeting about. And so, yeah, whenever stuff like that happens, you kind of just have to ignore it and learn to pick your battles, I guess. Oh yeah. And I assume that's what's going on now. I imagine that one day the AWS Twitter account is going to finally snap and just quote tweet me with some incredible roast and there will be no coming back from that for me.

I look forward to that day. It would be so nice to see that come out of them. I worry I may die before it gets there, but hope springs eternal. Cassidy, thank you so much for taking the time to speak with me. If people want to hear more about what you have to say, as they damn well should, where can they find you? Take a deep breath, run through the list. All right, they can find me on all sorts of platforms. You could look up Cassidy Williams, and you'll find either me or a Scooby-Doo character, and I'm not the Scooby-Doo character.

Or you could look up Cassidoo, C-A-S-S-I-D-O-O. Cassidoo.co is my website. Cassidoo on Twitter, on GitHub, on CodePen, on LinkedIn, all those platforms, that's where you can find me. And we will put links to all of those things in the show notes, because honestly, that's someone else's job and I am going to hurl that mess to them. Perfect. Thank you so much for taking the time to speak with me. I really appreciate

that. It was really fun. It was good chatting with you too. Really was. Cassidy Williams, Principal Developer Experience Engineer at Netlify. 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've hated this podcast, please leave a five-star review on your podcast platform of choice, along with an aggressive comment encouraging me to fight you on Twitch, however that might work. If your AWS bill keeps rising and your blood pressure is doing the same, then you need the Duck Bill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duck Bill Group works for you, not AWS.

We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started. This has been a HumblePod production. Stay humble.