Podcast appearances and mentions of cassidy williams

This interview was recorded for GOTO Unscripted.https://gotopia.techRead the full transcription of this interview here:https://gotopia.tech/articles/330Cassidy Williams - Senior Director of Developer Advocacy at GitHub Ben Hong - Staff Developer Experience Engineer at Pandan Studio  RESOURCESCassidyhttps://twitter.com/cassidoohttps://www.linkedin.com/in/cassidoohttps://github.com/cassidoohttps://cassidoo.coBenhttps://x.com/bencodezenhttps://m.webtoo.ls/@bencodezenhttps://github.com/bencodezenhttps://www.linkedin.com/in/bencodezenhttps://www.bencodezen.ioLinkshttps://obsidian.mdhttps://www.notion.sohttps://bear.apphttps://www.keyboardmaestro.comhttps://github.com/features/copilothttps://claude.aihttps://www.cursor.comhttps://www.tabnine.comDESCRIPTIONCassidy Williams and Ben Hong explore the intersection of aesthetics, functionality, and AI in the world of coding. They begin by examining how the design and feel of tools, from digital typewriters to customized keyboards, can significantly impact productivity and enjoyment. As they delve into AI's growing role, they assess various tools like GitHub Copilot, Claude.ai, and others, emphasizing how these technologies complement rather than replace human creativity.Their conversation highlights the balance between leveraging AI for efficiency and maintaining personal touch and critical thinking in coding. They argue that while AI advances, the human element remains crucial in driving innovation and crafting meaningful work. [...]RECOMMENDED BOOKSTaylor Royce • The 2024 Developer Productivity Guide • https://amzn.to/3XNAjqzUnni Panicker • The Software Developer's Guide to ChatGP • https://amzn.to/3MSpoWwAlex Castrounis • AI for People and Business • https://amzn.to/3NYKKToPhil Winder • Reinforcement Learning • https://amzn.to/3t1S1VZBlueskyTwitterInstagramLinkedInFacebookCHANNEL MEMBERSHIP BONUSJoin this channel to get early access to videos & other perks:https://www.youtube.com/channel/UCs_tLP3AiwYKwdUHpltJPuA/joinLooking for a unique learning experience?Attend the next GOTO conference near you! Get your ticket: gotopia.techSUBSCRIBE TO OUR YOUTUBE CHANNEL - new videos posted daily!

Wes and Scott talk with Cassidy Williams and Harald Kirschner about exciting new features in VS Code and GitHub Copilot, including custom instructions, UI/UX improvements, and the future of AI and Copilot within different editors. Show Notes 00:00 Welcome to Syntax! 00:32 Cassidy's keynote at GitHub Universe 03:23 New Copilot features 04:55 Use cases for prompt engineering 09:20 UI and UX enhancements 19:18 Copilot Extensions 20:38 Brought to you by Sentry.io 21:26 Multi-line suggestions? 27:00 How do you develop new ideas in this space? GitHub Next 35:42 Copilot in Xcode GitHub Copilot code completion in Xcode is now available in public preview 39:16 VS Code experimental features @code Hit us up on Socials! Syntax: X Instagram Tiktok LinkedIn Threads Wes: X Instagram Tiktok LinkedIn Threads Scott: X Instagram Tiktok LinkedIn Threads Randy: X Instagram YouTube Threads

On this Screaming in the Cloud replay, we're looking back to our conversation with Cassidy Williams, a Senior Director of Developer Advocacy at GitHub and the co-founder and chief product officer of Cosynd, Inc. Prior to these positions, she worked as the principal developer experience engineer at Netlify, an instructor and senior engineer at React Training, director of outreach at cKeys, a senior software engineer at CodePen, head of developer voice programs at Amazon, and a software engineer at Venmo, among other positions. Join Corey and Cassidy as they reflect on what Netlify is and what a developer experience engineer does, how JavaScript started off as a toy language and why everything that can be built with JavaScript will be moving forward, the benefits of using low-code development tools, how discovering TikTok helped Cassidy drum up a major following on social media, how Cassidy's humor is never directed at people or organizations and why that's the case, the differences between recording a podcast and live streaming on Twitch from the speaker's point of view, and more.Show Highlights(0:00) Intro(0:22) Backblaze sponsor read(0:49) What is Netlify and its role of a principal developer experience engineer(2:50) Is JavaScript the future?(7:46) Using low-code tools for web development(12:12) Having a goofy internet presence in a serious field(17:23) Social platforms as a means to teach(24:50) Twitch streaming and its inherent challenges(28:16) Cassidy's online coursework and how she answers, “So, what do you do?”(32:12) Unique ways of tracking Twitter followers(37:15) Where you can find more from CassidyAbout Cassidy WilliamsCassidy is a Senior Director of Developer Advocacy at GitHub. She's worked for several other places, including Netlify, 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 was 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.LinksTikTok: 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/cassidooOriginal Episodehttps://www.lastweekinaws.com/podcast/screaming-in-the-cloud/memes-streams-software-with-cassidy-williams/SponsorBackblaze: https://www.backblaze.com/ 

How do you build lightning-fast websites with Astro and React?In this episode, Nikolay teams up with Cassidy Williams, a developer advocate and educator with a flair for making complex concepts fun and accessible. Watch as Cassidy attempts to build an Astro website in 60 seconds, integrates React for interactivity, and shares tips on optimizing performance. Along the way, she shares her favorite productivity tools, discusses the power of community, and offers invaluable career advice for developers. ❓What did you think of the show? Leave your anonymous feedback:https://forms.gle/Df5sDABiNMQn4YSj7 CONNECT WITH CASSIDY WILLIAMS

In this episode of the Maintainable Software Podcast, Robby sits down with Cassidy Williams, Developer Advocate at GitHub, to explore the dynamic nature of a tech career, the delicate balance between clever code and maintainability, and the evolving trends in software development.Cassidy begins by discussing what makes software truly maintainable—starting with the ease of onboarding for new developers. She emphasizes the importance of clear documentation and warns against the pitfalls of writing overly clever code that might be difficult to maintain in the future.They then delve into the challenges of joining an existing codebase and managing technical debt. Cassidy shares her experiences, noting how codebases often start pristine but become more cumbersome as projects evolve and pivot.The Importance of Onboarding: Cassidy explains how fast someone can jump in and start working on code as a key indicator of well-maintained software.[00:10:21] Balancing Cleverness and Maintainability: Cassidy elaborates on why writing clever code can be a double-edged sword when it comes to long-term maintainability.[00:16:00] Navigating Career Pivots: Cassidy reflects on her own career journey, likening it to a "career jungle gym" where paths are non-linear and require thoughtful decision-making.[00:18:36] Working at Netlify: Cassidy shares her experience with upgrading a router within an existing codebase, highlighting the importance of collaboration and bringing in external expertise.[00:24:00] Local-First Software: Robby and Cassidy explore the trend of local-first software, emphasizing the benefits of data ownership and the ability to work offline.[00:26:30] Developer Wishlists: Cassidy suggests creating personal and communal wishlists for addressing technical debt, fostering a collaborative approach to maintaining software.[00:31:50] Jumbile - Cassidy's Side Project: Cassidy introduces her word game, Jumbile, detailing its development process and the unique challenges she faced.Cassidy also discusses her love for Brandon Sanderson's books, specifically the Mistborn trilogy, and the importance of owning your data in today's digital landscape.Key Takeaways:Maintainable software allows new developers to quickly contribute, thanks to clear documentation and readable code.Clever code can be a joy to write but may lead to maintenance challenges down the line.A career in tech often resembles a jungle gym, requiring flexibility and thoughtful navigation.Involving open-source maintainers in large codebase changes can provide invaluable insights and streamline the process.Local-first software is gaining traction, offering benefits in data ownership and offline functionality.Resources Mentioned:Cassidy's WebsiteCassidy on LinkedInCassidy on TwitterJumbile - Word GameReact RouterMistborn Trilogy by Brandon SandersonThanks to Our Sponsor!Turn hours of debugging into just minutes! AppSignal is a performance monitoring and error-tracking tool designed for Ruby, Elixir, Python, Node.js, Javascript, and other frameworks.It offers six powerful features with one simple interface, providing developers with real-time insights into the performance and health of web applications.Keep your coding cool and error-free, one line at a time! Check them out! Subscribe to Maintainable on:Apple PodcastsSpotifyOr search "Maintainable" wherever you stream your podcasts.Keep up to date with the Maintainable Podcast by joining the newsletter.

In this month's panel episode, we talk to Cassidy Williams, Michael Chan, and Atila Fassina about why web components are having a moment, mounting frustrations with React, and our guests' hottest takes on web development. Links Cassidy Williams https://cassidoo.co https://github.com/cassidoo https://twitter.com/cassidoo https://codepen.io/cassidoo https://www.linkedin.com/in/cassidoo https://www.patreon.com/cassidoo Michael Chan https://twitter.com/chantastic https://chan.dev/ https://www.youtube.com/@chantastic https://github.com/chantastic https://www.linkedin.com/in/chantastic Atila Fassina https://twitter.com/AtilaFassina https://atila.io/ https://github.com/atilafassina https://www.linkedin.com/in/atilafassina https://www.youtube.com/AtilaIO https://mas.to/@atila We want to hear from you! How did you find us? Did you see us on Twitter? In a newsletter? Or maybe we were recommended by a friend? Let us know by sending an email to our producer, Emily, at emily.kochanekketner@logrocket.com (mailto:emily.kochanekketner@logrocket.com), or tweet at us at PodRocketPod (https://twitter.com/PodRocketpod). Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form (https://podrocket.logrocket.com/get-podrocket-stickers), and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket combines frontend monitoring, product analytics, and session replay to help software teams deliver the ideal product experience. Try LogRocket for free today. (https://logrocket.com/signup/?pdr) Special Guests: Atila Fassina, Cassidy Williams, and Michael Chan.

Today, we have Cassidy Williams, CTO of Contenda. Contenda unbelievably started as a sticker distribution platform that pivoted into a product that converts podcasts and videos into various other forms of written content via AI. But in our conversation with Cassidy today, we talk about their latest pivot to a product called Brainstory, which is an AI based brainstorming application. We talked through some of their product choices around focusing on speech as the main input mechanism, some of the technical challenges they've had to overcome, how they're using multiple AI models in the backend to make all this magic happen, and where they're seeing initial product traction. If you're a founder or thinking of starting a company, we think you'll find this conversation super interesting. Check Out Brainstory: https://www.brainstory.ai/ Software Huddle: https://twitter.com/SoftwareHuddle Cassidy: https://twitter.com/cassidoo Sean: https://twitter.com/seanfalconer

In this week's roundup, hear snippets of our discussions about how Bun is creating runtime competition, what CSS containers actually are, and how to deal with complex UIs. Links Apple State of CSS, Bun 1.0, and v0: https://apple.co/3tlDSr2 CSS containers with Miriam Suzanne: https://apple.co/3PCMWiQ Designing for complex UIs with Vitaly Friedman: https://apple.co/48x1rNO Spotify State of CSS, Bun 1.0, and v0: https://spoti.fi/3Pzw9ND CSS containers with Miriam Suzanne: https://spoti.fi/3ZynWOk Designing for complex UIs with Vitaly Friedman: https://spoti.fi/3PvCOsf Google State of CSS, Bun 1.0, and v0: https://bit.ly/3PBHb51 CSS containers with Miriam Suzanne: https://bit.ly/457DnOQ Designing for complex UIs with Vitaly Friedman: https://bit.ly/460SJFY We want to hear from you! How did you find us? Did you see us on Twitter? In a newsletter? Or maybe we were recommended by a friend? Let us know by sending an email to our producer, Emily, at emily.kochanekketner@logrocket.com (mailto:emily.kochanekketner@logrocket.com), or tweet at us at PodRocketPod (https://twitter.com/PodRocketpod). Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form (https://podrocket.logrocket.com/get-podrocket-stickers), and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket combines frontend monitoring, product analytics, and session replay to help software teams deliver the ideal product experience. Try LogRocket for free today. (https://logrocket.com/signup/?pdr) Special Guests: Cassidy Williams, Chris Bautista, Mia Suzanne, and Vitaly Friedman.

Back with our monthly panel episode, we discuss the State of CSS 2023 results, the Bun 1.0 release, if Vercel's v0 is all hype, and more with panelists Cassidy Williams, Chris Bautista, Paul Mikulskis, and Noel Minchow. Links Cassidy Williams https://twitter.com/cassidoo https://cassidoo.co https://github.com/cassidoo https://www.linkedin.com/in/cassidoo Chris Bautista https://twitter.com/trashhdev https://m.twitch.tv/trashdev/home https://www.youtube.com/@trash_dev https://github.com/bautistaaa Paul Mikulskis https://www.linkedin.com/in/paul-mikulskis-37a50b4a Noel Minchow https://www.linkedin.com/in/noel-minchow https://bsky.app/profile/noel.minc.how Related resources https://2023.stateofcss.com/en-US https://twitter.com/jaredpalmer/status/1702356555218506070 https://v0.dev/faq https://twitter.com/ThePrimeagen/status/1702733449545519497 We want to hear from you! How did you find us? Did you see us on Twitter? In a newsletter? Or maybe we were recommended by a friend? Let us know by sending an email to our producer, Emily, at emily.kochanekketner@logrocket.com (emily.kochanekketner@logrocket.com), or tweet at us at PodRocketPod (https://twitter.com/PodRocketpod). Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form (https://podrocket.logrocket.com/get-podrocket-stickers), and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket combines frontend monitoring, product analytics, and session replay to help software teams deliver the ideal product experience. Try LogRocket for free today. (https://logrocket.com/signup/?pdr) Special Guests: Cassidy Williams and Chris Bautista.

What does it take to get executives to approve fair pay? Cassidy Williams, the CTO at Contenda, had to do exactly that at a previous job. Learn how Cassidy used every trick in the book - from "brag docs" to forging alliances - to close an unfair pay gap. She explains the mental shifts she had to make, and what she'd do differently next time. Cassidy discusses: Creating "brag docs" to prove your value Managing during hypergrowth The calm of profitable “lifestyle” companies versus those backed by venture. Her top advice for advocates, leaders, and especially parents in tech Get the inside scoop on pay equity, company growth stages, parenting policies, and more on this episode with Contenda CTO Cassidy Williams. Cassidy's links Website LinkedIn Newsletter Twitter

It's gardening season! Stephanie swaps seeds with friends and talks about her Chicago garden. Joël recently started experimenting with a dedicated bookmark manager. They discuss the aspirational (and sometimes dogmatic) sides of TDD and explore when to test: first or after. How does that affect the tests? How does that affect the code? How does that affect workflow? Are you a "better" programmer because you 100% TDD? This episode is brought to you by Airbrake (https://airbrake.io/?utm_campaign=Q3_2022%3A%20Bike%20Shed%20Podcast%20Ad&utm_source=Bike%20Shed&utm_medium=website). Visit Frictionless error monitoring and performance insight for your app stack. Cassidy William's Productivity tools (https://dev.to/cassidoo/the-productivity-apps-i-use-in-2023-3m8l) raindrop.io Bookmark Manager (https://raindrop.io/) Simplifying Tests by Extracting Side-Effects (https://thoughtbot.com/blog/simplify-tests-by-extracting-side-effects) Transcript: JOËL: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Joël Quenneville. STEPHANIE: And I'm Stephanie Minn. And together, we're here to share a bit of what we've learned along the way. JOËL: So, Stephanie, what is new in your world? STEPHANIE: It's gardening season here in Chicago. So right now, it is like mid-April as we're recording this, and we are just starting to get some warm weather. And this is usually the time that I do my garden planning for the season. And the other week, I went over to a friend's place, and we did a bit of a seed share. So we just each have collected fruit and vegetable seeds and herbs and all that. And a really fun way to collect more things to grow is to share with your friends. Seeds are super cheap, but I feel like you could just have like an infinite amount for all of the things that you might want to grow. And so it's really nice to be able to, yes, spread that gardening love around and share with your friends. JOËL: I'm imagining something like people trading collectible trading cards but the plant version. STEPHANIE: Yeah, exactly. The fun thing that we did, my friend and I, because, you know, you usually get a little envelope with between 10 and 50 or more seeds, and they're super tiny. Some of them are really teeny tiny, like with broccoli, for example, it's like I can't even explain. It's less than a millimeter, I swear. It's very easy to just lose them, so you want to keep them contained. But because we are sharing, we don't have a second envelope for the other person to take home with them. And so we actually made our own little envelopes with some origami paper that she had. And we folded it and stapled it and made it very cute. And so I came home with a bunch of these very adorable handmade envelopes with all of my new seeds. JOËL: Are you mostly doing vegetables, or are these flowers? STEPHANIE: Yeah, so we mostly focus on vegetables for our garden. And we do like to sprinkle some flower seeds in our yard. But that is more just like throw some seeds out there, and whatever happens to them happens. But with the vegetables, we put a little bit more effort because we usually try to have a good yield. So in past years, that has meant starting seeds indoors because, in Chicago, we have a shorter growing season than some warmer climate places. And the late summer vegetables like tomatoes, peppers those usually take a little bit longer. So if you want to get a good yield, you might want to start them inside a little early before it's warm enough for them to go outside. JOËL: So, do you have a garden plot out in your yard, or do you have a community garden plot? How does that work? STEPHANIE: I am really grateful to have a bit of backyard space. And we have three raised beds that we built that cover...I think each one is 3 feet by 10 feet, so quite a good amount of space. Yeah, we're able to grow a lot of food. Our highlights include shishito peppers. That's one that I really like to grow myself a lot because I usually don't see them in stores as frequently. We grow really great eggplants. Tomatoes, obviously, is a pretty popular beginner-friendly vegetable plant. And we like to grow a lot because then we can process it all and can some of it so we can have nice tomato sauce that's homegrown year round. JOËL: Hmm, sounds delicious. Do you experiment with the different varieties? STEPHANIE: We do. That's also a way that the seed sharing is really helpful because maybe I'll get some varieties of certain vegetables like cucumbers or whatever, but maybe my friend has a different kind. And I think we try to do a mix of growing the varieties that we know we like and then experimenting with some ones that are new to us. JOËL: It's hard to beat fresh vegetables in the summer. STEPHANIE: Yeah. I'm very excited, especially because during the fall and winter seasons here in Chicago, our local food is a little less exciting. It still can be good, but it's been a lot of root vegetables and the like when we try to eat seasonally in the other season. So I'm really looking forward to stuff that's just juicy and fresh, and it's just one of my biggest joys during the summer. What about you, Joël, what's new in your world? JOËL: I've recently started experimenting with a dedicated bookmark manager. This is not because I have been to too many bookstores and have all the free bookmarks they give you. These are the digital bookmarks to websites, and I've been really bad at managing those. I mostly just memorize the keywords I need to Google to get access to that website, which is a terrible way of doing things. And then I've got a mix of a few different browsers, which I don't sync, and have a couple of bookmarks. I use a little bit of Pocket, which is a tool by Mozilla. It's all right, but the search capabilities are not very good. So sometimes I'll know it's in there, but I can't find it. STEPHANIE: I'm so glad you brought up this topic because I am in a similar boat where I read a lot of things on the internet and have just thrown them all into my top-level bookmarks hierarchy. And that has not really been working for me, either. So I'm really curious to find out how you've been solving this problem. JOËL: So recently, I volunteered to be a mentor for first-time speakers at the upcoming RailsConf in Atlanta. And someone was asking me about designing slides, and we were talking a little bit about when should you use maybe a bulleted list on a slide versus when there are other options available. I knew that I had read years ago a fantastic resource on slide design. But try as I could, I could not Google this and get the page that I was looking for. This was shared to me by somebody else as part of a conference preparation group years ago, and so I reached out to this person. I was like, "Hey, so do you happen to remember that link you shared with me five years ago?" And this person says, "I do remember it. I don't have the link either." STEPHANIE: I've literally been in this exact same situation where I remembered that there was an article that I read, and I remembered exactly who shared it with me or who I talked about it with, and when I couldn't find it, trying to reach out to them and also not being able to find it through them. JOËL: So the story ends well because I was able to log into an old Slack group... STEPHANIE: Wow. JOËL: That had been created for the speakers at this conference and dig through the history. And luckily, I still had access to the group. I was still in that private channel for the speakers. And I found the link, and I was able to share it with others. So that was great. But then I started thinking; I can't keep living this way. I need something better. STEPHANIE: It's true. Even though we are expert Googlers as developers, sometimes the search just doesn't get you the thing you're looking for. JOËL: So, about this time, I'm scrolling Twitter as one does. And I saw a tweet from Cassidy Williams talking about some of the productivity tools that she's been using this year did a longer article about it. And I started reading it, and a tool that she mentioned there is Raindrop.io, which is an all-in-one bookmark manager. And I'm like, oh, that is exactly, I think, the missing piece of technology in my life right now. So I went up and signed up for it, and so far, it's been pretty good. I'm experimenting with it. But I've consolidated a lot of the links that were in my head or in some of these other places, put it in there, categorized them a little bit, tagged them. And hopefully, this becomes a better way so that when I want to reference a link for someone else either in a conversation or as a resource or even for myself, maybe when I'm writing an article, I'm like, oh, I know I read something that would act as a good resource here. I can go to Raindrop and get that article without any of these other shenanigans I had to do this time. STEPHANIE: Amazing. What is special about Raindrop as opposed to just your native browser bookmark capabilities? JOËL: It has some deeper structuring capabilities in terms of not everything has to be hierarchical. It has tags as well as categories. And I think most importantly, for me, it has search, which seems to be pretty good at surfacing things. It also has some somewhat smart capabilities where it will automatically figure out if the thing that you've linked is an article, or a document, or a video, something like that. So you can filter by these inferred types as well. It has the ability to sync across devices, which browsers can do if you're signed up for them. STEPHANIE: Nice. I like that it has that search functionality that you mentioned because I think I'm definitely in the boat of just scrolling through all of my untagged, unorganized bookmarks. And it's really tough to find what I'm looking for, especially if the meta title also doesn't quite tell me exactly the keywords that I'm needing to be scanning for in that moment. So I will definitely have to give it a try. JOËL: I believe you can get full-text search if you pay for the premium version (I'm currently trying the free version.), which in theory, could mean that it searches the contents of the article. It's not clear with that. But I do know they save a snapshot of the text of the article. STEPHANIE: That's really interesting because then it's almost like a search engine but scoped to the things that you have saved. JOËL: Yes. STEPHANIE: Nice. JOËL: I'll see how that goes, and maybe six months from now, I can talk a little bit about what the experience has been using that. STEPHANIE: Yeah, six months from now, you can tell us all about how you have no issues or qualms with how you've been managing bookmarks because everything is working perfectly well for you. [laughs] JOËL: JK, I've dropped this whole bookmark thing. STEPHANIE: That's true. That's also the flip side of trying out a new tool, [laughs], isn't it? MID-ROLL AD: Debugging errors can be a developer's worst nightmare...but it doesn't have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half. So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking! Airbrake's debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted. In addition to stellar error monitoring, Airbrake's lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction. Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality. Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back. Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today! STEPHANIE: So our topic for today is something that we've had in our topic backlog for a while, and I'm excited to talk about it. It's TDD, which I think is a very well-known, potentially controversial topic of discussion in the world of software development. And specifically, we wanted to talk about when TDD is useful and when you actually might also have some value in writing tests afterwards. And in preparation for this topic today, I actually have been TDDing most of my client work this week. JOËL: What? You're telling me you don't TDD 100% of the time? Are you even a real developer? STEPHANIE: I am a real developer, and I do not TDD 100% of the time. I'm just going to say it. It's on record. JOËL: You know what? Me too. STEPHANIE: Wow, I'm glad we could clear the air on that one. [laughs] JOËL: What percent of the time would you say that you do TDD? In this case, test first as opposed to maybe testing after you've written the code or maybe not testing at all. STEPHANIE: Hmm, that's an interesting question. A part of me wants to answer it in my ideal workflow terms. But I think that is less interesting than reality, which is I will usually at least try to test first if I'm feeling like I am up for it. So maybe the percentage is, I don't know, I really couldn't tell you, but I'm just going to throw out 40% of the time [laughs] because that seems pretty, I don't know, reasonable. Sometimes you wake up, and you're just like, I'm not going to do it today. [laughs] And other days, you wake up, and you're like, you know? It sounds like a fun exercise to do for this particular feature. So yeah, if I TDD 40% of the time, then I think maybe I write tests after another 40% or 50%. And then [laughs] I'm hesitant to say this on the air, but sometimes you code, and you don't write tests for it and would not recommend it for the majority of your work. But I'm just going to be real here that sometimes it happens. JOËL: It's always a trade-off in terms of the work you put in versus the value you're getting out of it. And sometimes, you get very little value out of a test. STEPHANIE: Yeah, that's real. It totally depends on what you're doing. JOËL: I think one thing that's interesting for us, because we're consultants, so we move from one project to another, is that some projects are set up in a way that they're very test friendly. It's easy to have a testing workflow with them. And then others are just incredibly painful to test because of the way the system has been architected. And I think a TDD purist would then tell us that this is a symptom of high coupling or other architectural problems; that's probably true. But also, you don't have time to re-architect the entire system, and so then it becomes a question of trade-offs. Can I test some things easily today? Can I refactor a few things that will make this local change somewhat easier to test? And then, where is it not worth the effort to make something testable? STEPHANIE: Yeah, I've definitely struggled with that, where a part of me wanted to test something very thoroughly or even do test-driven development and then ran into some obstacles along the way and having to be realistic about that effort. The other thing I was referring to around it depending is also the actual code you're working on. So maybe if you're just writing a script or something to automate some dev workflow, it's okay for that not to be tested. And I also do think that the decision to TDD is very dependent on whether you are writing net new code, or refactoring, or having to deal with legacy code. JOËL: That definitely makes a difference. For me, when I'm refactoring in the purest sense, changing structure without changing behavior, in theory, I should not be writing tests for that because there should already be existing tests, and I'm not changing behaviors. So the test suite should prove that my changes did not change behavior. In practice, oftentimes, there is not the coverage that needs to be there. I don't know about you; I feel like I often don't trust the code enough, where I'm a little bit scared to do a refactor if there isn't test coverage. How about you? STEPHANIE: I've been running into that issue a lot on my current client project where I've been making an intentional effort to add test coverage before I make any changes because that forces me to really understand how things work because either I read a piece of code and I just can't tell at all. Or I learn later on that I thought I understood something based on the class or the method names, but it turns out that there was actually some nuance in there or side effects or what have you that belied my understanding [laughs] of what it was doing. And after a few times of that lack of trust that you talked about popping up, I was like, okay, I think, at least for me, the way that I can feel good about the work that I'm doing is to set myself up for success in that way. JOËL: Do you ever find that the code that you write in a test-driven approach tends to end up different than code that you might write with a test-after approach? STEPHANIE: Yeah, I think this can actually be answered at a few different levels but let me start with talking about how I like to practice TDD. If I'm given a user story, I usually try to work outside in. So I will write a feature or acceptance test and that involves testing how the user would interact with our application. At that point, I will usually go with the most naive implementation to get the test passing, and so it probably won't look pretty. In a recent case, I was adding a new parameter to a controller, and I just put everything in the controller to get the test green. [laughs] And then, at that point, is when I gave that code a second pass and looked for areas to extract where I could. JOËL: That refactor step and the red, green refactor cycle is really important. STEPHANIE: Yeah, absolutely. I think that is where I find TDD to be the most valuable from that higher-level perspective. And I know that there are different schools of thought on this. But that helps ensure that at least I have written the code to make the feature work the way that I was hoping. And I use TDD less for driving design decisions just because I like to have something to react to that is helpful for me rather than having a blank slate of, okay, let me write a test with an idea about how an object's interface will look. And so that's what works for me. So I do think it's kind of a mix of like from an acceptance test level; I am at least writing code that I know works, but the shape of the code for me is less determined by how I test. JOËL: So when you're looking at code that you've written six months down the line, you generally can't tell the difference whether it was test-driven or written first and tested after. STEPHANIE: That sounds right. That's just how my process works. In fact, I think recently we, to go on a quick tangent, we talked about writing conference talks, and I think I even mentioned for me the process is looking at the thing and then revising. And I think that the design driving element of TDD that a lot of people like is a bit less effective for me personally. JOËL: Hmm. Would you say that TDD does not impact the shape of the code that you end up creating in response to the tests? Or when you're talking about design, are you mostly thinking in terms of the interface that you would have in the test itself, like, what arguments the constructor takes or things like that? STEPHANIE: I think I was talking more about the latter, the interface, the construction arguments. When I do test afterwards, I also will notice the way the setup of my test how that is feeling. And if it is feeling a bit unwieldy or is a bit complicated, that will cue me to maybe take another pass at the code itself. So that's actually one way that testing after can signal to me a way that I might want to change my code. JOËL: Okay, so you're getting some of those pressures that you get from testing, but you respond to them in a like second path? STEPHANIE: Yeah, I think so. I'm curious how you TDD and whether you notice changes in how your code looks. JOËL: I think there are a couple of things that TDD does in my workflow that are really nice. One is it keeps me focused in terms of getting the work done because you're just following from one failure to another. It also keeps me focused in terms of scope. It's really easy for my engineering brain to be like, oh, we could totally do this thing and all that, and it's like, no, that's not needed to solve the problem at hand. Because in TDD, you try the smallest solution that will solve your problem, and then you will refactor it to make it maybe nicer to work with. But you try not to add new behavior that's not required in order to pass the test, and that can be a really helpful forcing function for me. STEPHANIE: That's interesting because I was just thinking about how sometimes, at least with the outside-in approach that I was talking about, I will find that the scope of the ticket is too big as I make changes to get the desired quality of the code that I want. Like I mentioned, the naive implementation, like, sure, maybe everything is in a controller, but as soon as I'm starting to do that second pass, and I want to maybe change another class and to make it work for my needs, I will notice it start to sprawl a little bit. And that is usually a signal to me that, like, oh, maybe what I need first is just refactoring the objects that I'm hoping to use to get the desired implementation. And that ends up being a separate PR that I do first to then set myself up for making the change. JOËL: The classic make the change easy before you then go and make the easy change. STEPHANIE: Right. But that does mean that that initial feature test that I wrote won't ever be green. So I do have to kind of like back out of making that change and just be like, okay, today is not the day [laughs] that I'm going to get this feature working. JOËL: There are some times where I'm in a situation like that, and I will kind of recognize, oh, there's a refactor step that's happening right now as a sort of subtask. And so, I will make that refactor change that I need to and then commit only those files that were a part of that refactor and may be included as part of the PR with the feature change or maybe push it up and make it its own PR. But depending on what the refactor is, oftentimes, I can kind of do it sort of all more or less continuously but decide once I've done that refactor step, okay, commit time but only those files for the smaller set of changes, and then keep moving with that outside-in approach. One thing I have noticed about the style of code that I tend to produce when I TDD versus when I don't is how I will tend to decouple things. And so because coupled code is really annoying to test in isolation, TDD sort of forces me to do more dependency injection, passing objects to others. It will often force me or maybe not force me, but it gives me that wholesome pressure to maybe separate HTTP requests from more of the business logic in my code, which otherwise I might completely intermix because it's just so convenient. Even certain things like class methods, I might tend to overuse them or use them more if I'm not test driving than if I were. STEPHANIE: When you talk about coupling, I'm curious, do you end up mocking a lot in the tests that you are writing to drive your development? JOËL: No, but if I'm testing after, I probably will. Mocking, I think, is a sign of coupling generally. In tests where you're just passing objects to each other, generally, you can get away with passing in a test double or something, whereas if you're hard-coding dependencies, you often have to mock. STEPHANIE: Got it. That makes a lot more sense now. I think that does require a bit of thought upfront about what kinds of objects you might need and what they would provide for you in the thing that you're testing. JOËL: Yes. There's definitely a phase where let's say; I'm testing some kind of third-party integration; I'm just kind of trying to do it all in one object that has a mix of business logic and some HTTP request stuff. It gets really annoying as we're adding...maybe the first feature is okay. I use WebMock, and I stub out a request, and it's good. And then the second one, I feel like I'm kind of duplicating that. And then the third one, I've got to deal with retries. So now I've got to go back to the first one and add some two or three WebMocks because now we've got exponential backoff code that's happening here. And this new feature broke the old tests. And it just becomes this really annoying thing to do. And then I might start thinking, okay, how do I separate these two things? I have one place where I test the HTTP logic, the exponential backoff, the what to do if I get a 404 from the API. And then, separately, I can just have the business logic and test all of those branches there without having to touch any of the HTTP stuff. I think you could get there from a few different paths. So you could get there by sort of following a lot of classic design principles, things like SOLID, because they kind of converge on that general idea as well. You could even get there if you took more of a functional programming approach where you are really good at separating side-effectful code from, I'm going to use the term loosely here, pure functions. I've heard some people make the distinction between IO versus non-IO in code and how that affects the types of tests that you write for them. And separating those two is a thing that you might do, even if you weren't writing tests at all, if that's a design principle that you know to follow. STEPHANIE: Yeah, that's a great point. I was thinking, as you were talking about your approach for handling that potential feature with talking to a third party, that I've heard that particular task or problem in software development used as an example for a lot of those different techniques or strategies that you mentioned. And I suppose TDD really is just a tool, and it doesn't replace your experience or intuition. And earlier, when we were talking about times that you don't do TDD, I will have to say that if I am doing something that I've done many times before, I feel confident enough that I don't need to lean on that red, green refactor cycle. At that point, it's more muscle memory. And maybe I do forget a step along the way, but I have the experience to know how to debug that or to see the error and know exactly what it was that I did wrong. And in that case, I am tapping into something different than using TDD. JOËL: I think definitely, for a lot of things now, there are patterns that I have learned where even if I weren't TDDing, I might do a third-party integration using this pattern because I've done it via TDD enough to know that this is a structure that I find works very well in terms of the coupling of things. And then maybe if I want to fill in some tests afterwards, then I'll thank my past self that I'm using a pattern that plays nicely with that. One thing that I do notice happens sometimes is that when people add tests after the fact, they will add tests that are green but that don't necessarily fail if the code breaks. Have you ever seen that? STEPHANIE: I have seen that before. In fact, I just saw it recently where we had a false positive test. And I made a change expecting the test to fail, and it didn't, which is not great because the value that tests have are when they fail, you want to be alerted when something goes wrong. Just because they're green doesn't mean that everything works. It just means that they didn't detect a problem. And in this particular case, I don't know if the developer who wrote this test had TDDed or not. But I did notice that in the test, we were mocking a method, and that ended up being the cause of the false positive. JOËL: I'm always a little bit skeptical of mocks because I feel like I've seen so many either brittle tests or tests that will succeed all the time come out of mocks. I don't know if you've ever heard the term tautological test or a test that is a tautology. STEPHANIE: No, I haven't. What does that mean? JOËL: In its sort of most basic sense, it's a test that is always green no matter what the output is. Some people think of it more in terms of self-referential tests, like, oh, a thing equals itself, which, yes, it does, and those tend to be always green. But it's not always self-referential. It can be some other subtle ways. Typically this happens when mocking or specifically if you mock the system under test. It's very easy to write a test that is now going to always be green, no matter how the code changes. A fun fact about the word tautology is it comes from discrete math, which is the topic of my RailsConf talk. If you write out a truth table that shows all the possible inputs and whether or not something will be true or false, depending on what the inputs are, the output column is all true in a tautology, which tells you that no matter what the inputs are, you're going to get true out of that method or function or equation. And so, if this was a Boolean expression in Ruby, you could replace that by hardcoding true and get the same result. STEPHANIE: Yeah, that's what I was imagining, a function that just returns true. [laughs] JOËL: And that's effectively what you can accidentally write when you're creating a test that is a tautological test is one where you could have just replaced the entire thing with expect true to be true, and it would have the same effect. And, like you said, tests only have value when they fail. And a test that never fails has no value. So TDD has this red, green refactor cycle. I feel like you could probably come up with a cute slogan like that for a testing-after style. So maybe I guess you'd start off you write some code, then you write a test that theoretically passes for it. So you start green, but then you want to make sure you see that test fail, so you got to go red and then comment out the code or something. Then comment it back in to see that it goes back to green to make sure that not only does this test fail when the code is broken but also that bringing this test back is what makes it pass, which is an important distinction. So maybe it's a green, red, green, and then maybe refactor. Because one thing that I admired in the style that you were talking about earlier is that even when you test after, you include a refactor step. The test at the end is not the final step in your workflow. STEPHANIE: Yeah, that's a really good point. When you said green, red, green, I was thinking of a Christmas garland [laughs] or something like that. But yeah, I do think that stuff gets skipped sometimes. If you are testing after, you're backfilling tests for code you wrote, and at that point, you think you know how it will work, and so you're writing your tests kind of colored with that in mind. I like the injecting commenting something out or changing an input or something that you know should make the test fail, just so that you can confirm that you didn't just write a test that expects true to equal true or give you a false positive like that, then go back to green. And as you were saying that, it did make me think like, oh, well, that's like a whole extra step as opposed to TDD where we do just have red, green refactor. We don't have that extra step. But I think the effort is just like put in at a different point in time. JOËL: Agreed. It's important that you see the code fail and that you see it pass after the change. The order has changed a little bit, but those two kinds of core elements are present. Kind of by default, you have no choice when you're doing TDD. You have the ability to skip that if you're testing after, but ideally, you incorporate those in a robust test after workflow as well. STEPHANIE: Yeah. And I know I mentioned times when I've done something enough or used a pattern enough that maybe I'll just go ahead and implement it and then backfill with tests. And I also recognize that in those moments, I could have done something wrong, that there is some amount of wanting to check that the test failed. And I imagine there is some kind of balance to achieve there between the speed that you get by having that experience and knowing the direction you want to take things and applying a pattern that you've done a lot with being like, oh, we're all human, and sometimes we make mistakes. JOËL: In a situation where you feel like you're coding something that you've coded up 100 times before, you're very familiar with this. Do you find that a test after workflow is faster for you? STEPHANIE: Hmm, that's an interesting question. JOËL: Because I think that's often a motivation. It's like, I don't want to bother, like, I just have the idea. I know what to do. Let me just write that code and get it done. STEPHANIE: I think if I were introducing a new route or controller action or whatever, I don't need to go through the cycle of writing a test and it failing because I haven't added the action to the controller yet. It's like I know that that is the next logical step, and so maybe I might skip it there. But if I'm at the point where I'm working with business or domain logic, I think that's where is the value of test writing first because it's like, I passed the framework and passed my tools. And now, I'm working at working through the logic of the business problem itself. JOËL: So you're working in maybe slightly larger iterations of that red, green refactor cycle. STEPHANIE: Yeah, that's a good way to describe it. JOËL: I was recently working on a gem and tried to TDD it from scratch and went with micro iterations. And it was actually really fun, and there was a flow to it. And this is a greenfield side project. And it helped me stay focused. I think it did give me a decent design. I really enjoyed it. STEPHANIE: Nice. Was there something satisfying about seeing that green each time and kind of doing that bit of mechanical labor? And I can see how that can feel almost meditative. JOËL: Yes. And I think also because this was a problem that I didn't fully know how I was going to solve, TDD helped really focus me on solving sub-parts of that problem, things that I can hold in my head and solve in a minimalistic way and then iterate on. STEPHANIE: I like that a lot. You were using that technique, and that really helped for the task at hand, which was, in this case, a bit smaller in scope. I think the way you and I have been talking about TDD has been very realistic and very reasonable. And I'm curious what you think about people who kind of use it as the pinnacle of how you should write code. JOËL: I think that's really interesting because TDD is a really wonderful technique, and I wish more people used it. But it's kind of taken on a mystique of its own where if you do TDD or claim to do TDD 100% of the time, now, all of a sudden, you've put yourself on another level. And I think people even who choose for pragmatic reasons not to TDD all the time maybe feel a little bit of guilt or at least feel the need to explain themselves to other people to say, "Hey, I didn't TDD this here. Well, let me explain to you why that's okay, and I'm not a bad programmer." STEPHANIE: Yeah, I think we even alluded a little bit to that earlier in the show, and I could hear my hesitancy to be like, oh, I guess I'm going to say this and have all these people hear it. But I think that's a good point that it's okay for you not to do it 100% of the time. That doesn't make you any less of a programmer. Also, the way we've been talking about it also makes it sound like one of those things where it's like you do have to learn the rules before you can break them. And so there is value in learning it and doing it. And then you also, after having done it enough, know when you want to use it or when you don't. My advice for folks who haven't really done it before or don't quite see the value of it is just to try it and then decide for yourself. I think at the end of the day, we should all feel empowered to be able to decide how we work best. JOËL: It's also really valuable, I think, to maybe pair with someone who is really good at that and to get to see what their workflow is like. Oftentimes, there's almost a hump of getting into it where you are more productive without TDDing because you're not comfortable with the flow or with the techniques. And it takes a lot of expertise to get over that hump where maybe at the expert end of things, you are more productive with it. And on the less expert end, it just becomes a chore that takes up all of your time or ends up giving you results that aren't that great anyway. And so, how do you cross that chasm? STEPHANIE: Yeah, that's a really, really great point because, in some ways, when you first get started, it will feel slow. You are unlearning the ways that you have known to code before and trying to do it in a different way. And I really like your advice about trying to pair with someone who has expertise or has been practicing it for a long time. That was my first real introduction to it too. At this point, I had been a few years into my career and hadn't really tried it because it seemed very daunting, and seeing someone else verbalize their process and seeing their workflow was really helpful for me to get on board. JOËL: I think what I would like is for TDD to be a tool that is aspirational for a lot of people. If you're new to the technique and you've paired with somebody who's really good at it, and you see the flow that they have and be like, wow, that's really good. I would love to get that incorporated in the way that I work. Rather than a sort of measuring stick for how elite of a programmer you are. There's no sense in shaming people over the tools they use. STEPHANIE: Right. Because it should also be accessible, and if you make people feel bad about it, and then it's not accessible to folks. JOËL: On that note. Shall we wrap up? STEPHANIE: Yeah, let's wrap up. Show notes for this episode can be found at bikeshed.fm. JOËL: This show has been produced and edited by Mandy Moore. STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeee!!!!!! ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

As a developer have you ever worked on an API endpoint but you can't easily find the documentation for the API to see how pieces work, or can't find the specific sequence diagram on how your domains interact, or how about using some clunky outdated internal tool that you have to use to compile your code, well your user experience is suffering, more specifically your developer experience is poor. The term “developer experience” or DX is becoming more and more pervasive in the tech industry as companies realize how important it is for the success of their businesses. But what is DX you ask? Well, in today's episode I am joined by a very special guest to answer that question and explore the realm of DX engineering and how you can help yourself and your team become more productive and build the experience you deserve. Our guest today, Cassidy Williams, spreads the joy of tech through her contagious positivity and accessible content. She earned her Bachelor of Science in Computer Science from Iowa State University and is a startup advisor and investor and developer experience expert. Currently, she is the CTO at Contenda, an AI content generation platform. Previously, she was the Director of Developer Experience at Netlify and has also worked at a variety of large and small companies like Remote, React Training, CodePen, Amazon and Venmo. She's active in the developer community, has given hundreds of talks around the world, and also co-hosts the Stack overflow podcast and The Dev Morning Show (at night) podcast. She is one of Glamour Magazine's 35 Women Under 35 Changing the Tech Industry and LinkedIn's Top Professionals 35 & Under. She wants to inspire generations of STEM students to be the best they can be. When Cassidy is not inspiring the next generation of coders she is playing music, singing karaoke, creating memes, building mechanical keyboards, and hanging out with her sister. Connect with Cassidy: Twitter The Dev Morning Show (at night) LinkedIn Website Show notes and helpful resources: CTO at Contenda Glamour Magazine's 35 Women Under 35 Changing the Tech Industry Subscribe to Cassidy's newsletter it won't disappoint Cassidy's fav joke at the time of recording “I adopted my dog from a blacksmith. As soon as we got home, she made a bolt for the door!” Obsidian note taking software for productivity As a developer experience engineer you are making developers live's easier through content generation, demos, tutorials and anything that can get them from zero to 1, the “Time to Hello World” Make Time by Jake Knapp and John Zeratsky Cosynd App - The fastest and most affordable way for content creators to register their works Visit podcast.unfilteredbuild.com for more info Building something cool or solving interesting problems? Want to be on this show? Send me an email at jointhepodcast@unfilteredbuild.com Podcast produced by Unfiltered Build - dream.design.develop.

In our first-ever panel episode, PodRocket Producer Emily brings together Cassidy Williams, Michael Chan, and Alex Trost to talk about breaking up with React, web components, and the pros and cons of using Prettier. Plus, hot takes that will make you ask, is this a web development podcast? Links Is it time to break up with React? * React I Love You, But You're Bringing Me Down (https://marmelab.com/blog/2022/09/20/react-i-love-you.html) * Dan Abromov's response (https://twitter.com/dan_abramov/status/1572590212647391235) Should we finally stop using web components? * Theo (Ping.gg CEO) talks about his frustrations (https://twitter.com/t3dotgg/status/1576815005042737152) * Brian Vaughn makes his opinion known (https://twitter.com/brian_d_vaughn/status/1576000911721529345) * Matthew Phillips chimes in with a blog post (https://twitter.com/matthewcp/status/1576647455839752192) * 2019 blog post from Rich Harris about not using web components (https://dev.to/richharris/why-i-don-t-use-web-components-2cia) Should we stop using Prettier? * Anthony Fu details why he doesn't use Prettier (https://twitter.com/antfu7/status/1576164644338958338) Cassidy Williams https://cassidoo.co/ https://twitter.com/cassidoo https://cassidoo.co/newsletter/ https://github.com/cassidoo https://www.linkedin.com/in/cassidoo/ Michael Chan https://chan.dev/ https://www.youtube.com/c/chantastic https://github.com/chantastic discord.gg/lunchdev (https://discord.com/invite/lunchdev) Alex Trost https://twitter.com/trostcodes https://frontend.horse/ https://discord.com/invite/MVymXFPtBE https://www.twitch.tv/trostcodes https://twitter.com/frontendhorse https://www.youtube.com/c/AlexTrosts https://www.linkedin.com/in/trostcodes/ https://trost.codes/ Tell us what you think of PodRocket We want to hear from you! We want to know what you love and hate about the podcast. What do you want to hear more about? Who do you want to see on the show? Our producers want to know, and if you talk with us, we'll send you a $25 gift card! If you're interested, schedule a call with us (https://podrocket.logrocket.com/contact-us) or you can email producer Kate Trahan at kate@logrocket.com (mailto:kate@logrocket.com) Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form (https://podrocket.logrocket.com/get-podrocket-stickers), and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket combines frontend monitoring, product analytics, and session replay to help software teams deliver the ideal product experience. Try LogRocket for free today. (https://logrocket.com/signup/?pdr) Special Guests: Alex Trost, Cassidy Williams, and Chantastic.

In this supper club episode of Syntax, Wes and Scott talk with Kristi Perreault of Liberty Mutual about why they're using serverless functions, what languages they write in, managing security and montoring, and Kristi's journey into tech as a career. Hasura - Sponsor With Hasura, you can get a fully managed, production-ready GraphQL API as a service to help you build modern apps faster. You can get started for free in 30 seconds, or if you want to try out the Standard tier for zero cost, use the code “TryHasura” at this link: hasura.info. We've also got an amazing selection of GraphQL tutorials at hasura.io/learn. Stack Overflow Podcast - Sponsor For over a dozen years, the Stack Overflow Podcast has been exploring what it means to be a developer, and how the art and practice of software programming is changing our world. Hosted by Ben Popper, Cassidy Williams, and Ceora Ford, the Stack Overflow Podcast is your home for all things code. Listen to new episodes twice a week, wherever you get your podcasts. Lightstep Incident Response - Sponsor Streamline on-call, collaboration, incident management, and automation with a free 30-day trial of Lightstep Incident Response, built on ServiceNow. Usage-based pricing on active services promotes collaboration across your entire team to build a culture of service ownership. Listeners of Syntax will also receive a free Lightstep Incident Response T-shirt after firing an alert or incident. Pay for the services you use, not the number of people on your team with Lightstep Incident Response, built on ServiceNow. Streamline on-call, collaboration, incident management, and automation with a free 30-day trial. Fire an alert or incident today and receive a free Lightstep Incident Response t-shirt. Show Notes 00:33 Welcome 03:24 Guest introduction @kperreault95 Kristi Perreault on Dev.to Kristi Perreault AWS Hero Liberty Mutual 04:55 Developers at Mutual Liberty 07:05 What did you do before serverless functions? 08:36 Why are you using serverless functions? 12:39 What languages are you writing for serverless functions? 15:53 Sponsor: Hasura 17:22 Where does all the code live? 20:58 AWS CDK AWS CDK CDK Workshop 25:55 Sponsor: Lightstep Incident Response 27:07 How did you get into tech? 31:44 How do you organize all the functions? 33:51 How important is security? 35:23 What are IM roles? 36:16 How do you deal with spiking and monitoring? Datadog Splunk 41:20 Sponsor: Stackoverflow Podcast 42:02 Have you used Edge functions? 42:50 Supper Club Questions Off by None newsletter Ready Set Cloud ××× SIIIIICK ××× PIIIICKS ××× Loki on Disney+ Shameless Plugs Real World Serverless Podcast Serverless Denver Group AWS Summits @ServerlessCO Kristi Perreault on Medium Tweet us your tasty treats Scott's Instagram LevelUpTutorials Instagram Wes' Instagram Wes' Twitter Wes' Facebook Scott's Twitter Make sure to include @SyntaxFM in your tweets

In this supper club episode of Syntax, Wes and Scott talk with Pokey Rule about using his voice to code, and the current state of voice coding software. Stackoverflow Podcast - Sponsor For over a dozen years, the Stack Overflow Podcast has been exploring what it means to be a developer, and how the art and practice of software programming is changing our world. Hosted by Ben Popper, Cassidy Williams, and Ceora Ford, the Stack Overflow Podcast is your home for all things code. Listen to new episodes twice a week, wherever you get your podcasts. directus - Sponsor Directus is an open-source data platform that instantly layers on top of any SQL database. Our Data Engine empowers engineers with dynamic REST+GraphQL APIs, workflow automation, built-in auth, caching, and asset transformations. And the included Data Studio democratizes your database, allowing even non-technical users to browse, manage, and visualize database content through a no-code data collaboration app. Get started in minutes with a free Directus Community Cloud project. Show Notes 00:33 Welcome 01:35 Guest introduction Con 2021 - Cursorless: keyboards and mice are sooo last year!! by Pokey Rule Emily Shea 05:12 How does coding with your voice work? Talon Voice Cursorless Talon 09:45 How do you handle triggering wrong words? 11:41 Sponsor: The Stack Overflow Podcast 12:26 Example of voice coding Parrot 14:21 What are the noises you make for? 24:29 Working on multiple lines at the same time 27:37 How do you decide where the hats go? 31:18 Sponsor: directus 32:59 What is the community of users like for this? Tree Sitter “Incremental, zero-config Code Nav using stack graphs” by Douglas Creager 35:20 Does eye tracking work? 36:48 What kind of mic do you use? DPA Microphone The Voice Book 39:25 Supper Club questions Dark Abyss VS Code theme Kinesis Freestyle 2 Charybdis Nano keyboard Nexstand Arxiv Sanity Subvocal Recognition Imagen Research Midjourney 54:11 ××× SIIIIICK ××× PIIIICKS ××× ××× SIIIIICK ××× PIIIICKS ××× Git Imerge Shameless Plugs Scott: LevelUp Tutorials Wes: Wes Bos Tutorials Pokey: YouTube channel, Sponsor Pokey on GitHub Tweet us your tasty treats Scott's Instagram LevelUpTutorials Instagram Wes' Instagram Wes' Twitter Wes' Facebook Scott's Twitter Make sure to include @SyntaxFM in your tweets

In this Coffee Talk Aleksandra Desmurs-Linczewska (https://www.callstack.com/team/aleksandra-desmurs-linczewska) and Łukasz Chludziński (https://www.callstack.com/team/lukasz-chludzinski) provide a lot of ideas for staying up to date with the community news. They discuss the most valuable resources such as newsletters, top Twitter accounts, blogs, podcasts, conferences, GitHub and release notes: Newsletters: The React Native Newsletter, Tyler's (ui.dev) newsletter, JavaScript Weekly, Cassidy Williams's newsletter Twitter accounts: official React and React Native accounts Callstack, Remix, Next, Vercel accounts of people who are well-known in the community: Angie Jones (@techgirl1908), Sara Vieira (@NikkitaFTW), Kadi Kraman (@kadikraman), Evan Bacon (@Baconbrix), Dan Abramov (@dan_abramov), Lorenzo Sciandra (@Kelset), Rick Hanloni (@rickhanlonii), Ryan Cavanaugh (@SeaRyanC), Cassidy Williams (@cassidoo), Michal Pierzchala (@thymikee), Wes Bos (@wesbos), Jamon Holmgren (@jamonholmgren), Kent C Dodds (@kentcdodds), Michael Jackson (@mjackson), Ryan Florence (@ryanflorence), Sebastien Lorber (@sebastienlorber) Conferences: React Native EU https://hubs.li/Q01bt5WQ0 React Summit https://reactsummit.com/ Chain React https://cr.infinite.red/ Podcasts: The React Native Show https://hubs.li/Q01bt7gK0 React Native Radio https://reactnativeradio.com/ DevSpresso JS News https://bit.ly/3LnLYmC YouTube channels: Ben Awad https://www.youtube.com/c/BenAwad97 William Candilion https://www.youtube.com/c/wcandillon Fireship.io https://www.youtube.com/c/Fireship The overview of resources will come in handy for every React Native developer regardless of whether you have much experience or you are new to the React Native world.

This double guest episode features Cassidy Williams, Head of Developer Experience and Education and Tobi Pfeiffer, Staff Engineer from Remote. This fast growing Elixir company provides HR support to clients who are hiring internationally. In this fascinating fast-paced conversation Cassidy and Tobi discuss how Remote works, the explosive growth it has seen and what Cassidy and Tobi have most enjoyed in their time there. Also, we learn more about Cassidy's content creation projects, why Tobi's handle is PragTob, and the strangest laws they have come across when working internationally. We also learn about Cassidy's love of mechanical keyboards and about Tobi's adorable pet rabbits. We wrap up the episode with some great book recommendations and what's upcoming at Remote. Key Points From This Episode: Welcome to Cassidy Williams (Head of Developer Experience and Education) and Tobi Pfeiffer (Staff Engineer) at Remote. Why Cassidy recommends the app Centered for achieving flow state. How different types of music affect everyone's concentration while coding. Getting to know Tobi: Rails Girls community member, wearer of green and keyboard player. Who Cassidy is: a dweeb who likes memes and how she found the world of coding. What Remote is and how it works. How Tobi came up with the handle PragTob! The explosive growth Remote has seen, and how they stay on top of it. What's coming on the open-source front of Remote. The challenges Remote faces when employing people from different countries. The strangest laws Tobi and Cassidy have come across internationally. Why Cassidy enjoyed the well-practiced onboarding aspects of Remote, and the company values Tobi most appreciates. Tobi's secret role in the formation of Remote! The people Tobi and Cassidy see moving into Elixir and which skills benefit them the most. Why Tobi's GitHub picture has a rabbit and his favorite game. Cassidy's passion for mechanical keyboards! Book club recommendations: the books you should be looking out for, and why! Links Mentioned in Today's Episode: Cassidy Williams on LinkedIn — https://www.linkedin.com/in/cassidoo/ Cassidy Williams on TikTok — https://www.tiktok.com/@cassidoo Cassidy Williams' Newsletter — https://cassidoo.co/newsletter/ Tobi Pfeiffer on LinkedIn — https://www.linkedin.com/in/tobiaspfeiffer Tobi Pfeiffer on GitHub — https://github.com/pragtob Remote — https://remote.com/ Remote GitHub — https://github.com/remoteoss Centered — https://www.centered.app/ Benchee — https://elixirschool.com/en/lessons/misc/benchee SimpleCov — https://github.com/simplecov-ruby Rails Girls Berlin — http://railsgirls.com/berlin The Agile Samurai: How Agile Masters Deliver Great Software — https://www.amazon.com/Agile-Samurai-Software-Pragmatic-Programmers Netlify — https://www.netlify.com/ Devs for Ukraine — https://www.devsforukraine.io/ Jose Valim — https://www.linkedin.com/in/josevalim Marcelo Lebre — https://www.linkedin.com/in/marcelolebre RubyConf — https://rubyconf.org/ Rust — https://rust.facepunch.com/ Go — https://go.dev/ Node.js — https://nodejs.org/en/ React — https://reactjs.org/ Astro — https://astro.build/ Supabase — https://supabase.com/ Thea 2: The Shattering — https://store.steampowered.com/app/606230/Thea2TheShattering Mechanical Keyboard — https://en.wikipedia.org/wiki/ModelM_keyboard QMK Firmware — https://docs.qmk.fm/#/ Brandon Sanderson — https://www.brandonsanderson.com/ Dark Matter — https://www.amazon.com/Dark-Matter-Novel-Blake-Crouch SmartLogic — https://smartlogic.io/ SmartLogic Jobs — https://smartlogic.io/about/jobs Special Guests: Cassidy Williams and Tobi Pfeiffer.

You can learn more about Clement's career on his LinkedIn and on Twitter (assuming you speak French).You can learn more about Dailymotion here and check out the roles they are hiring for here.You can find Cassidy Williams on Twitter and at her website. You can find Ceora Ford on Twitter and at her website.Our Lifeboat badge winner of the week is Swati Kiran, who helped solve an error causing permission problems in an angular app.

You can learn more about Clement's career on his LinkedIn and on Twitter (assuming you speak French).You can learn more about Dailymotion here and check out the roles they are hiring for here.You can find Cassidy Williams on Twitter and at her website. You can find Ceora Ford on Twitter and at her website.Our Lifeboat badge winner of the week is Swati Kiran, who helped solve an error causing permission problems in an angular app.

Will no one think of the maintainers? As The New Stack points out, watching millions of projects fail because of a bug in an open source library has become common enough that  we shrug and reply, "Told you so." It's gotten so bad, big tech companies are visiting the White House to discuss the issue as a matter of national security.There is a great post up on the Stack Overflow blog examining  this issue, but it's not about color.js, it's about Log4J.  Traffic to questions on this logging library grew more than 1000% percent after the recent revelations about a new vulnerability. Also discussed in this episode: cryptographer and Signal creator Moxie Marlinspike stepped down from his role as CEO of the encrypted messaging service.  That's news, but he actually made bigger waves in tech circles with an unrelated blog post detailing  his first experience with Web3. Spoiler alert: it's not as decentralized or divorced from Web2 as you might have thought.You can find Cassidy Williams on Twitter and her website.Ben Popper can be found on Twitter here.Ryan Donovan can be found on Twitter, or writing for the Stack Overflow blog. 

Will no one think of the maintainers? As The New Stack points out, watching millions of projects fail because of a bug in an open source library has become common enough that  we shrug and reply, "Told you so." It's gotten so bad, big tech companies are visiting the White House to discuss the issue as a matter of national security.There is a great post up on the Stack Overflow blog examining  this issue, but it's not about color.js, it's about Log4J.  Traffic to questions on this logging library grew more than 1000% percent after the recent revelations about a new vulnerability. Also discussed in this episode: cryptographer and Signal creator Moxie Marlinspike stepped down from his role as CEO of the encrypted messaging service.  That's news, but he actually made bigger waves in tech circles with an unrelated blog post detailing  his first experience with Web3. Spoiler alert: it's not as decentralized or divorced from Web2 as you might have thought.You can find Cassidy Williams on Twitter and her website.Ben Popper can be found on Twitter here.Ryan Donovan can be found on Twitter, or writing for the Stack Overflow blog. 

In this episode, I will share with you the marketing plan that resulted in the successful launch of my interview with Cassidy Williams (aka @cassidoo) that has broken every wbe record to the date!I will give you a detailed walkthrough of everything I have planned for each platform: twitter, reddit, LinkedIn, etc...About this podcastJoin the WBE spaceBuy a CoffeeFollow me on TwitterRecommended Tool:HivoeBackground music:Music: https://www.chosic.com/free-music/all/ 

2021 has been a year of ups and downs in the world of DevRel and Community work. From the shifting quicksand of events returning in person, then virtual once again, to the massive opening of job reqs for positions under the DevRel umbrella, it's been a wild ride. We've also tried new things, both on the podcast and personally, and in this episode we will cover our perspectives on the year that was 2021. Links: * Sonder (https://seths.blog/2017/10/the-sonder-breakthrough/) * Top Episodes: * Online Community Platforms (http://www.communitypulse.io/58-online-community-platforms) (Jono Bacon, Noele Flowers) - Episode 58 * DevRel Content Channels (http://www.communitypulse.io/57-devrel-content-channels) (Cassidy Williams, Joe Karlsson) - Episode 57 * DevRel Around the World (http://www.communitypulse.io/59-devrel-around-the-world) - Episode 59 Send in your feedback! Hit us up on Twitter (https://twitter.com/community_pulse) or shoot us an email (info@communitypulse.io). Special shout-out to Sarah Allen for all of the hard work getting the new website up and running. Photo by Moritz Knöringer (https://unsplash.com/@mokngr?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on Unsplash (https://unsplash.com/@mokngr?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) Enjoy the podcast? Please take a few moments to leave us a review on iTunes (https://itunes.apple.com/us/podcast/community-pulse/id1218368182?mt=2) and follow us on Spotify (https://open.spotify.com/show/3I7g5WfMSgpWu38zZMjet?si=565TMb81SaWwrJYbAIeOxQ), or leave a review on one of the other many podcasting sites that we're on! Your support means a lot to us and helps us continue to produce episodes every month. Like all things Community, this too takes a village.

Cassidy Williams (aka @cassidoo) is a software developer with an impressive resume. She has worked in more than six software companies and she has experienced it all: small companies, big companies, pure development positions, and more leading and teaching gigs too. On top of that, Cassidy still has the energy to maintain and cultivate an active social media presence that has reached more than 170K followers on Twitter.Follow Cassidy:TwitterNewsletterWebsiteTikTokAbout WBE Podcast:Become a MemberBuy a CoffeeJoin Virtual Co-Working spaceTwitterTools* AstroBackground Music:Listen Here

Need a crash course on how to approach live streaming? In this episode, we talk to Cassidy "Cassidoo" Williams, developer and content creator. You'll learn what equipment and tools Cassidy uses for streaming, tips on how to get started, different approaches to handling the live chat, and more.Visit our website for the detailed episode recap with key learnings.Cassidy's Twitch channelLearn with Jason — a live learning site for developersTwitch, YouTube — popular streaming platformsOBS, Streamlabs, Twitch Studio — streaming desktop appsSocket Studio — open source software for enhancing Twitch streamsShure MV7, Blue Yeti — popular microphonesSony A6100 — Cassidy's streaming cameraElgato Key Lights — a compact lighting optionFollow Cassidy on GitHubFollow Cassidy on TwitterCassidy's website  and newsletterThanks for listening! If you found the episode useful, please spread the word about the show on Twitter mentioning @userlist, or leave us a review on iTunes.SponsorThis show is brought to you by Userlist — the best way for SaaS founders to send onboarding emails, segment your users based on events, and see where your customers get stuck in the product. Start your free trial today at userlist.com.

On today's episode, our hosts Sarah and Bryan are going to talk about the role of community in Developer Experience.We're all part of communities, whether we participate in them or not.Are they any major differences between developers centric communities and more traditional ones, centered around geography or interests? We're also seeing more and more developers communities popping up, usually launched by tech companies. What is the value proposition for those developers? How do you take care of a global community, where anything can be happening 24/7?To help us answers these questions, we're super happy to welcome today our guest Cassidy Williams. Cassidy is Director Experience at Netlify. Outside of that role, Cassidy runs her own community newsletter, is a mechanical keyboard enthusiast and is arguably one of the funniest people on developer social media.Cassidy Williams: @cassidooBryan Robinson: @brobSarah Dayan: @frontstuff_ioNetlify: @netlify / netlify.comAlgolia: @algolia / algolia.com

Today we have another episode of Better Done Than Perfect. Listen in as we talk with Cassidy "Cassidoo" Williams, developer and content creator. You'll learn what equipment and tools Cassidy uses for streaming, tips on how to get started, different approaches to handling the live chat, and more.Please head over to the episode page for the detailed recap and key takeaways.Show notesCassidy's Twitch channelLearn with Jason — a live learning site for developersTwitch, YouTube — popular streaming platformsOBS, Streamlabs, Twitch Studio — streaming desktop appsSocket Studio — open source software for enhancing Twitch streamsShure MV7, Blue Yeti — popular microphonesSony A6100 — Cassidy's streaming cameraElgato Key Lights — a compact lighting optionFollow Cassidy on GitHubFollow Cassidy on TwitterCassidy's website and newsletterSponsorThis show is brought to you by Userlist — the best way for SaaS founders to send onboarding emails, segment your users based on events, and see where your customers get stuck in the product. Start your free trial today at userlist.com.Interested in sponsoring an episode? Learn more here.Leave a ReviewReviews are hugely important because they help new people discover this podcast. If you enjoyed listening to this episode, please leave a review on iTunes. Here's how.

How can you build a following, and a career, with memes? In this episode of the Sourcegraph Podcast, Cassidy Williams, Director of Developer Experience at Netlify, joins Beyang Liu, co-founder and CTO of Sourcegraph, to discuss why we should consider communication a core skill instead of a soft skill, why you should be a developer advocate or a software engineer but not both, and why, when learning React, you should start with the fundamentals. Along the way, Cassidy shares stories about the job she held the longest (mascot for Iowa State), positive and negative experiences from the heyday of hackathons, and the time she nearly went blind from burnout.Show notes & transcript: https://about.sourcegraph.com/podcast/cassidy-williams/Sourcegraph: about.sourcegraph.com

Steph talks about starting a new project and identifying "focused" tests while Chris shares his latest strategy for managing flaky tests. They also ponder the squishy "it depends" side of software and respond to a listener question about testing all commits in a pull request. This episode is brought to you by ScoutAPM (https://scoutapm.com/bikeshed). Give Scout a try for free today and Scout will donate $5 to the open source project of your choice when you deploy. rspec-retry (https://github.com/NoRedInk/rspec-retry) Cassidy Williams - It Depends - GitHub Universe 2021 (https://www.youtube.com/watch?v=aMWh2uLO9OM) Say No To More Process (https://thoughtbot.com/blog/say-no-to-more-process-say-yes-to-trust) StandardRB (https://github.com/testdouble/standard) Become a Sponsor (https://thoughtbot.com/sponsorship) of The Bike Shed! Transcript: CHRIS: My new computer is due on the fourth. I'm so close. STEPH: On the fourth? CHRIS: On the fourth. STEPH: That's so exciting. CHRIS: And I'm very excited. But no, I don't want to upgrade any software on this computer anymore. Never again shall I update a piece of software on this computer. STEPH: [laughs] CHRIS: This is its final state. And then I will take its soul and move it into the new computer, and we'll go from there. [chuckles] STEPH: Take its soul. [laughs] CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. STEPH: And I'm Steph Viccari. CHRIS: And together, we're here to share a bit of what we learn along the way. So, Steph, what's new in your world? STEPH: Hey, Chris. Let's see. It's been kind of a busy week. It's been a busy family week. Utah, my dog, hasn't been feeling well as you know because you and I have chatted off-mic about that a bit. So he is still recovering from something, I don't know what. He's still on most days his normal captain chaos self, but then other days, he's not feeling well. So I'm just keeping a close eye on him. And then I also got some other family illnesses going on. So it has been a busy family week for sure. On the more technical project side, I am wrapping up my current project. So I have one more week, and then I will shift into a new project, which I'm very excited about. And you and I have chatted about this several times. So there's always just that interesting phase where you're trying to wrap up and hand things off and then accomplish last-minute wishlist items for a project before then you start with a new one. So I am currently in that phase. CHRIS: How long were you on this project for? STEPH: It'll be a total of I think eight months. CHRIS: Eight months, that's healthy. That's a bunch. It's always interesting to be on a project for that long but then not longer. There were plenty of three and four-month projects that I did. And you can definitely get a large body of work done. You can look back at it and proudly stare at the code that you have written. But that length of time is always interesting to me because you end up really...for me, when I've had projects that went that long but then not longer, I always found that to be an interesting breaking point. How are you feeling moving on from it? Are you ready for something new? Are you sad to be moving on? Do you feel attached to things? STEPH: It's always a mix. I'm definitely attached to the team, and then there are always lots of things that I'd still love to work on with that team. But then, I am also excited to start something new. That's why I love this role of consulting because then I get to hop around and see new projects and challenges and work with new people. I'm thinking seven to eight months might be a sweet spot for me in terms of the length of a project. Because I find that first month with a project, I'm really still ramping up, I'm getting comfortable, I'm getting in the groove, and I'm contributing within a short amount of time. But I still feel like that first month; I'm getting really comfortable with this new environment that I'm in. And so then I have that first month. And then, at six months, I have more of heads-down time. And I get to really focus and work with a team. And then there's that transition period, and it's nice to know when that's coming up for several weeks, so then I have a couple of weeks to then start working on that transition phase. So eight months might be perfect because then it's like a month for onboarding, ramping up, getting comfortable. And then six months of focus, and then another month of just focusing on what needs to be transitioned so then I can transition off the team. CHRIS: All right. Well, now we've defined it - eight months is the perfect length of a project. STEPH: That's one of the things I like about the Boost team is because we typically have longer engagements. So that was one of the reasons when we were splitting up the teams in thoughtbot that I chose the Boost team because I was like, yeah, I like the six-month-plus project. Speaking of that wishlist, there are little things that I've wanted to make improvements on but haven't really had time to do. There's one that's currently on my mind that I figured I'd share with you in case you have thoughts on it. But I am a big proponent of using the RSpec focus filter for when running tests. So that way, I can just prefix a context it block or describe block with F, and then RSpec I can just run all the tests. But RSpec will only run the tests that I've prefixed with that F focus command., and I love it. But we are running into some challenges with it because right now, there's nothing that catches that in a pull request. So if you commit that focus filter on some of your tests, and then that gets pushed up, if someone doesn't notice it while reviewing your pull request, then that gets merged into main. And all of the tests are still green, but it's only a subset of the tests that are actually running. And so it's been on my mind that I'd love something that's going to notice that, that's going to catch it, something that is not just us humans doing our best but something that's automated that's going to notice it for us. And I have some thoughts. But I'm curious, have you run into something like this? Do you have a way that you avoid things like that from sneaking into the main branch? CHRIS: Interestingly, I have not run into this particular problem with RSpec, and that's because of the way that I run RSpec tests. I almost never use the focus functionality where you actually change the code file to say, instead of it, it is now fit to focus that it. I tend to lean into the functionality where RSpec you can pass it the line number just say, file: and then line number. And RSpec will automatically figure out which either spec or context block or entire file. And also, I have Vim stuff that allows me to do that very easily from the file. It's very rare that I would want to run more than one file. So basically, with that, I have all of the flexibility I need. And it doesn't require any changes to the file. So that's almost always how I'm working in that mode. I really love that. And it makes me so sad when I go to JavaScript test runners because they don't have that. That said, I've definitely felt a very similar thing with ESLint and ESLint yelling at me for having a console.log. And I'm like, ESLint, I'm working here. I got to debug some stuff, so if you could just calm down for a minute. And what I would like is a differentiation between these are checks that should only run in CI but definitely need to run in CI. And so I think an equivalent would be there's probably a RuboCop rule that says disallow fit or disallow any of the focus versions for RSpec. But I only want those to run in CI. And this has been a pain point that I felt a bunch of times. And it's never been painful enough that I put in the effort to fix it. But I really dislike particularly that version of I'm in my editor, and I almost always want there to be no warnings within the editor. I love that TypeScript or ESLint, or other things can run within the editor and tell me what's going on. But I want them to be contextually aware. And that's the dream I've yet to get there. STEPH: I like the idea of ESLint having a work mode where you're like, back off, I am in work mode right now. [chuckles] I understand that I won't commit this. CHRIS: I'm working here. [laughter] STEPH: And I like the idea of a RuboCop. So that's where my mind went initially is like, well, maybe there's a custom cop, or maybe there's an existing one, and I just haven't noticed it yet. But so I'm adding a rule that says, hey, if you do see an fcontext, fdescribe, ffit, something like that, please fail. Please let us know, so we don't merge this in. So that's on my wishlist, not my to-don't list. That one is on my to-do list. CHRIS: I'm also intrigued, though, because the particular failure mode that you're describing is you take what is an entire spec suite, and instead, you focus down to one context block within a given file. So previously, there were 700 specs that ran, and now there are 12. And that's actually something that I would love for Circle or whatever platform you're running your tests on to be like, hey, just as a note, you had been slowly creeping up and had hit a high watermark of roughly 700 specs. And then today, we're down to 12. So either you did some aggressive grooming, or something's wrong. But a heuristic analysis of like, I know sometimes people delete specs, and that's a thing that's okay but probably not this many. So maybe something went wrong there. STEPH: I feel like we're turning CI into this friend at the bar that's like, "Hey, you've had a couple of drinks. I just wanted to check in with you to make sure that you're good." [laughs] CHRIS: Yes. STEPH: "You've had 100 tests that were running and now only 50. Hey, friend, how are you? What's going on?" CHRIS: "This doesn't sound like you. You're normally a little more level-headed." [laughs] And that's the CI that is my friend that keeps me honest. It's like, "Wait, you promised never to overspend anymore, and yet you're overspending." I'm like, "Thank you, CI. You're right; I did say I want the test to pass." STEPH: [laughs] I love it. I'll keep you posted if I figure something out; if I either turn CI into that friend, that lets me know when my behavior has changed in a concerning way, and an intervention is needed. Or, more likely, I will see if there's a RuboCop or some other process that I can apply that will check for this, which I imagine will be fast. I mean, we're very mindful about ensuring our test suite doesn't slow down as we're running it. But I'm just thinking about this out loud. If we add that additional cop, I imagine that will be fast. So I don't think that's too much of an overhead to add to our CI process. CHRIS: If you've already got RuboCop in there, I'm guessing the incremental cost of one additional cop is very small. But yeah, it is interesting. That general thing of I want CI to go fast; I definitely feel that feel. And we're slowly creeping up on the project I'm working on. I think we're at about somewhere between five to six minutes, but we've gotten there pretty quickly where not that long ago; it was only three minutes. We're adding a lot of features specs, and so they are definitely accruing slowdowns in our CI. And they're worth it; I think, because they're so valuable. And they test the whole integration of everything, but it's a thing that I'm very closely watching. And I have a long list of things that I might pursue when I decide it's time for CI to get a haircut, as it were. STEPH: I have a very hot tip for a way to speed up your test, and that is to check if any of your tests have a very long sleep in them. That came up recently [chuckles] this week where someone was working in a test and found some relic that had been added a while back that then wasn't caught. And I think it was a sleep 30. And they were like, "Hey, I just sped up our test by 30 seconds." I was like, ooh, we should grep now to see if there's anything else like that. [laughs] CHRIS: Oh, I love the sentence we should grep now. [laughter] The correct response to this is to grep immediately. I thought you were going to go with the pro tip of you can just focus down to one context block. And then the specs will run so much faster because you're ignoring most of them, but we don't want to do that. The sleep, though, that's a pro tip. And that does feel like a thing that there could be a cop for, like, never sleep more than...frankly, let's try not to sleep at all but also, add a sleep in our specs. We can sleep in life; it's important, but anyway. [chuckles] STEPH: [laughs] That was the second hot tip, and you got it. CHRIS: Lots of hot tips. Well, I'm going to put this in the category of good idea, terrible idea. I won't call it a hot tip. It's a thing we're trying. So much as we have tried to build a spec suite that is consistent and deterministic and tells us only the truth, feature specs, even in our best efforts, still end up flaking from time to time. We'll have feature specs that fail, and then eventually, on a subsequent rerun, they will pass. And I am of the mindset that A, we should try and look into those and see if there is a real cause to it. But sometimes, just the machinery of feature specs, there's so much going on there. We've got the additional overhead of we're running it within a JavaScript context. There's just so much there that...let me say what I did, and then we can talk more about the context. So there's a gem called RSpec::Retry. It comes from the wonderful folks over at NoRedInk, a well-known Elm shop for anyone out there in the Elm world. But RSpec::Retry does basically what it says in the name. If the spec fails, you can annotate specs. In our case, we've only enabled this for the feature specs. And you can tell it to retry, and you can say, "Retry up to this many times," and et cetera, et cetera. So I have enabled this for our feature specs. And I've only enabled it on CI. That's an important distinction. This does not run locally. So if you run a feature spec and it fails locally, that's a good chance for us to intervene and look at whether or not there's some flakiness there. But on CI, I particularly don't want the case where we have a pull request, everything's great, and we merge that pull request, and then the subsequent rebuild, which again, as a note, I would rather that Circle not rebuild it because we've already built that one. But that is another topic that I have talked about in the past, and we'll probably talk about it again in the future. But setting that aside, Circle will rebuild on the main branch when we merge in, and sometimes we'll see failures there. And that's where it's most painful. Like, this is now the deploy queue. This is trying to get this out into whatever environment we're deploying to. And it is very sad when that fails. And I have to go in and manually say, hey, rebuild. I know that this works because it just worked in the pull request, and it's the same commit hash. So I know deterministically for reasons that this should work. And then it does work on a rebuild. So we introduced RSpec::Retry. We have wrapped it around our feature specs. And so now I believe we have three possible retries. So if it fails once, it'll try it again, and then it'll try it a third time. So far, we've seen each time that it has had to step in; it will pass on the subsequent run. But I don't know; there was some very gentle pushback or concerns; let's call them when I introduced this pull request from another developer on the team, saying, "I don't know, though, I feel like this is something that we should solve at the root layer. The failures are a symptom of flaky tests, or inconsistency or et cetera, and so I'd rather not do this." And I said, "Yeah, I know. But I'm going to merge it," and then I merged it. We had a better conversation about that. I didn't just broadly overrule. But I said, "I get it, but I don't see the obvious place to shore this up. I don't see where we're doing weird inconsistent things in our code. This is just, I think, inherent complexity of feature specs." So I did it, but yeah, good idea, terrible idea. What do you think, Steph? Maybe terrible is too strong of a word. Good idea, mediocre idea. STEPH: I like the original branding. I like the good idea, terrible idea. Although you're right, that terrible is a very strong branding. So I am biased right now, so I'm going to lead in answering your question by stating that because our current project has that problem as well where we have these flaky tests. And it's one of those that, yes, we need to look at them. And we have fixed a large number of them, but there are still more of them. And it becomes a question of are we actually doing something wrong here that then we need to fix? Or, like you said, is it just the nature of these features-specs? Some of them are going to occasionally fail. What reasonable improvements can we make to address this at the root cause? I'm interested enough that I haven't heard of RSpec::Retry that I want to check it out because when you add that, you annotate a test. When a test fails, does it run the entire build, or will it rerun just that test? Do you happen to know? CHRIS: Just the test. So it's configured as in a round block on the feature specs. And so you tell it like, for any feature spec, it's like config.include for feature specs RSpec::Retry or whatever. So it's just going to rerun the one feature spec that failed when and if that happens. So it's very, very precise as well in that sense where when we have a failure merging into the main branch, I have to rebuild the whole thing. So that's five or six minutes plus whatever latency for me to notice it, et cetera, whereas this is two more seconds in our CI runtime. So that's great. But again, the question is, am I hiding? Am I dealing with the symptoms and not the root cause, et cetera? STEPH: Is there a report that's provided at the end that does show these are the tests that failed and we had to rerun them? CHRIS: I believe no-ish. You can configure it to output, but it's just going to be outputting to standard out, I believe. So along with the sea of green dots, you'll see had to retry this one. So it is visible, but it's not aggregated. And the particular thing is there's the JUnit reporter that we're using. So the XML common format for this is how long our tests took to run, and these ones passed and failed. So Circle, as a particular example, has platform-level insights for that kind of stuff. And they can tell you these are your tests that fail most commonly. These are the tests that take the longest run, et cetera. I would love to get it integrated into that such that retried and then surface this to Circle. Circle could then surface it to us. But right now, I don't believe that's happening. So it is truly I will not see it unless I actively go search for it. To be truly honest, I'm probably not doing that. STEPH: Yeah, that's a good, fair, honest answer. You mentioned earlier that if you want a test to retry, you have to annotate the test. Does that mean that you get to highlight specific tests that you're marking those to say, "Hey, I know that these are flaky. I'm okay with that. Please retry them." Or does it apply to all of them? CHRIS: I think there are different ways that you can configure it. You could go the granular route of we know this is a flaky spec, so we're going to only put the retry logic around it. And that would be a normal RSpec annotation sort of tagging the spec, I think, is the terminology there. But we've configured it globally for all feature specs. So in a spec support file, we just say config.include Rspec::Retry where type is a feature. And so every feature spec now has the possibility to retry. If they pass on the first pass, which is the hope most of the time, then they will not be tried. But if they don't, if they fail, then they'll be retried up to three times or up to two additional times, I think is the total. STEPH: Okay, cool. That's helpful. So then I think I have my answer. I really think it's a good idea to automate retrying tests that we have identified that are flaky. We've tried to address the root, and our resolution was this is fine. This happens sometimes. We don't have a great way to improve this, and we want to keep the test. So we're going to highlight that this test we want to retry. And then I'm going to say it's not a great idea to turn it on for all of them just because then I have that same fear about you're now hiding any flaky tests that get introduced into the system. And nobody reasonably is going to go and read through to see which tests are going to get retried, so that part makes me nervous. CHRIS: I like it. I think it's a balanced and reasonable set of good and terrible idea. Ooh, it's perfect. I don't think we've had a balanced answer on that yet. STEPH: I don't think so. CHRIS: This is a new outcome for this segment. I agree. Ideally, in my mind, it would be getting into that XML format, the output from the tests, so that we now have this artifact, we can see which ones are flaky and eventually apply effort there. What you're saying feels totally right of we should be more particular and granular. But at the same time, the failure mode and the thing that I'm trying, I want to keep deploys going. And I only want to stop deploys if something's really broken. And if a spec retries, then I'm fine with it is where I've landed, particularly because we haven't had any real solutions where there was anything weird in our code. Like, there's just flakiness sometimes. As I say it, I feel like I'm just giving up. [laughs] And I can hear this tone of stuff's just hard sometimes, and so I've taken the easy way out. And I guess that's where I'm at right now. But I think what you're saying is a good, balanced answer here. I like it. I don't know if I'm going to do anything about it, but...[laughter] STEPH: Well, going back to when I was saying that I'm biased, our team is feeling this pain because we have flaky tests. And we're creating tickets, and we're trying to do all the right things. We create a ticket. We have that. So it's public. So people know it's been acknowledged. If someone's working on it, we let the team know; hey, I'm working on this. So we're not duplicating efforts. And so, we are trying to address all of them. But then some of them don't feel like a great investment of our time trying to improve. So that's what I really do like about the RSpec::Retry is then you can still have a resolution. Because it's either right now your resolution is to fix it or to change the code, so then maybe you can test it in a different way. There's not really a good medium step there. And so the retry feels like an additional good outcome to add to your tool bag to say, hey, I've triaged this, and this feels reasonable that we want to retry this. But then there's also that concern of we don't want to hide all of these flaky tests from ourselves in case we have done it and there is an opportunity for us to improve it. So I think that's what I do really like about it because right now, for us, when a test fails, we have to rerun the entire build, and that's painful. So if tests are taking about 20 minutes right now, then one spec fails, and then you have to wait another 20 minutes. CHRIS: I would have turned this on years ago with a 20-minute build time. [chuckles] STEPH: [laughs] Yeah, you're not wrong. But also, I didn't actually know about RSpec::Retry until today. So that may be something that we introduce into our application or something that I bring up to the team to see if it's something that we want to add. But it is interesting that initial sort of ooh kind of feeling that the team will give you introducing because it feels bad. It feels wrong to be like, hey, we're just going to let these flaky tests live on, and we're going to automate retrying them to at least speed us up. And it's just a very interesting conversation around where we want to invest our time and between the risk and pay off. And I had a similar experience this week where I had that conversation, but this one was more with myself where I was working through a particular issue where we have a state in the application where something weird was done in the past that led us to a weird state. And so someone raised a very good question where it's like, well, if what you're saying is technically an impossible state, we should make it impossible, like at the database layer. And I love that phrase. And yet, there was a part of me that was like, yes, but also doing that is not a trivial investment. And we're here because of a very weird thing that happened before. It felt one of those interesting, like, do we want to pursue the more aggressive, like, let's make this impossible for the future? Or do we want to address it for now and see if it comes back up, and then we can invest more time in it? And I had a hard time walking myself through that because my initial response was, well, yeah, totally, we should make it impossible. But then I walked through all the steps that it would take to make that happen, and it was not very trivial. And so it was one of those; it felt like the change that we ended up with was still an improvement. It was going to prevent users from seeing an error. It was still going to communicate that this state is an odd state for the application to be in. But it didn't go as far as to then add in all of the safety measures. And I felt good about it. But I had to convince myself to feel good about it. CHRIS: What you're describing there, the whole thought sequence, really feels like the encapsulation of it depends. And that being part of the journey of learning how to do software development and what it means. And you actually shared a wonderful video with me yesterday, and it was Cassidy Williams at GitHub Universe. And it was her talking to her younger self, and just it depends, and it was so true. So we will include a link to that in the show note because that was a wonderful thing for you to share. And it really does encapsulate this thing. And from the outside, before I started doing software development, I'm like, it's cool. I'm going to learn how to sling code and fix the stuff and hack, and it'll be great, and obvious, and correct, and knowable. And now I'm like, oh man, squishy nonsense. That's all it is. STEPH: [laughs] CHRIS: Fun squishy, and I like it. It's so good. But it depends. Exactly that one where you're like, I know that there's a way to get to correctness here but is it worth the effort? And looping back to...I'm surprised at the stance that I've taken where I'm just like, yeah, I'm putting in RSpec::Retry. This feels like the right thing. I feel good about this decision. And so I've tried to poke at it a tiny bit. And I think what matters to me deeply in a list of priorities is number one correctness. I care deeply that our system behaves correctly as intended and that we are able to verify that. I want to know if the system is not behaving correctly. And that's what we've talked about, like, if the test suite is green, I want to be able to deploy. I want to feel confident in that. Flaky specs exist in this interesting space where if there is a real underlying issue, if we've architected our system in a way that causes this flakiness and that a user may ever experience that, then that is a broken system. That is an incorrect system, and I want to resolve that. But that's not the case with what we're experiencing. We're happy with the architecture of our system. And when we're resolving it, we're not even really resolving them. We're just rerunning manually at this point. We're just like, oh, that spec flaked. And there's nothing to do here because sometimes that just happens. So we're re-running manually. And so my belief is if I see all green, if the specs all pass, I know that I can deploy to production. And so if occasionally a spec is going to flake and retrying it will make it pass (and I know that pass doesn't mean oh, this time it happened to pass; it's that is the correct outcome) and we have a false negative before, then I'm happy to instrument the system in a way that hides that from me because, at this point, it does feel like noise. I'm not doing anything else with the failures when we were looking at them more pointedly. I'm not resolving those flaky specs. There are no changes that we've made to the underlying system. And they don't represent a failure mode or an incorrectness that an end-user might see. So I honestly want to paper over and hide it from myself. And that's why I've chosen this. But you can see I need to defend my actions here because I feel weird. I feel a little off about this. But as I talk through it, that is the hierarchy. I care about correctness. And then, the next thing I care about is maintaining the deployment pipeline. I want that to be as quick and as efficient as possible. And I've talked a bunch about explorations into the world of observability and trying to figure out how to do continuous deployment because I think that really encourages overall better engineering outcomes. And so first is correctness. Second is velocity. And flaky specs impact velocity heavily, but they don't actually impact correctness in the particular mode that we're experiencing them here. They definitely can. But in this case, as I look at the code, I'm like, nah, that was just noise in the system. That was just too much complexity stacked up in trying to run a feature spec that simulates a browser and a user clicking in JavaScript and all this stuff and the things. But again, [laughs] here I am. I am very defensive about this apparently. STEPH: Well, I can certainly relate because I was defending my answer to myself earlier. And it is really interesting what you're pointing out. I like how you appreciate correctness and then velocity, that those are the two things that you're going after. And flaky tests often don't highlight an incorrect system. It is highlighting that maybe our code or our tests are not as performant as we would like them to be, but the behavior is correct. So I think that's a really important thing to recognize. The part where I get squishy is where we have encountered on this project some flaky tests that did highlight that we had incorrect behavior, and there's only been maybe one or two. It was rare that it happened, but it at least has happened once or twice where it highlighted something to us that when tests were run...I think there's a whole lot of context. I won't get into it. But essentially, when tests were being run in a particular way that made them look like a flaky test, it was actually telling us something truthful about the system, that something was behaving in a way that we didn't want it to behave. So that's why I still like that triage that you have to go through. But I also agree that if you're trying to get out at a deploy, you don't want to have to deal with flaky tests. There's a time to eat your vegetables, and I don't know if it's when you've got a deploy that needs to go out. That might not be the right time to be like, oh, we've got a flaky test. We should really address this. It's like, yes; you should note to yourself, hey, have a couple of vegetables tomorrow, make a ticket, and address that flaky test but not right now. That's not the time. So I think you've struck a good balance. But I also do like the idea of annotating specific tests instead of just retrying all of them, so you don't hide anything from yourself. CHRIS: Yeah. And now that I'm saying it and now that I'm circling back around, what I'm saying is true of everything we've done so far. But it is possible that now this new mode that the system behaves in where it will essentially hide flaky specs on CI means that any new flaky regressions, as it were, will be hidden from us. And thus far, almost all or I think all of the flakiness that we've seen has basically been related to timeouts. So a different way to solve this would potentially be to up the Capybara wait time. So there are occasionally times where the system's churning through, and the various layers of the feature specs just take a little bit longer. And so they miss...I forget what it is, but it's like two seconds right now or something like that. And I can just bump that up and say it's 10 seconds. And that's a mode that if eventually, the system ends in the state that we want, I'm happy to wait a little longer to see that, and that's fine. But there are...to name some of the ways that flaky tests can actually highlight truly incorrect things; race conditions are a pretty common one where this behaves fine most of the time. But if the background job happens to succeed before the subsequent request happens, then you'll go to the page. That's a thing that a real user may experience, and in fact, it might even be more likely in production because production has differential performance characteristics on your background jobs versus your actual application. And so that's the sort of thing that would definitely be worth keeping in mind. Additionally, if there are order issues within your spec suite if the randomize...I think actually RSpec::Retry wouldn't fix this, though, because it's going to retry within the same order. So that's a case that I think would be still highlighted. It would fail three times and then move on. But those we should definitely deal with. That's a test-related thing. But the first one, race conditions, that's totally a thing. They come up all the time. And I think I've potentially hidden that from myself now. And so, I might need to lock back what I said earlier because I feel like it's been true thus far that that has not been the failure mode, but it could be moving forward. And so I really want to find out if we got flaky specs. I don't know; I feel like I've said enough about this. So I'm going to stop saying anything new. [laughs] Do you have any other thoughts on this topic? STEPH: Our emotions are a pendulum. We swing hard one way, and then we have to wait till we come back and settle in the middle. But there's that initial passion play where you're really frustrated by something, and then you swing, and you settle back towards something that's a little more neutral. CHRIS: I don't trust anyone who pretends like their opinions never change. It doesn't feel like a good way to be. STEPH: Oh, I hope that...Do people say that? I hope that's not true. I hope we are all changing our opinions as we get more information. CHRIS: Me too. Mid-roll Ad And now a quick break to hear from today's sponsor, Scout APM. Scout APM is leading-edge application performance monitoring that's designed to help Rails developers quickly find and fix performance issues without having to deal with the headache or overhead of enterprise platform feature bloat. With a developer-centric UI and tracing logic that ties bottlenecks to source code, you can quickly pinpoint and resolve those performance abnormalities like N+1 queries, slow database queries, memory bloat, and much more. Scout's real-time alerting and weekly digest emails let you rest easy knowing Scout's on watch and resolving performance issues before your customers ever see them. Scout has also launched its new error monitoring feature add-on for Python applications. Now you can connect your error reporting and application monitoring data on one platform. See for yourself why developers call Scout their best friend and try our error monitoring and APM free for 14 days; no credit card needed. And as an added-on bonus for Bike Shed listeners, Scout will donate $5 to the open-source project of your choice when you deploy. Learn more at scoutapm.com/bikeshed. That's scoutapm.com/bikeshed. CHRIS: Well, shifting only ever so slightly because it turns out it's a very related question, but we have a listener question. As always, thank you so much to everyone who sends in listener questions. We really appreciate them. And today's question comes from Mikhail, and he writes in, "Regarding the discussion in Episode 311 on requiring commits merged to be tested, I have a question on how you view multi commit PRs. Do you think all the commits in a PR should be tested or only the last one? If you test all commits in a PR, do you have any good tips on setups for that? Would you want all commits to pass all tests? For one, it helps a lot when using Git bisect. It is also a question of keeping the history clean and understandable. As a background on the project I currently work on, we have the opinion that all commits should be tested and working. We have now decided on single commit PRs only since this is the only way that we can currently get the setup reasonably on our CI. I would like to sometimes make PRs with more than one commit since I want to make commits as small as possible. In order to do that, we would have to find a way to make sure all commits in the PR are tested. There seems to be some hacky ways to accomplish this, but there is not much talk about it. Also, we are strict in requiring a linear history in all our projects. Kind regards, Mikhail." So, Steph, what do you think? STEPH: I remember reading this question when it came in. And I have an experience this week that is relevant to this mainly because I had seen this question, and I was thinking about it. And off the cuff, I haven't really thought about this. I haven't been very concerned about ensuring every single commit passes because I want to ensure that, ultimately, the final commit that I have is going in. But I also rarely have more than one commit in a PR. So that's often my default mode. There are a couple of times that I'll have two, maybe three commits, but I think that's pretty rare for me. I'll typically have just one commit. So I haven't thought about this heavily. And it's not something that frankly I've been concerned about or that I've run into issues with. From their perspective about using Git bisect, I could see how that could be troublesome, like if you're looking at a commit and you realize there's a particular commit that's already merged and that fails. The other area that I could think of where this could be problematic is if you're trying to roll back to a specific commit. And if you accidentally roll back to a commit that is technically broken, but you didn't know that because it was not the final commit as was getting tested on CI, that could happen. I haven't seen that happen. I haven't experienced it. So while that does seem like a legitimate concern, it's also one that I frankly just haven't had. But because I read this question from this person earlier this week, I actually thought about it when I was crafting a PR that had several commits in it, which is kind of unusual for me since I'm usually one or two commits in a PR. But for this one, I had several because we use standard RB in our project to handle all the formatting. And right now, we have one of those standard to-do files because we added it to the project. But there are still a number of manual fixes that need to be applied. So we just have this list of files that still need to be formatted. And as someone touches that file, we will format it, and then we'll take it out of that to-do list. So then standard RB will include it as it's linting all of our files. And I decided to do that for all of our spec files. Because I was like, well, this was the safest chunk of files to format that will require the least amount of review from folks. So I just want to address all of them in one go. But I separated the more interesting changes into different commits just to make others aware of, like, hey, this is something standard RB wants. And it was interesting enough that I thought I would point it out. So my first commit removed all the files from that to-do list, but then my other commits are the ones that made actual changes to some of those files that needed to be corrected. So technically, one or two of my middle commits didn't pass the standard RB linting. But because CI was only running that final commit, it didn't notice that. And I thought about this question, and so I intentionally went back and made sure each of those commits were correct at that point in time. And I feel good about that. But I still don't feel the need to add more process around ensuring each commit is going to be green. I think I would lean more in favor of let's keep our PR small to one or two commits. But I don't know; it's something I haven't really run into. It's an interesting question. How about you? What are your experiences, or what are your thoughts on this, Chris? CHRIS: When this question came through, I thought it was such an interesting example of considering the cost of process changes. And to once again reference one of our favorite blog posts by German Velasco, the Say No to More Process post, which we will, of course, link in the show notes. This is such a great example of there was likely a small amount of pain that was felt at one point where someone tried to run git bisect. They ran into a troublesome commit, and they were like, oh no, this happened. We need to add processes, add automation, add control to make sure this never happens again. Personally, I run git bisect very rarely. When I do, it's always a heroic moment just to get it started and to even know which is the good and which is the bad. It's always a thing anyway. So it would be sad if I ran into one of these commits. But I think this is a pretty rare outcome. I think in the particular case that you're talking about, there's probably a way to actually tease that apart. I think it sounds like you fixed those commits knowing this, maybe because you just put it in your head. But the idea that the process that this team is working on has been changed such that they only now allow single commit PRs feels like too much process in my mind. I think I'm probably 80%, maybe 90% of the time; it's only a single commit in a PR for me. But occasionally, I really value having the ability to break it out into discrete steps, like these are all logically grouped in one changeset that I want to send through. But they're discrete steps that I want to break apart so that the team can more easily review it so that we have granular separation, and I can highlight this as a reference. That's often something that I'll do is I want this commit to standalone because I want it to be referenced later on. I don't want to just fold it into the broader context in which it happened, but it's pretty rare. And so to say that we can't do that feels like we're adding process where it may not be worth it, where the cost of that process change is too high relative to the value that we're getting, which is speculatively being able to run git bisect and not hit something problematic in the future. There's also the more purist, dogmatic view of well, all commits should be passing, of course. Yeah, I totally agree with that. But what's it worth to you? How much are you willing to spend to achieve that goal? I care deeply about the correctness of my system but only the current correctness. I don't care about historical correctness as much, some. I think I'm diminishing this more than I mean to. But really back to that core question of yes, this thing has value, but is it worth the cost that we have to pay in terms of process, in terms of automation and maintenance of that automation over time, et cetera or whatever the outcome is? Is it worth that cost? And in this case, for me, this would not be worth the cost. And I would not want to adopt a workflow that says we can only ever have single commit PRs, or all commits must be run on CI or any of those variants. STEPH: This is an interesting situation where I very much agree with everything you're saying. But I actually feel like what Mikhail wants in this world; I want it too. I think it's correct in the way that I do want all the commits to pass, and I do want to know that. And I think since I do fall into the default, like you mentioned, 80%, 90% of my PRs are one commit. I just already have that. And the fact that they're enforcing that with their team is interesting. And I'm trying to think through why that feels cumbersome to enforce that. And I'm with you where I'll maybe have a refactor commit or something that goes before. And it's like, well, what's wrong with splitting that out into a separate PR? What's the pain point of that? And I think the pain point is the fact that one, you have two PRs that are stacked on each other. So you have the first one that you need to get reviewed, and then the second one; there's that bit of having to hop between the two if there's some shared context that someone can't just easily review in one pull request. But then there's also, as we just mentioned, there's CI that has to run. And so now it's running on both of them, even though maybe that's a good thing because it's running on both commits. I like the idea that every commit is tested, and every commit is green. But I actually feel like it's some of our other processes that make it cumbersome and hard to get there. And if CI did run on every commit, I think it would be ideal, but then we are increasing our CI time by running it on every commit. And then it comes down to essentially what you said, what's the risk? So if we do merge in a commit that doesn't work or has something that's failing about it but then the next commit after that fixes it, what's the risk that we're going to roll back to that one specific commit that was broken? If that's a high risk for you and your team, then adding this process is probably the really wise thing to do because you want to make sure the app doesn't go down for users. That's incredibly important. If that's not a high risk for your team, then I wouldn't add the process. CHRIS: Yeah, I totally agree. And to clarify my stances, for me, this change, this process change would not be worth the trade-off. I love the idea. I love the goal of it. But it is not worth the process change, and that's partly because I haven't particularly felt the pain. CI is not an inexhaustible resource I have learned. I'm actually somewhat proud our very small team that is working on the project that we're working on; we just recently ran out of our CI budget, and Circle was like, "Hey, we got to charge you more." And I was like, "Cool, do that." But it was like, there is cost both in terms of the time, clock time, and each PR running and all of those. We have to consider all of these different things. And hopefully, we did a useful job of framing the conversation, because as always, it depends, but it depends on what. And in this case, there's a good outcome that we want to get to, but there's an associated cost. And for any individual team, how you weigh the positive of the outcome versus how you weigh the cost will alter the decision that you make. But that's I think, critically, the thing that we have to consider. I've also noticed I've seen this conversation play out within teams where one individual may acutely feel the pain, and therefore they're anchored in that side. And the cost is irrelevant to them because they're like, I feel this pain so acutely, but other people on the team aren't working in that part of the codebase or aren't dealing with bug triage in the same way that that other developer is. And so, even within a team, there may be different levels of how you measure that. And being able to have meaningful conversations around that and productively come to a group decision and own that and move forward with that is the hard work but the important work that we have to do. STEPH: Yeah. I think that's a great summary; it depends. On that note, shall we wrap up? CHRIS: Let's wrap up. The show notes for this episode can be found at bikeshed.fm. STEPH: This show is produced and edited by Mandy Moore. CHRIS: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes, as it really helps other folks find the show. STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari. CHRIS: And I'm @christoomey STEPH: Or you can reach us at hosts@bikeshed.fm via email. CHRIS: Thanks so much for listening to The Bike Shed, and we'll see you next week. All: Byeeeeeeeeee! Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

In this episode, Cassidy Williams brings The Parent Trap to the pod. Together, Cassidy, Chloe, and Sarah discuss this 1998 film (and a bit of the 1961 version) and realize that Meredith Blake is truly an icon and the definition of an adult. You can find Cassidy online at https://cassidoo.co/ and on Twitter, GitHub, Twitch, YouTube, and TikTok. --- This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app Support this podcast: https://anchor.fm/saluteyourskorts/support

Go get your copy of They Key here.Our frequent collaborator, Cassidy Williams of Netlify, helped design the key and joined this episode to share her love for all things mechanical keyboard. 

Go get your copy of They Key here.Our frequent collaborator, Cassidy Williams of Netlify, helped design the key and joined this episode to share her love for all things mechanical keyboard. 

Cassidy Williams first made waves as one of Glamour's 35 Women Under 35 Who Are Changing Tech.... now she's making waves in roughly 100 different ways, including Twitter and TikTok. Join our chat with this very friendly meme-lady and dev advocate, who has a lot to say on everything from mechanical keyboards to how to stay active without getting exhausted. Timestamps 1:48 Learning by teaching 4:00 What's a developer advocate? 12:00 What's her biggest TikTok flop? 15:00 - Trumpets and the all-electric guitar band 17:15 - How do you handle multitasking? 25:00 - "Get glamorous with Cassidy" AKA Glamour Magazine 35 under 35 27:30 - Everything about mechanical keyboards 35:45 - K-drama drama 41:30 - Remote life tips - the stretch & share! 43:00 - Best tracking apps (spoiler: it's Obsidian) Check out the home for untold developer stories around open source, careers and all the other cool stuff developers are doing at cult.honeypot.io. Honeypot is a developer-focused job platform, on a mission to get developers great jobs. Wanna see what we're all about? Visit honeypot.io to find a job you love. To learn more about Honeypot: http://www.honeypot.io/?utm_source=youtube Follow Them: Website: https://cassidoo.co/ TikTok: https://www.tiktok.com/@cassidoo/ Twitter: https://twitter.com/cassidoo Follow us: Twitter: https://twitter.com/honeypotio YouTube: https://www.youtube.com/c/Honeypotio/Instagram: https://www.instagram.com/honeypot.cult/ Relevant links: https://beat-pose.netlify.app/ https://obsidian.md/ https://www.netlify.com/blog/2021/01/06/developer-experience-at-netlify/

About LaurieLaurie is a Senior Software Engineer at Netflix. You can also find her creating content and educating the technology industry as an egghead instructor, member of the TC39 Educators committee, and technical blogger.Links: Twitter: https://twitter.com/laurieontech Netflix: https://www.netflix.com Egghead: https://egghead.io The Art of the Subtle Subtweet: https://laurieontech.com/book-launch/ TranscriptAnnouncer: 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.Corey: You could build you go ahead and build your own coding and mapping notification system, but it takes time, and it sucks! Alternately, consider Courier, who is sponsoring this episode. They make it easy. You can call a single send API for all of your notifications and channels. You can control the complexity around routing, retries, and deliverability and simplify your notification sequences with automation rules. Visit courier.com today and get started for free. If you wind up talking to them, tell them I sent you and watch them wince—because everyone does when you bring up my name. Thats the glorious part of being me. Once again, you could build your own notification system but why on god's flat earth would you do that?Corey: This episode is sponsored in part by our friends at VMware. Let's be honest—the past year has been far from easy. Due to, well, everything. It caused us to rush cloud migrations and digital transformation, which of course means long hours refactoring your apps, surprises on your cloud bill, misconfigurations and headache for everyone trying manage disparate and fractured cloud environments. VMware has an answer for this. With VMware multi-cloud solutions, organizations have the choice, speed, and control to migrate and optimizeapplications seamlessly without recoding, take the fastest path to modern infrastructure, and operate consistently across the data center, the edge, and any cloud. I urge to take a look at vmware.com/go/multicloud. You know my opinions on multi cloud by now, but there's a lot of stuff in here that works on any cloud. But don't take it from me thats: VMware.com/go/multicloud and my thanks to them again for sponsoring my ridiculous nonsense.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by Laurie Barth, but no one really knows that's her last name. In fact, @laurieontech is how most people think of her. She's a senior software engineer at a company called Netflix, which primarily streams movies and gives conference talks—in the before times—about how you're doing it wrong.She also creates a lot of content and educates the technology industry as an instructor at Egghead. She's a member of the TC39 Educator's Committee, and of course, is a technical blogger. Laurie, thank you for suffering the slings and arrows I'm no doubt going to be hurtling your way.Laurie: This is the most fun I've had all week. [laugh].Corey: Well, it's a pandemic on, so presumably that isn't that high of a bar for the pony to stumble over.Laurie: Yeah, unfortunately not. I think that's maybe the problem.Corey: So, you're someone that I have been aware of for an awfully long time. You're always sort of omnipresent in conversations. You are someone who has a lot of great opinions that present well; you talk about an awful lot of things that are germane to my interests, educating the next generation of engineers, for example. And of course, you recently started at Netflix, at which point, well, if you're not familiar with what Netflix is doing in the cloud, have you ever even talked to an AWS employee for more than 35 seconds because they'll go reference Netflix for a variety of wonderful reasons, both based on technical excellence, as well as because AWS is so bad at telling the story of what you can build out of their popsicle stick service collection that they just punt to companies like Netflix to demonstrate what you could do. So, you're sort of this omnipresent force on Twitter, but we've never really had a conversation before, so it was long past time to rectify this.Laurie: I mean, you sent me two cents. So… I think that was pretty—[laugh].Corey: That's what the Tip Jar is for. You just wind up hurling very small amounts of money at people along with insulting comments, and it's a new form of social media. That is the micro-transaction way.Laurie: I quite enjoyed that. So, for context, I was one of the first people to be part of the A/B testing for Tip Jar on Twitter and Corey was the first person to send me money with, of course, a very on-brand Corey message, which there's a screenshot of on Twitter somewhere. And a couple of people followed, but it was great fun. And I think that's the first time we had ever directly interacted in a message or something, other than obviously, in threads and that sort of thing.Corey: Yeah, that's an interesting point to lead into here because I'm also in the A/B test for Tip Jar and I've largely turned it off, except for when I'm doing something very small and very focused, usually aimed at some sort of charitable benefit or whatnot, and even then, it's not the right way to do it. And it's weird, there was a time I absolutely would have turned it on, but it doesn't seem right for me to do it now and that's partially due to the fact that—first, I don't need tips from the audience in order to sustain myself. I'm not that kind of creator. I have a company that solves very expensive problems for large companies and that works out really well for, you know, keeping the lights on here.I'm not trying to disparage creators in any way, folks who are in a position of needing that to cover their lifestyle a variety of different ways. And even if they're well beyond that, I don't begrudge that to them at all. I mean, from a very selfish capitalist perspective, I don't want you to feel that you've paid your debt to me for entertaining you by sending me $5. I want you to repay that debt by signing a five-figure consulting agreement.Laurie: Yeah, those aren't really the same thing, are they?Corey: No, no. Turns out signing authority caps out at different places for different folks.Laurie: [laugh].Corey: Who knew? But it was a fun experiment. I'm glad that they're doing it. I'm glad to see Twitter coming out of its stasis for a long time and trying new things, even if we don't like some of them.Laurie: Well, they have this whole Super Follows thing now, and I got waitlisted for it the other day because they said they accepted too many people, whatever that means. I think—Corey: Same here.Laurie: Yeah, I think a bunch of us got that. And I'm interested, my sense is it's sort of like a Patreon hosted in Twitter sort of thing. And I've never had a Patreon; I have a mailing list that I made based on an April Fool's joke this past year where I made an entire signup workflow for the pre-order of my new book, The Art of the Subtle Subtweet. I was very pleased with this joke.This was, like, very elaborate: I had a whole website, I had a signup flow, and I now have a mailing list which I've done nothing with. So, I have all of these things, but that's not really been my—there's too many things to do as a content creator, and so I've sort of not explored most of those other avenues. And so, Super Follows, I was like, “This could be interesting. I could try doing it,” but, you know, alas, they don't want me to. So, [laugh] I don't know that it matters.Corey: It's an interesting problem, too, because at the start of the pandemic, I had a third of the Twitter followers that I do as of the time of this recording, which is something like 63,000. When I started what I do, five years ago, and I had just left a company which was highly regulated, so, “Don't tweet,” was basically their social media policy, it was a, okay, I had something like 2000 followers at the time. I was—it had taken me seven years to get there, let's be very clear here. And since then, my following has exploded, and yours has as well. You have, I think the last time we checked, was it something like 30,000 and change?Laurie: Yeah, something like that.Corey: And it changes the way that people interact with you. This is one of those things that there aren't that many people that we can have this kind of honest conversation with because let's be very clear here, for folks who have not established an audience like that it sounds absolutely like it's either a humblebrag—which I'm not intending that to come across that way—or it's one of those, “Wish I had those problems.” And in some ways, yeah, it's a weird problem to have, and it's also not a sympathetic problem to have, but something that has been very clear to me has been that the way that people perceive me and the way that they interact with me has shifted significantly as my Twitter notoriety has increased.Laurie: Yeah.Corey: I'm curious about how you have experienced that?Laurie: Yeah, so I'm half your size and especially in the front-end universe, there's plenty of people with between 100,000 to, you know, I think Dan Abramov is at, like, 400,000 at this point. Like—Corey: Oh yeah, my Twitter following would explode if I either knew JavaScript or was funny. Either one would just absolutely kick me into the stratosphere, but we work with what we've got.Laurie: I either don't know JavaScript or I'm not funny or maybe both because apparently not. But yeah, there's these huge, huge, huge, huge scales, and I'm sure by many people's judgment, pretty, pretty large. But comparing to other people in my ecosystem, maybe not so much. And I didn't understand it until I was living it. I actually had the opportunity to meet Emily Freeman at a conference in DC, probably… three years ago now, when I had less than a thousand followers. And I thought getting my first hundred was a big deal; I thought getting my first 500—and it is. Don't get me wrong. Those things are very cool milestones. And I [crosstalk 00:07:18]—Corey: I still celebrate the milestones, but I do it less publicly now.Laurie: Yeah, exactly. And I had a whole conversation with her and she gave me some really, really helpful advice: sort of, don't look at your follower count as it goes back and forth, five people, six people you'll think people are unfollowing you; they're probably not. It doesn't matter. And recognize that the larger you get, the more careful you have to be, and try to keep me sane before I was ever there. And it's all sort of come true.There's two things that have stuck out to me, I think, during the pandemic, especially. One is I can write the most nonsensical, silly tweet and people will like it because they think it says something insightful whether it does or it doesn't. They're projecting onto the tweet something funnier, or more relevant than the reason I wrote it in the first place. Which, okay, that's cool. I'm not as smart as you're giving me credit for, but sure.The other thing which is the downside to that is, everyone assumes that if they're having a conversation with me, they're having a conversation with me. So one-on-one, back and forth. That's not untrue, but I'm having a similar conversation in parallel with—if it's a popular tweet—a hundred other people at the same time. And what that means is, if you're being a little bit of a jerk, and a little bit troll-y, you're not being a little bit troll-y, you're being a little bit troll-y times the a hundred other little bit troll-y people. And so my reaction to you is not going to be necessarily equivalent to what you say, and that can get me in trouble. But there's no mental, emotional spectrum that was designed to work with the scale of social media.Corey: Oh, absolutely not. In fact, let's do an experiment now, while we're having this conversation. I am making a tweet as we speak. “Some mornings, it's just not worth chewing through the leather straps.” It's not particularly insightful.It's not particularly deep, and before the end of this episode, we will check and see what that does in terms of engagement just because you can say anything, and there's some folks who will wind up automatically engaging. And again, that's fine; everyone engages with Twitter in a bunch of different ways. For me, what's been very odd is I have talked to a couple of very large companies who I talk about on Twitter from time to time, and it turns out that they are reluctant to engage with me directly on Twitter or promote anything that I do or do retweets of me, not because of me, but because of an element of the audience, in some cases, of what people will chime in and say because it doesn't align with corporate brands and a bunch of different perspectives. Which, again, I have some sympathy for this; it's hard to deal with folks who are now suddenly given a soapbox and a platform that rewards clever insults better than it does meaningful heartfelt content, and that is something that I think everyone is still struggling with. Let's also be very clear here. I'm a white dude in tech; my failure mode is a board seat and a book deal.Laurie: [laugh].Corey: When I post something about Git, for example—which I did a few days ago—and someone responds explaining the joke back to me, my response to them was, “Thank you for explaining Git to me.” And that was all I said, and it's led to a mini-pile-on of this person because it's like—Laurie: Oh, yeah.Corey: “Don't you know who Corey is?” Yet I have seen the same dynamic happen with women tweeting about these things and it's not just one response that explains Git; it's all of them. And when people say—like, Abby Fuller, for example—Laurie: Yep.Corey: —will tweet about password manager challenges and how annoying some of them are, and it leads to a cavalcade of people suggesting password managers to her. That is not why she's tweeting it, and she explicitly says, “I do not want you to recommend password managers to me.” And people continue to do it. And I don't for the life of me understand what goes on in some people's heads.Laurie: Yeah. I mean, I've watched that happen countless times. I think the frustration—there's a point at which no matter how big of a following you have, you just want to be yourself. I think most people who get to that amount of interaction have been theirself most of the way, along the way. Or they're just being totally fake for the sense of growth hacking, in which case, okay, you do you.But most people, I think, are being themselves because it's exhausting to spend that much time on a platform and pretend to be someone else or be fake the whole time. So, I'm pretty much myself. And that means that sometimes when someone's being a total jerk, I really want to treat them and be like, “Yeah, you suck.” But the problem is when I say that, I'm siccing 30,000 other people on them to defend me. And I can't do that.So instead, I've become sort of famous for subtweeting. And I will wait a couple of days to do it, or I will totally change the framing of the situation so I can get out my same sort of frustration, and annoyance, and just needing to blow off steam, or venting, or whatever it is and not point at the person. Because if I point at the person, I discovered very, very quickly that there's a whole crowd of people willing to take them down. If they're being blatantly terrible, I will do it. There is a line here.Someone recommending that I use a different tool because I decided to bitch about TypeScript, for example, or telling me I don't understand TypeScript, okay, fine. Someone's saying, “You only have followers because you're a pretty girl.” Yeah, you're an asshole. No, I'm not protecting you. Also, by the way, I tweeted two minutes ago, do all tweets deserve a ‘like,' question mark, and we'll see how much that—Corey: Yeah.Laurie: —interaction gets. [laugh].Corey: I'm looking forward to seeing how that plays out. It's a responsibility, which sounds odd, but if I complain about a company, what I'm fundamentally doing is I have the potential to be calling out an airstrike on top of them. And not every customer service failure deserves that. I deleted all of my tweets prior to 2015 a while back. And the reason most people delete tweets, or the reason we hear about most people deleting tweets, there was nothing especially problematic in my tweets other than jokes that were mean in different ways and punching down in ways that I didn't realize were at the time.It was not full of slurs; it was just things that weren't particularly great. But that wasn't the real reason I did it. The honest reason was is that I looked at my early tweets and they were cringy beyond belief. I was shilling for the company I worked for in many respects, and there were swaths which I didn't engage with Twitter, and the only time I really did is I was out there complaining about various customer service failures, so it's just this neverending stream of complaints about different companies that had wronged me in trivial ways.Laurie: [laugh].Corey: And, I don't know at some point if somebody is going to build something where it's easy to explore early tweets of a particular account. I don't want them to do that and then figure out that this is how you get started being me. It's like, I succeeded in spite of that nonsense, not because of it. And it's not something good that I want to put out into the world.Laurie: Yeah. So, I have, I think, only once added a company when I was having a customer service issue on a weekend, and we were in really dire straits. And I was just like, “Okay, it's a weekend. I'm going to at.” And I've never gotten a response so fast.And my husband looked at me and he was like, “Wait, what?” And I'd done this with an ol—I have this really ancient Twitter account that I got rid of because I was mostly just screaming about politics [laugh] and I didn't want—I think I got @laurieontech in like, 2016, 2017—and I'd done that before. I'd been like, “Hey, you know”—I'm making something up—“At Spirit Airlines”—they seem like an easy one to—I've never flown Spirit, so—but I mean, I never got a response. And so there—realizing that you have power from a brand perspective is really weird.But I almost want to go back to your point when you were talking about when you worked for a company and you had your account and, you know, they don't want you to tweet, basically. Or companies are not going to tweet at you now, in your current state. I think it's really hard to be a company on the internet in tech because you're either going to make a joke that lands well, or everyone's going to think that you're shilling for yourself. There's no in-between and so—this is a hot take and I might get in trouble for that—companies have realized that the best way to get around that is to hire people who have their own personal names and get your company name associated with them. And all of a sudden, it looks less disingenuous.Corey: And even that's a problem because I've talked to companies who are hiring folks with large followings for DevRel style jobs, and—I've interviewed for a few of those, once upon a time, about midway through when I was debating do I shut this consulting thing down and get a real job again because that's always how I sort of assumed it would be for the first couple years. And then, “No, I'm going to get serious about it.” And I took on a business partner and got very serious, and here we are. But talking to folks, my question was, in the interview process, I would talk to my prospective manager and ask questions of the form, “So, what is your plan for when we eventually part ways? How are you structuring that?”And they looked at me like that was a bizarre question. It's, understand that, done right, my personal brand will, in some areas and some corners, eclipse that of the company, so as soon as I leave for whatever reason, the question is going to be, “Were you mistreated? Did someone wrong you there? We'll drag them just preemptively on the off chance.” And you need to have a plan in place to mitigate some of that and have a structured exit for what that is going to look like. And they looked at me like I was coming from a different planet. But I still think I'm right.Laurie: You are right. And, oh goodness, I've seen this in a lot of different places. I mean, I have left companies in the past and I have had to decide how I was going to position that publicly. And how much I was going to say or not say, how complimentary I was going to be or not because the thing is, when you leave a place, you're not just leaving the company, you're also leaving your colleagues. And what does that mean for their experience?You're gone. You don't want to be saying, “Hey, this place is horrible, while your really close friends you were working with on Friday are still there.” At the same time, companies don't think about this from the DevRel perspective and, I want to be very clear, I have friends who work in DevRel who are themselves brands. They are all fantastic people; they work incredibly hard; this is not a knock on them in any way—Corey: It looks easy from the outside. I want to be very clear on that.Laurie: [laugh]. It's not easy. All this stuff is great, but part of the reason I decided to go to a place like Netflix is because I knew my brand had no bearing on them and so I could be myself and just do my own thing and they weren't going to try and leverage me, or there was no hit to them based on who I was. Granted, did I go after someone the other day, sort of, in deep in a thread for being a jerk and did they try and at Netflix engineering and say, “Is this the kind of person you want representing your brand?” And at egghead.io, “Is this the kind of person wanting your brand?” Yeah, they did.So, that part's still a problem, but that's a problem for me rather than being a problem for my company, if I decide that, you know, I don't always want to—like, no one cares if I talk about the new Marvel show. No one cares. I like Marvel; I'm allowed to like Marvel. I also love the stuff on Netflix, right, but when you're at a company that isn't like that, honestly, when I was at Gatsby, I couldn't be tweeting about Next or Nuxt, or even Vue for that matter, because it just doesn't look right. Because my brand had more of an impact in that smaller pond than it does now.Corey: People have said, “Oh, well, what if AWS acquires you so you can work on their behalf?” Or, “What if Google acquires you?” Or something like that, and it's—what people don't get is that my persona—again, to be clear, I am genuine on Twitter. I emphasize aspects of my personality, but I don't get up there and say things I don't necessarily believe. We'll get back to that in a minute.But what I do as a small company, making fun of trillion-dollar publicly traded entities is funny and it works, but if suddenly I work at a different publicly-traded company, it just looks like I work for my employer, bagging on a competitor. And even if I'm speaking in ‘an opinions my own' sense, which is apparently Amazon's corporate motto, based on how often I see it in their employee's Twitter bios—Laurie: Oh, yeah. [laugh].Corey: —is going to be perceived as me smacking at a competitor regardless. Further, I will not be the person that craps on my own employer on Twitter because that sends terrible signal in many respects. I won't even crap on previous employers who frankly kind of deserve it because when you do that, it does not look good to people who are not familiar with the situation, and no one's as familiar with it as you are. It just looks like sour grapes, regardless of how legitimate your grievance was. To be very clear, I'm not saying don't call out abuse when you encounter it—Laurie: Yeah.Corey: —that's fine. I'm not going down that path—Laurie: Yeah, yeah, yeah, yeah.Corey: —let's clear here. But, “Yeah, they have a terrible management culture, and they don't promote internally, and I hate those people,” it just makes you look bad, and it doesn't help anything.Laurie: Yeah. I had always made a commitment to never talk about a former employer in any way that was easily identifiable. I've changed that policy a little bit. There's a story I shared a couple of times where my CEO didn't want to give me a pay raise because he thought it was my parents' and boyfriend at the time's job to take care of me financially. Like, that kind of stuff, I will say publicly.No one's going to know who it is; you'd have to go back and figure it out and, like, you don't have enough context so how would you know? But it's stuff like that, that I'm like, okay. I don't want to hide stories like that because that's not protecting anybody.Corey: No, I'm not talking about covering up for misbehavior. I'm talking run-of-the-mill just bad management, poor company culture, terrible technical decisions, et cetera. Yeah, if it's like, yeah, they sexually harassed every woman on the team, out. Yeah, tell that story. I—thank you, I should absolutely clarify my stance. Heaven forbid I get letters.Laurie: But yeah, it's the problem is that you can't—and everyone has a slightly different experience with this, but from what I've seen, it doesn't matter if you say their management is shitty and they didn't promote versus there was a ton of sexual harassment. If you're one person saying it—if it's the Blizzard situation where there's tons of receipts and it's made it into national media, then that's a little bit different. But if you're one person saying it about one company, people are going to think it's sour grapes. And unfortunately, it doesn't reflect on the company; it reflects on you. So, unless there's a sort of like, where there's smoke, there's fire situation where a bunch of people are doing it at once, you have to weigh stuff really carefully.Especially because your next employer doesn't want you out there talking about your previous employer because then their fear is what are you going to say about them when you leave? There's lots of nuance and it gets—if you are screaming into the void—we're screaming into the cloud here—Corey: Ahhhh. Yes.Laurie: Ahhhh. [laugh]. If you're screaming into the void, it doesn't matter if you're you. And I mean… [sigh] I hate saying, “If you're me,” right? That's such an obnoxious statement to make, but at 30,000, they probably care.Corey: There are inflection points. I started seeing—around 40,000 is when I started seeing a couple of brands reaching out to me to, “Hey, you want to promote some nonsense.” And I've never sold any social media promotion for anything. I sell sponsorships for newsletters, this podcast, I do webinars stuff, I do paid speaking engagements. My Twitter account is mine.It is not the company's and that is by design. It's me; that's what it comes down to. That does lead to challenges in some arenas because I talk to companies about their AWS bill and these companies do not have much of a sense of humor about spending tens of millions of dollars, in some cases a month, on a cloud provider. These are serious problems and they're a little worried, in some cases, the first time we have conversations that they're dealing with some kind of internet clown.Laurie: [laugh].Corey: And often with talking to folks to convince them to come on this podcast, it's, “Look, this is not me dragging you and making you look awful because if I do that, I'll never get another guest again.” And if I do it in the context of a consulting project it's, “That was a hilarious entertaining intro here. Get out and never come back.” It is not useful. People have generally taken a risk personally on bringing the Duckbill Group in.If we can't deliver and cannot present professionally, then they have some serious damage control to do, for a variety of excellent reasons. And we've never put someone in that position and we won't. I talked to brands who sponsor all of these things, and the ones that are the best sponsors intrinsically understand it, that [unintelligible 00:23:56] once I start getting after some serious maleficence style stuff—no one is going to not do business with you because I make fun of your company on Twitter—Laurie: Yeah.Corey: —but an awful lot of people are going to hear about you for the first time and advertising in the newsletter and having fun with that, or I talk about you in the podcast ads, it winds up being engaging in many cases depending how far I can stretch it. And it works. I did a tour at re:Invent last year—virtual re:Invent—where I led a Twitch tour for an hour around the virtual expo hall into a bunch of different sponsored virtual booths and made fun of them all, and I got thank you notes from the sponsors because that led to a bunch of leads because people cared about the—oh, people paying attention because Amazon did a crap job of advertising the Sponsor Expo. And it was something that people could grasp, and have fun with, and get attention for. It's top-of-funnel work and that's fine, but I just don't do it with the boring stodgy stuff. I like to have fun with it. Bring a personality or don't bother.Laurie: Yeah. And you can't take yourself too seriously. I'm not the stand-up comedian that you are. I like to fashion myself as a little bit funny but not that funny. I'm not a stand-up comedian and I don't have a consultancy to represent anymore.There was a time where I did; I was not the owner of it but I worked there. So, now it's sort of, I represent me, which is good in the way that you say it. Like, it's clearly you. It's not Duckbill Group; it's your account. But at the same time, it freaks me out when in real life people know that it's me.So, in my brain, Twitter is the internet and I have my actual real day-to-day life, and never the two shall cross. [laugh]. And my—one of my—I had this popular tweet where I talked about all the companies I'd been rejected from, and it turned into a bit of a retweet situation with everyone sharing all these companies that they'd been rejected from. And the screenshots made it onto LinkedIn and made it into my cousin's feed, and she sent me a text message with a screenshot. And she's like, “You're on my LinkedIn.”And I was like, “No, no, this is not okay. This is not”—I have my little circle of the world and it should not expand beyond that. I go to a conference, even a tech conference, and someone's like, “Oh, you're blue shirt, crossed arms.” I'm like, “No, this is not okay.” Like, [laugh] I only exist on the internet.Corey: This episode is sponsored by our friends at Oracle HeatWave is a new high-performance accelerator for the Oracle MySQL Database Service. Although I insist on calling it “my squirrel.” While MySQL has long been the worlds most popular open source database, shifting from transacting to analytics required way too much overhead and, ya know, work. With HeatWave you can run your OLTP and OLAP, don't ask me to ever say those acronyms again, workloads directly from your MySQL database and eliminate the time consuming data movement and integration work, while also performing 1100X faster than Amazon Aurora, and 2.5X faster than Amazon Redshift, at a third of the cost. My thanks again to Oracle Cloud for sponsoring this ridiculous nonsense.Corey: My business partner was, a week or so ago, at a cafe and someone came by and saw his Last Week in AWS sticker on his laptop. It's like, “Oh, you read that, too? I love Corey's work.” Turns out the guy works at IBM Cloud. And yes, you should hear the air quotes around the word, ‘cloud' in there. But still.Laurie: [laugh].Corey: It's—I haven't been out in the world since I really started focusing on this, and now it's—like, I wear a mask so it's fine, but I'm starting to wonder, am I going to get stopped on the street when I go back into the universe out there? And it's weird because you can't really unring that bell?Laurie: No.Corey: It's a weird transition, and on some level, it's constraining in some ways. Like, at some point of celebrity—I don't know if I'm there yet or not—there's going to become a day where I can't just unload on a waiter for crappy service at a restaurant—not that that's how I—Laurie: I mean, you shouldn't do that anyway. [laugh].Corey: —operate anyway—without it potentially going viral, and, “Oh, he's a jerk when you actually get to know him.” And everyone has this idea of you and this impression of who you are, based upon the curated selection of what it is you put out into the world. I've tried to be as true to life as I can on this. In conversations, I generally don't drop nothing but one-liners, but I think I'm pretty true to life as far as how I present on the internet versus how I present in person.Laurie: More than I expected, to be honest.Corey: Yeah. That also does surprise people. Like, they think there's some sort of writing team behind me. And it's, if you look at the timing of some of my tweets where I will respond with a witty, snarky thing in less than a minute, it's, I wish I had a writing team with that kind of latency. I think that'd be terrific.Laurie: I always assumed it was you, but I figured there was like a persona that you turn on and turn off and I realize now that it's an always on sort of thing. [laugh].Corey: One thing I did experiment with for a little bit was having my team write tweets for my approval to promote episodes of this podcast, for example, because I am not the sort of person going to sit there and build the thing out correctly and schedule at the right time. And I have people who can do things like that, but it's the sort of thing that led to a situation of never getting much engagement and those tweets never did very well, so why even bother? We have a dedicated Twitter feed for that stuff and everyone's happier. Especially since I don't have to share access to this thing through anyone. Speaking of, let's see her tweets did.Laurie: Oh, yeah. Okay, hold on. How'd we do? All right. So, I have, “Do all tweets deserve a like?” Was posted 19 minutes ago. It has 12 comments, 1 retweet, and 22 likes.Corey: My, “Some mornings, it's just not worth chewing through the leather straps.” Was posted at a similar timeframe has 10 likes and 3 replies. Someone said that, “Organic, eh? Probably better than nylon.” Someone said, “Is this an NDA subtweet?” And someone said—with a GIF of Leonardo DiCaprio, saying, “You had my curiosity. Now, you have my attention.” That's it. So yeah, not exactly a smash-it-out-of-the-park success.Laurie: Yeah, but I got to say, “Do all tweets deserve a like?” Is pretty mundane. For that amount of response.Corey: You included a question mark, which is an open invitation—Laurie: Oh, right.Corey: —to the internet randos to engage, so there is—Laurie: Oh, yeah.Corey: —a potential there.Laurie: I going to have to retweet this and say that I'm not grifting and it was done for this podcast [laugh] and they should all listen to it. [laugh].Corey: Oh, of course. By all means. I am thrilled in any point to wind up helping people learn more things about the environment.Laurie: [laugh].Corey: I want to thank you so much for taking the time to speak with me. I have to honestly say that I wasn't quite sure what was coming, but of all the things you could have asked me to predict about this episode, not talking about how Netflix works in cloud was absolutely not one of them. So wow, are you sure you work at Netflix? That's one of those odd moment things.Laurie: Yeah, I got to say I'm pretty abstracted from the cloud these days, so that—maybe that means that I don't know enough to talk about it intelligently.Corey: I would argue that extends to lots of folks. To be clear, Netflix has a lot of really neat thing.Laurie: That never stopped anyone before? Bu-dum-shh.Corey: Oh, yeah. It's like, I like to get up there, sometimes I'll talk about how we do things at Netflix, periodically, on conference stages even though I've never worked there, but people don't correct me because why not? I'm a white man in tech. And I say something, of course, it's right. It's just—if you don't want them to get right, you just don't have enough context. That's the rule.Laurie: Corey, I'm going to need you to take the last minute or so of this episode, and please explain your feelings on how to optimize your use of JavaScript on the front-end, please.Corey: Oh, wonderful; you pay smart people who know what they're doing to look deep into the JavaScript side of it—Laurie: [laugh].Corey: —because honestly, every time I've tried to get into JavaScript, I go back at it and I feel even more foolish than when I started. Async stuff just completely blows my mind, especially by default. How in God's flat earth is that supposed to work? And—Laurie: You work in cloud. [laugh].Corey: It doesn't make sense to me, in a clear sense. At least with Python, which is the—I would say it's the language I know best, but it's not. Crappy Python is. And I can at least do things top to bottom and it works about like I would expect unless explicitly instructed otherwise. But the JavaScript world is just a big question mark and doesn't work the way that I would expect to. To be clear, the failure here is entirely mine.Laurie: ‘JavaScript is a big question mark and doesn't work the way I would expect it to' should be JavaScript's tagline.Corey: That's fair because I have this ridiculous belief from the Dark Ages—because I spent 20 years as a systems admin—that computer behavior should be deterministic and if there's one thing that we learned about the internet, it's not.Laurie: Yeah, no. There's that whole user thing, and then that whole browser thing, and then that whole device thing. It's a whole bunch of non-deterministic behaviors. Just stick to the cloud, and there's one consumer and one producer, and you're good.Corey: One thing I will say—in the moment of pure seriousness here—is that if I were looking at getting into tech today, the first language I would learn would be JavaScript. It is clearly the way of the future. It is a first-class citizen on every platform out there. It is the lingua franca of, effectively, everyone coming out of a boot camp. And it is going to be the way that computers are built.I say this not from a position of being an advocate for JavaScript. I don't know it; I can't stand it personally, but it is clear as day to me that is the direction the world is moving in, so if you're debating what language to pick up, you'd be hard-pressed to convince me not to recommend JavaScript as the first one.Laurie: And do you want me to be my serious self, and you're going to laugh at what I'm about to say?Corey: Hit me with it.Laurie: If you're looking to get into technology because of boot camps and some other things, we have an oversaturation of newbie front-end developers and they're all way more talented than I was at that point in my career, and yet there aren't nearly the front-door opportunities for being a—I hate the term junior, but newbie. And where there is the opportunity, it's cloud. And security.Corey: I will absolutely point out further that I understand this runs the risk of being ‘boomer gives career advice'—Laurie: Yeah, right? [laugh].Corey: —but let's be clear here. I think that if you are going to enter the front-end space—and this does speak to cloud and it speaks to security as well—distinguish slash differentiate yourself by having another discipline or area of intense interest that you can bring into it as well because when you have a company that's looking to hire from a sea of new boot camp grads that generally tend to look more or less identical from a resume perspective, the one that will stand out is the one that can bring in another discipline and especially if that niche winds up aligning with a company's business, or at least an intense interest in something that is directly germane to the company, that will distinguish you. And everyone has something like that; no one is one-dimensional. So, find the thing that is the in-between space, and focus on finding jobs in companies that do those things. And if you're a mid-career switcher, let me be very clear here.It is not a go back to entry-level roles-style story. I've never understood that philosophy. I do have steps from thing I'm doing now toward thing I want to go to. Well, is there a job I can find to do next that blends the two of them together in different ways, and then once I'm there, then make a further transition. And of course, find someone who's—in any career, in any path you're on, find someone who is five years ahead of you, and ask them for their advice.“What would you do in my shoes?” If the answer is, “Go to a boot camp,” okay. Talk to a few people who've done this and make sure it validates it. If it's, “Get a degree,” okay, but make sure you're not doing it because you think that's what you're supposed to do. You'll very rarely find me recommending six figures of debt in order to advance your career, but there are occasions.By and large, they'll find someone who's been there before who knows what's going on, you can have a conversation with and give them context appropriate to your situation and then see what's right. We turned this into last-minute career advice and I'm not even—I don't even [unintelligible 00:34:45] have a problem with that.Laurie: Well, I was about to say that it's 2020. 21 2020—wow, I—you knew what I meant—it's 2021, and I guess I need to start taking my half-steps towards becoming a Lego master before I retire. [laugh].Corey: Oh, yes, the Lego world is vast and deep, and they have gotten no worse since I was a child at separating parents from money to buy LEGO sets. My daughter's four and his way into them already. So, it's great. It's something that we can bond over.Laurie: If I ever have kids, we're going to need separate sets because they're not touching mine. [laugh].Corey: Yeah, I'm looking at stuff like, oh, well, I'd love to buy that awesome big Star Destroyer—wait, it's how much money? And it turns into this—yeah. It's wow, on some level, I never ever thought I would find a hobby that was more expensive than my mechanical keyboards hobby, but here we are.Laurie: Oh, yeah, I blame Cassidy Williams for getting me into that one, too. I have a shiny one beneath me. And that's my first.Corey: She is a treasure and a delight.Laurie: She's a treasure, a delight, and dangerous if you want to save money because she will draw you into the mechanical keyboards, and there's just, there's no resisting. I tried for a very long time. I failed, ultimately.Corey: One of these days, she and I are going to have a keyboard-off at some point, once it's no longer a deadly risk to do so. It'll be fun.Laurie: Do it.Corey: I'm looking forward to it. Thank you so much for taking the time to speak with me. I really appreciate it.Laurie: Absolutely. Thanks for having me.Corey: Of course. Laurie Barth, senior software engineer at Netflix, also instructor at Egghead, also a member of the TC39 Educator Committee, and prolific blogger. 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 a horrifying comment explaining anything we just talked about, back to us.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.

In this episode, we talk about Visual Studio Code with, Jonathan Carter, principal program manager at Microsoft, and Cassidy Williams, director of developer experience at Netlify. Show Notes Cockroach Labs (DevDiscuss) (sponsor) Scout APM (DevNews) (sponsor) CodeLand 2021 (sponsor) Visual Studio Code GitHub Codespaces Vim ASP.NET Active Server Pages C# documentation Visual InterDev .NET Firebug C++ Microsoft Visual Studio Atom TypeScript Monaco Gitpod CodeSandbox CodeTour CSS Diner

We invite Cassidy, Ben, and Tara from the Netlify DevRel team to talk about using the Jamstack architecture with Headless WordPress.Cassidy mentions a few examples she's seen of React + Headless WordPress sites. Tara shows off a site that uses "Jamgular" (Jamstack with Angular). Ben breaks down how developers are using Vue in conjunction with headless WordPress.Finally, we talk about Netlify Edge Handlers, producing content on Astro, and up-and-coming tech that excites the Netlify team.Cassidy Williams: https://cassidoo.co/Ben Hong: https://www.bencodezen.ioTara Z. Manicsic: https://github.com/tzmanicsWebsites mentioned:https://www.harukimurakami.com/library - Website built from Angular and WordPresshttps://github.com/jamstack/jamstack.org/discussions/549 - Distributed Persistent Rendering (DPR)https://docs.netlify.com/configure-builds/on-demand-builders/ - On Demand Buildershttps://www.guggenheim.org/ https://www.netlify.com/blog/

We've talked a lot this summer about God's great promises for us, but how do we respond when the fulfilment of God's promises don't seem to come as we expected? Listen in as Cassidy Williams shows us the glories of Psalm 42 and helps us see how to cling to God when it's hard to see the fulfilment of His promises.

Videohttps://youtu.be/E6TJmGsmRoE

There are two sides to every story, and a job interview can seem very different depending on whether you're the interviewee or the interviewer. Cassidy Williams (Director of Developer Experience at Netlify and teacher here at Scrimba) has experienced both. She joins us today to share her experience and prove the interview process isn't as scary as it may seem.Contents Introduction (00:00) What does Cassidy do at Netlify? (01:51)   How Cassidy stays super productive (and how you can too) (03:58) How to "kill two birds with one scone" (07:31) Why you should learn and work in public (11:21) "The difference between a developer and a senior developer is that the senior developer says, 'I don't know' more." (13:50) How to start your career in tech (17:30) Why rejection is not a reflection of you or your ability (21:48) Should you apply to lots of companies or a few specific ones? (25:48) Small companies or big companies? (29:23) Cassidy's cool sister's (Cammi Williams) experience working at Apple, Google, Amazon, and Facebook (30:10) The importance of friendship in the developer community (34:00) Networking doesn't have to be gross

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/@cassidoo Newsletter: https://cassidoo.co/newsletter/ Scrimba: https://scrimba.com/teachers/cassidoo Udemy: https://www.udemy.com/user/cassidywilliams/ Skillshare: https://www.skillshare.com/user/cassidoo O'Reilly: https://www.oreilly.com/pub/au/6339 Personal website: https://cassidoo.co Twitter: https://twitter.com/cassidoo GitHub: https://github.com/cassidoo CodePen: https://codepen.io/cassidoo/ LinkedIn: https://www.linkedin.com/in/cassidoo TranscriptAnnouncer: 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 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 enterprise-y. Take a look. I'm a big fan of this. More from them in the coming weeks.Corey: 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.Corey: I'm Corey Quinn. I'm joined this week by Cassidy Williams, principal developer experience engineer at Netlify. Cassidy, thanks for joining me.Cassidy: Thanks for having me.Corey: 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?Cassidy: 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.Corey: 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 frontend.Cassidy: It takes all kinds to make a project work. Yeah, so it is more than static. I like to think of it more as 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:, JavaScript, APIs, and Markup stack. And so, it's less about technologies and more about 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—Corey: Well, not with that attitude anyway.Cassidy: [laugh]. 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 upfront and then pulling in data as needed.Corey: The idea is incredibly compelling, and it gets at a 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 a frontend—in general, when it comes to, effectively, computers. We're seeing it on the backend, we're seeing it on the frontend, 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?Cassidy: 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 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 then 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.Corey: 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 code 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 you—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 being secretly terrible? Or is there a nuance here that I'm not picking up on?Cassidy: 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. [laugh].Corey: 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 IDE 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 odd. 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 frontend in a responsible way? Are they nice-to-haves? Is it effectively an aside current debate that I got suckered into and lost the forest for the trees?Cassidy: 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.Corey: 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 frontend developer to build something frontend 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 a discovered Retool, which is one of those low-code tools that more or less is Visual Basic for frontend. 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.Cassidy: [laugh]. 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.Corey: 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 a 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 frontend 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.Cassidy: 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.Corey: 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 frontend is easy, and backend 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?Cassidy: You know, I think it just comes from the past.Corey: 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.Cassidy: 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, “Eh, well, I know HTML and CSS, so I know frontend.” And that's about it. Or they'll say, “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 ten years ago, that might have been more true because we didn't have some of these frameworks that do a lot on the frontend. And we didn't have things like GraphQL, and really powerful tools on the frontend. Where back then, it was a lot of the backend doing stuff, and then the frontend making it look good. But now the work is distributed a bit more where our backend 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 frontend, all of the management of that data happens on the frontend, all of the organization and optimizing for the browser happens on the frontend. 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.Corey: 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, ugh, it kills me. Let's talk a little bit about that. How did it start? And how is it continuing?Cassidy: 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 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, “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. [laugh].Corey: 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 and 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.Cassidy: Yeah. It brings a levity to our very serious industry—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 and 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 Netlify because a bunch of them are just dorks [laugh] where 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.Corey: 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, or 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.Cassidy: 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.Corey: 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 livestreaming on Twitch—or ‘Twetch' or however it's pronounced. I'm 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?Cassidy: 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 tried to do that and all the things that I do.Corey: 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 in Git” because if there's one thing that unites frontend, backend, 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 where, 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 Frontend 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 frontend 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.Cassidy: 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, “Eh, 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 [laugh] much happier industry in general.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: 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 counterargument is that it's also supremely unhelpful. It's—Cassidy: Right.Corey: —“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 them 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 blessing, 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 some reason worried about being overly prescriptive. And I get that too.Cassidy: 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 own. But I'm sure it'll work for you.” And just kind of roll with it from there because you never know.Corey: Yeah, what 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.Cassidy: Yeah.Corey: Yeah.Cassidy: That's common.Corey: 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.Cassidy: 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 00:23:27], that's almost always the case. 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, “Eh, 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 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. [laugh].Corey: And whenever someone says something like that, I always assume conflict of interest somewhere. It's like, “With 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't 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, honestly, the product itself.Cassidy: Exactly. There's always cons. 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.Corey: 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 00:25:05]. 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—Cassidy: Yeah, we should cut out those farts earlier, by the way.Corey: Oh, yeah. Oh, we've already edited that out.Cassidy: Okay, great. [laugh].Corey: 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 are 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.Cassidy: 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 are about to livestream, or they're learning how to livestream 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 livestream 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.Corey: Oh, 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.Cassidy: Thank you. [laugh]. 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.Corey: You also seem to have some of the same problems than 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?Cassidy: 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. [laugh].Corey: And that's the hard part is when someone asks, “So, what do you do?” What's your default answer?Cassidy: 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, streams, and software.” And I just kind of leave it at that, and people be like, “Okay, Cassidy, shut up.” [laugh] 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.Corey: Yeah, it's a hard problem. My answer has always been to spin it depending upon who I'm talking to.Cassidy: True.Corey: 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.Cassidy: [laugh]. 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 like, “Oh, well, I specialize on frontend 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 WiFi 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.Corey: Oh, hey, I'm building a computer, too. Can you recommend some parts? Absolutely not. Is my—Cassidy: Nope.Corey: —I don't know what I'm doing there.Cassidy: I kind of just Google and accept whatever I'm told. [laugh].Corey: 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?” 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 geekspeak.”Cassidy: 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 tech jokes on Twitter.” And they'll say, “Oh, really? Say something funny.” I'm like, “Uh—I don't know how.” [laugh]. It's not that easy. It's interesting trying to figure out how you define that for other people.Corey: “Oh, you're a comedian. Great. Make me laugh.” Like, “Oh, God.”Cassidy: Just please, no.Corey: Yeah, that's the best setup for a good belly laugh is command performance of, be funny when you weren't expecting it?Cassidy: Yeah. Ugh, can't handle it. I just freeze up and give up.Corey: Ugh. 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 we wound up going through expanding audiences on Twitter and whatnot. And you sent a screenshot, at one point, of tracking your Twitter follower count over time in a private Slack channel that you had. And 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—Cassidy: So funny.Corey: —first, hilarious because I've never seen anyone else do that. And, two, a bit of product feedback, perhaps, for the team at Twitter.Cassidy: It really is. Yeah, no, 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 in 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 type, but eh.Corey: 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.Cassidy: 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.Corey: Four years ago, I had 1500 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 re:Invent.” “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.Cassidy: 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 [laugh] strategies. But yeah, I mean, I guess that also speaks to building what's best for you is often the best solution.Corey: Yeah, and it changes, too. And the 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 and 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.Cassidy: Right.Corey: 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.Cassidy: 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 en masse.Corey: No, I have learned there's 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 look like a fool for basically taking a troll seriously, but I'd rather that than the alternative of someone asks a naive question, and I assume 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.Cassidy: 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 there and 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, you have whenever stuff like that happens, you kind of just have to ignore it and learn to pick your battles, I guess.Corey: Oh, yeah. And I assume that'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: [laugh].Corey: 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—okay can they find you? Take a deep breath; run through the list.Cassidy: 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, cassido on Twitter on GitHub on CodePen on LinkedIn all those platforms. That's where you can find me.Corey: And we will put links to all of those things in the [show notes 00:38:03] because honestly, that's someone else's job, and I am going to hurl that mess to them.Cassidy: [laugh]. Perfect.Corey: Thank you so much for taking the time to speak with me. I really appreciate that.Cassidy: It was really fun. It was good chatting with you, too.Corey: It 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.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.

Many area businesses thrived before the pandemic thrived. But now, as things open back up, some locally-owned spots are struggling. In this episode of Open Record, the FOX6 Investigators invite FOX6 reporter Cassidy Williams on the podcast to talk about how the pandemic could forever change the world of working in downtown Milwaukee. Cassidy recently profiled a local downtown soup restaurant forced to shut down due to lack of business. She found many companies are not renewing their leases downtown, as working from home and hybrid schedules become the new normal. What do downtown boosters say? What other kinds of fallout may happen because of it? Plus, in the Off the Record segment, hear why Cassidy needs to swing by the store before coming to your party and Bryan's go-to dish for a get-together.

Key Points From This Episode: - Introducing Cassidy, her favorite frameworks, and her road into tech. - Understanding more about React and how Next.js fits into it. - Discussing other JS frameworks like Nuxt and Vite. - Making a counter and a to-do list in Vue; Cassidy’s experience with this new framework. - How making a counter in Vue would compare to doing it in React. - Loops, event bubbling, and deleting things from lists in Vue. - Setting up a new Vue app versus a new React one. - Using CSS modules versus styles in the component in Vue. - Different shortcuts in Vue such as the dollar, pound, and v-bind. - Issues around interpolation using string quotation marks rather than curly braces. - Highs and lows of Cassidy’s experience with the Vue docs. - How to find Cassidy online and read her newsletter too. - The week’s picks: Albanese gummy bears and more! Tweetables: - “I admit some of Vue, I was just like, it works and it felt magical to the point where I was just like, ‘It almost feels wrong. I need to suffer a little more to make this work.’” — @cassidoo [0:08:43] - “Luckily, I know enough React that I don't have to go to the docs anymore because I don't like them. So, in comparison, the Vue docs are great.” — @cassidoo [0:34:55] - “I enjoyed the Vue.” — @cassidoo [0:36:19] Links Mentioned in Today’s Episode: - Cassidy Williams (https://cassidoo.co/) - Cassidy Williams on LinkedIn (https://www.linkedin.com/in/cassidoo/) - Cassidy Williams on GitHub (https://github.com/cassidoo) - Cassidy’s Newsletter (https://cassidoo.co/newsletter/) - Netlify (https://www.netlify.com/) - Ionic (https://ionicframework.com/vue) - Enjoy the Vue on Twitter (https://twitter.com/enjoythevuecast?lang=en) - Enjoy the Vue (https://enjoythevue.io/) Special Guest: Cassidy Williams.

In this episode, we talk about content creation and building communities with Cassidy Williams, principal developer and experience engineer at Netlify. Cassidy talks about her strategy for doing internships, the intersection of content and community, and where she draws inspiration from. Show Links TwilioQuest (sponsor) DevDiscuss (sponsor) DevNews (sponsor) Career Karma (sponsor) Cockroach Labs (sponsor) Cassidy Williams rendezvous with cassidoo Cassidy Williams Twitch Netlify I love being a woman on the internet freeCodeCamp .NET Hackathon Black Girls Code Women Innovate Mobile Mums who Code CodePen React React Training Bruno Mars Hackathon Hackers Ladies Storm Hackathons

The benefits of JamstackIn this episode, we speak with Cassidy Williams and Jason Lengstorf, both on the Developer Experience Team at Netlify, about deploying Jamstack (which stands for Javascript, APIs, and Markup) applications to Netlify. Jason clarifies the Jamstack, “It’s honestly not a stack at all, so it ends up being a silly name for an architecture. Jamstack is a way of organizing your code. The Jamstack architecture is where you're abstracting your front end to being a layer of static assets that can be deployed to a CDN.”Netlify helps host and maintain Jamstack applicationsCassidy explains how Netlify and Jamstack work together to maximize productivity, “The short way of saying what Netlify does is we host Jamstack applications. But the longer form is not only do we host them, but we also have a ton of different features that make it easy for the developer to maintain Jamstack applications.”These features include:Form management — Add a Netlify attribute to an HTML form, and it will automatically gather all of your responses for youSplit testing — Point different branches (whether production, staging, or QA) at different groups of users to test and compare the resultsDeploy previews — See what your deployment is going to look like on any given pull request before pushing it liveSnippet injection — Inject different snippets of code into your applications without having to include it in the code itselfNetlify can also connect with GitHub, GitLab, or Bitbucket repositories, increasing your productivity further. Jason adds,“You want to switch as few contexts as you can when you're trying to get things done. When you’re working in GitHub, you can push up changes and Netlify will show them to you in deploy preview. All the context you need is right there. You don't have to go to other places to do other parts of your job, you can consolidate that whole workflow.”You can try out Next.js on Platform.sh today by clicking the Deploy on Platform.sh button in our template's README: https://github.com/platformsh-templat…Platform.shLearn more about us.Get started with a free trial.Have a question? Get in touch!Platform.sh on social mediaTwitter @platformshTwitter (France): @platformsh_frLinkedIn: Platform.shLinkedIn (France): Platform.shFacebook: Platform.shWatch, listen, and subscribe to the Platform.sh Deploy Friday podcast:YouTubeApple PodcastsBuzzsproutPlatform.sh is a robust, reliable hosting platform that gives development teams the tools to build and scale applications efficiently. Whether you run one or one thousand websites, you can focus on creating features and functionality with your favorite tech stack and leave managing infrastructure and processes to us.

In this episode, Brian and Ben talk with Cassidy Williams about being “tech famous,” web developer comedy as a genre, and what it’s like to create content specifically for web developers. We also get into developer experience for a little bit, touching on both the future and importance of niche communities. Links https://cassidoo.co/ (https://cassidoo.co/) https://twitter.com/cassidoo (https://twitter.com/cassidoo) https://github.com/cassidoo (https://github.com/cassidoo) https://www.patreon.com/cassidoo (https://www.patreon.com/cassidoo) https://www.tiktok.com/@cassidoo (https://www.tiktok.com/@cassidoo) https://www.netlify.com/ (https://www.netlify.com/) https://www.netlify.com/blog/2021/01/06/developer-experience-at-netlify/ (https://www.netlify.com/blog/2021/01/06/developer-experience-at-netlify/) https://www.timirahjames.com/ (https://www.timirahjames.com/) https://dev.to/dabit3 (https://dev.to/dabit3) Contact us https://podrocket.logrocket.com/contact-us (https://podrocket.logrocket.com/contact-us) @LogRocket (https://twitter.com/LogRocket) brian@logrocket.com What does LogRocket do? LogRocket combines frontend monitoring, product analytics, and session replay to help software teams deliver the ideal product experience. Try LogRocket for free today (https://logrocket.com/signup/?pdr). Special Guest: Cassidy Williams.

In this episode, we chat with Cassidy Williams, who works as a Principal Developer Experience Engineer at Netlify. We talk about the difference between developer relations and developer experience, the developer experience team at Netlify, the risks that these teams can face, and mitigating those risks. She also shares some insights into starting a career in DevRel and hiring for these teams. Featuring:
 Cassidy Williams (twitter.com/cassidoo) Hosts:
 Tanay Pant (twitter.com/tanay1337)

FeaturingCassidy Williams — Twitter, GitHub, Websitechantastic — Twitter, GitHub, WebsiteDiscordJoin the discussion in Discord

In the *first-ever episode of Non-Technical* (!!!), Alexis chats with *Cassidy Williams* , a Principal Developer Experience Engineer at Netlify, one of Glamour Magazine’s 35 Women Under 35 Changing the Tech Industry, and lover of mechanical keyboards and karaoke. They talk about what’s (not) in Cassidy’s fridge, why she’s into K-Dramas, whether her astrological sign means anything and more! You can find Cassidy on Twitter @cassidoo ( https://twitter.com/cassidoo ) and Alexis at @yayalexisgay ( https://twitter.com/yayalexisgay ) and @NonTechnicalPod ( https://twitter.com/NonTechnicalPod ). This episode is sponsored by *Worklife* , the first venture capital firm designed for builders and creators. Sign up for the Worklife newsletter for interviews with creators and updates on new tools for your worklife at worklife.vc ( https://worklife.vc/ ).

Cassidy 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. In this episode, listen to Cassidy talk about finding mentorship and how to stand out as an engineer. Cassidy also reflects on her favorite projects from her time at Venmo, Clarifai, CodePen and Netlify. Shownotes: Connect with Cassidy on her Twitter (https://twitter.com/cassidoo) or GitHub (https://github.com/cassidoo). Subscribe to Cassidy's weekly web dev newsletter (https://cassidoo.co/newsletter/) and check out her course on Building Reusable React (https://scrimba.com/learn/reusablereact).

I spoke with the flamboyant Cassidy Williams. Cassidy is a Developer Experience Engineer at Netlify. From a technical stand point, she does a lot of work with React, but her reach goes way beyond that. As a public speaker, she talks about topics such as Women in Tech and STEM education. As many of us, she was directly affected by covid as the company she used to work for, a react training company, had to layoff all their staff at the start of the pandemic but being connected as she is, she got a new position at Netlify right away. Cassidy has her own very popular weekly newsletter called "rendezvous with cassidoo" where she talks about technology and coding. She is also a curator of "The Overflow" newsletter published weekly by Stack Overflow. From her adventures as a public speaker to her passion for mechanical keyboards we spoke about everything. Enjoy the chat! Full show notes and links: https://SoloCoder.com/60

Cassidy Williams is a Principal Developer Experience Engineer at Netlify. She's worked for several other places, including CodePen, Amazon, and Venmo, and has worked 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. Check out & support Cassidy and her works here :) Follow Cassidy: Web / Twitter Follow Su on Instagram & Twitter Join the Discord Server Listen to Su's music on Spotify & Apple Music Support on Patreon

Cassidy first told us about how she came to web development in high school, discovered it could be a job and ended up studying computer sciences. We then discussed how she chose her first job to use her creative & people skills, not just coding. We talked about burnout, before diving deeper into developer experience. Cassidy gave us her definition of a good developer relations engineer, how developer relations impact companies and how dev-rel will evolve in the next 10 years. We finally briefly touched on Cassidy's loved topic of mechanical keyboards.Here are the links of the show:https://twitter.com/cassidoohttps://cassidoo.cohttps://www.netlify.com/authors/cassidy-williamshttps://www.tiktok.com/@cassidoohttps://cassidoo.co/newsletterhttps://dev.to/cassidoohttps://www.udemy.com/user/cassidywilliamshttp://www.lissaexplains.comhttp://www.neopets.comhttps://girlknowstech.com/beginning-coding-career-neopetshttps://scrimba.comCreditsMusic Aye by Yung Kartz is licensed CC BY-NC-ND 4.0.Your hostSoftware Developer‘s Journey is hosted and produced by Timothée (Tim) Bourguignon, a crazy frenchman living in Germany, who dedicated his life to helping others learn & grow. More about him at timbourguignon.fr.Gift the podcast a ratingPlease do me and your fellow listeners a favor by spreading the word about this podcast. And please leave a rating on the podcasting platforms. This is the best way to increase the visibility of the podcast. Find all the links here: https://devjourney.info/subscribe.htmlPatreonFinally, if you want to help produce the podcast, support us on Patreon. Every cent you pledge will help pay the hosting bills.Support the show (http://bit.ly/2yBfySB)

Cassidy (@cassidoo) has been building but also educating developers on how to build apps on React, JavaScript, JAMStack and many other technologies over the past years. We got her on our podcast where she gave us insights into React Hooks, how WPO (Web Performance Optimization) plays out in the React world, why it is important to think about state from the start and that its important to always have your end user in mind before even writing your first line of JavaScript.In the podcast she references additional resources which here are the links for: The performance benefits of Variable Fonts, Mandy Michael (@Mandy_Kerr), Isabela Moreira (@isabelacmor) and A/B Testing with React (YouTube).https://twitter.com/cassidoohttps://reactjs.org/https://jamstack.org/https://uxdesign.cc/the-performance-benefits-of-variable-fonts-79af8c4ff56chttps://twitter.com/Mandy_Kerrhttps://twitter.com/isabelacmorhttps://www.youtube.com/watch?v=xpfR0rRfcNk

Cassidy (@cassidoo) has been building but also educating developers on how to build apps on React, JavaScript, JAMStack and many other technologies over the past years. We got her on our podcast where she gave us insights into React Hooks, how WPO (Web Performance Optimization) plays out in the React world, why it is important to think about state from the start and that its important to always have your end user in mind before even writing your first line of JavaScript.In the podcast she references additional resources which here are the links for: The performance benefits of Variable Fonts, Mandy Michael (@Mandy_Kerr), Isabela Moreira (@isabelacmor) and A/B Testing with React (YouTube).https://twitter.com/cassidoohttps://reactjs.org/https://jamstack.org/https://uxdesign.cc/the-performance-benefits-of-variable-fonts-79af8c4ff56chttps://twitter.com/Mandy_Kerrhttps://twitter.com/isabelacmorhttps://www.youtube.com/watch?v=xpfR0rRfcNk

Scott and Principal Developer Experience Engineer Cassidy Williams talk about social friendships, internet life, making code, videos, and videos about code.

On Day 10/100 of the #100DaysOfCode Motivation Podcast, Cassidy Williams, Meme Creator & Software Engineer, empowers you to find and connect with your community so that when you're facing a challenging bug or hurtle, you'll have the support you need to get through it. Then you can give back and help your community when others are experiencing an obstacle. "When you aren't sure what you're doing, but you really want to succeed – you'll figure out a way to do it." – Cassidy Williams Go to join.teamtreehouse.com/100-days-of-code to launch your #100DaysOfCode Challenge with Treehouse today!

For more episodes listen here: https://thenewstack.io/podcasts/ Welcome to The New Stack Context, a podcast where we discuss the latest news and perspectives in the world of cloud native computing. For this week's episode, we spoke with a couple of folks from cloud workload protection platform provider Rezilion: CEO Liran Tancman, and Chief Marketing Officer Tal Klein. We discuss how current best practices in security are actually outdated and how they think companies should be approaching security practices in the age of DevOps. TNS editorial and marketing director Libby Clark hosted this episode, alongside founder and TNS publisher Alex Williams and TNS managing editor Joab Jackson. Klein wrote a contributed article for TNS on “Why Vulnerability Management Needs a Patch,” where he argues that current best practices and tools around security patching, such as the CVSS system for rating vulnerabilities, are outdated, particularly for modern DevOps shops. As Klein says in the interview: When you've got vulnerabilities, it's very tough to figure out which ones to fix first, and the fact is that more and more vulnerabilities are discovered every year. So there's, there's a greater amount of things to patch and if you don't know which ones to patch first, you're never going to be able to address the full patching needs of your organization. And that's been a cat and mouse game for a long time. Then later in the show, we discuss some of our top podcasts and stories of the week. Our sister podcast, The New Stack Makers, posted an interview with DevRel trailblazer (and Coder-Twitter celeb) Cassidy Williams, on building software communities. COVID-19 continues to tear through the IT community, and so we look at the shifting network traffic patterns that have come about from the pandemic, as well as the additional babysitting duties that many IT professionals have to now mix into their daily work from home routines. Finally, we discuss The Eclipse Foundation's Theia code editor, which has been billed as “a true open source alternative to Visual Studio Code.”

For more episodes listen here: https://thenewstack.io/podcasts/ Welcome to The New Stack Context, a podcast where we discuss the latest news and perspectives in the world of cloud native computing. For this week's episode, we spoke with a couple of folks from cloud workload protection platform provider Rezilion: CEO Liran Tancman, and Chief Marketing Officer Tal Klein. We discuss how current best practices in security are actually outdated and how they think companies should be approaching security practices in the age of DevOps. TNS editorial and marketing director Libby Clark hosted this episode, alongside founder and TNS publisher Alex Williams and TNS managing editor Joab Jackson. Klein wrote a contributed article for TNS on “Why Vulnerability Management Needs a Patch,” where he argues that current best practices and tools around security patching, such as the CVSS system for rating vulnerabilities, are outdated, particularly for modern DevOps shops. As Klein says in the interview: When you've got vulnerabilities, it's very tough to figure out which ones to fix first, and the fact is that more and more vulnerabilities are discovered every year. So there's, there's a greater amount of things to patch and if you don't know which ones to patch first, you're never going to be able to address the full patching needs of your organization. And that's been a cat and mouse game for a long time. Then later in the show, we discuss some of our top podcasts and stories of the week. Our sister podcast, The New Stack Makers, posted an interview with DevRel trailblazer (and Coder-Twitter celeb) Cassidy Williams, on building software communities. COVID-19 continues to tear through the IT community, and so we look at the shifting network traffic patterns that have come about from the pandemic, as well as the additional babysitting duties that many IT professionals have to now mix into their daily work from home routines. Finally, we discuss The Eclipse Foundation's Theia code editor, which has been billed as “a true open source alternative to Visual Studio Code.”

Listen to more episodes here: https://thenewstack.io/podcasts/ This episode of The New Stack Makers focuses on more the community and less on the tech side of the tech community — which we think matters now more than ever. Williams has dedicated her career to teaching, mentoring and helping others find the right roles in tech. In fact, she's written a step-by-step guide on how to get your first job in this industry. This episode dives into how to build the right network Software Engineer and Developer Advocate Cassidy Williams started this decade looking forward to a year of global travel for React training, workshops, and public speaking gigs. She spent January in Boston, DC, and Austria. February saw her speaking in France and Ireland. Then, suddenly, the small consultancy she worked at went from having overbooked their March to an empty schedule. And the full-time staff was let go.

In this episode of Technically True, we will chat with Cassidy Williams, who is a software engineer and instructor at React Training. We will explore her journey and utilize her experience to learn about getting started with public speaking, dealing with procrastination, handling live demos like a boss and establishing your personal brand. Featuring: Cassidy Williams (twitter.com/cassidoo) Hosts: Tanay Pant (twitter.com/tanay1337) Notes: The journal that Cassidy mentioned is Dabble.Me and the slide software that she mentioned is Deckset.

Cassidy walks us through her career and gives us insight on choosing jobs, quitting them, and focusing on what's important to you. We also discuss keeping track of her many ideas, teaching workshops at React Training, why Amazon was a poor fit, and much more.

On this week's episode, Chris and Steph catch up on recent client adventures, revisit their feelings on using let in rspec, and spend a bit of time outside their respective comfort zones. There's also some talk about nearly full-time pairing, mechanical keyboards, debugging thorny datetime issues, and how we interact with our developer tools and workflows.This episode of The Bike Shed is sponsored by Honeybadger.Tuple (remote pairing app)Leopold 660 with Cherry MX BrownsHusky - "git hooks made easy"Cassidy Williams eslint video tweetFlipper "disable fun mode"Let's Not - Rspec blog postThe Zen of PythonIf you're enjoying The Bike Shed, we'd love it if you could give it a rating or review on iTunes. Thanks!

Tilde Club: It’s your chance to LARP as a 70s sys admin! What you do on your computer is your business. Don’t be tricked by scammers.Paul makes the mistake of sharing his Anxiety Box on This American LifeSara’s favorite Kanye tweet is available, beautifully framed, for only $75. cKeys is an amazing Seattle non-profit that teaches folks how to make their own keyboards!When we recorded this episode Cassidy worked at CodePen, but not she works at React Training, so check them out.

Tilde Club: It's your chance to LARP as a 70s sys admin! What you do on your computer is your business. Don't be tricked by scammers.Paul makes the mistake of sharing his Anxiety Box on This American LifeSara's favorite Kanye tweet is available, beautifully framed, for only $75. cKeys is an amazing Seattle non-profit that teaches folks how to make their own keyboards!When we recorded this episode Cassidy worked at CodePen, but not she works at React Training, so check them out.

On this episode of if/else, host Mayuko Inoue explores a choice faced by many front-end developers: which JavaScript framework should you use?There are many frameworks available, including Angular, Relay, Next, Aurelia, Svelte, Ember, Meteor, Knockout, Backbone, Node, and Polymer. But we're going to focus on the two most popular ones: React and Vue.js.Mayuko explains the history and philosophy behind these two frameworks, and you'll hear from several developers about their experiences with React and Vue.You'll also meet Al. Al works at a small IoT firm, and is getting back into front-end development after a long hiatus. He has some experience with JavaScript, but wants to take advantage of the efficiency gains of a JavaScript framework. Al has heard about React and Vue, but he hasn't committed to either option. To help Al decide which one will work best for his projects, we've enlisted the help of two industry experts.Cassidy Williams is an instructor and developer at React Training and the director of outreach at cKeys. Erik Hanchett is a senior software engineer at Cerity and the author of the book Vue.js In Action. He is also co-host of the Self Taught or Not podcast.Cassidy and Erik join Mayuko to discuss the guiding principles of each framework, along with their strengths and weaknesses. The idea is to give Al, or anyone else facing a similar decision, the information needed to make a solid choice.if/else is an original podcast by CTO.ai, makers of The Ops Platform. The Ops Platform makes it easy for development teams to create and share workflow automations without leaving the command line. Visit cto.ai/platform to join the beta.If you enjoy the show, please leave a ⭐⭐⭐⭐⭐ rating or review on Apple Podcasts.

On this week's episode, Steph returns from vacation and Chris makes some noise about a fantastic new button. They discuss Steph's continued adventures in search of the perfect mechanical keyboard and then dig into two listener questions on landing a first job as a developer and what frameworks and languages to focus on, as well as discussing some of the common objections to GraphQL.Rails ActionableErrors - Migration ButtonCODE KeyboardKeychron K2 keyboardCassidy Williams on TwitterAvdi Confident Code talkAvdi Confident Ruby bookRobustness principleThe Rails TutorialStack Overflow 2019 developer surveyDataloader for GraphQLgraphql-batch from ShopifyGraphQL persisted Queries

Shownotes:To allow you to find interesting places here are the beginnings of some conversations:We start with how she found herself working remote for CodePen. (1:35)How it is for Cassidy to working remotely for CodePen (3:15)What is Cassidy's responsibility at CodePen (6:11)She is responsible for changing their web application from Ruby Rails and Redux to Apollo and GraphQLCassidy talks about how she interviewed with CodePen (9:40)How the team learns a new technology together as a team (13:20)CodePen's inclusive environment and women in tech (15:45)Why does Cassidy spend time on making jokes and funny videos (19:50)How does Cassidy approach problems? (24:15)How do they communicate in a remote team? (27:00)Do they use Code Reviews at CodePen? (29:35)Cassidy explains that they also invest now more into testing (31:30)How are decisions done at CodePen? Who decides which features are delivered? (32:15)Cassidy talks about how they covert CodPen to a more consolidated state using React and Appollo (38:15)We talk about if you should re-write your code from scratch? (44:15)CodePen is rewritten piece by piece, reminding Michaela about how Slack UI was modernized.Now we talk about Cassidy's side projects and how she integrates that into her life (45:50)Why she isn't a developer evangelist anymore (46:30)What is up with Cassidy and her keyboards? (48:45)Cassidy's advice for others on side projects: figure out why you do that (51)A song that stuck with her and has some solid career advise (52:30)Lyrics:The day is short.The night is long.Why do we work so hard, to get what we don't even want?(From the song: The Day Is Short - Jearlyn Steele)Career advice: You should know what you like and what you dislike (55:00)Rebecca Gracia: When you build your personal career or your personal brand, it's just as important to know what you like as it is what you dislike.Links:Cassidy's talk about converting CodPen Side.Cassidy's websiteSlack engineering blog article on modernizing the UI at Slack

Phil’s guest on this episode of the IT Career Energizer podcast is Cassidy Williams. She is a software engineer at CodePen and the director of outreach at cKeys.  Previously, she has worked for Amazon, L4 Digital, Clarifai and Venmo. She also runs a weekly newsletter and loves teaching and helping people become better coders.  In this episode, Phil and Cassidy Williams discuss the benefits of getting involved with the wider community and teaching them tech skills. They talk about the need to constantly evaluate the work you are doing to make sure that it is still right for you. Phil and Cassidy also review how the frontend is changing and what the websites of the future will look like.   KEY TAKEAWAYS: (4.18) TOP CAREER TIP Know what you don’t want just as much as what you do. If you do not want to work in a certain kind of environment or use a specific tech knowing that is the case is essential. You have to avoid that kind of work even if it looks like it will take you closer to your dream job. Putting yourself in an uncomfortable place to reach your ultimate goal rarely works out. Usually, you just end up feeling miserable. At which point, it is all too easy to give up on your dream.   (6.08) WORST CAREER MOMENT A few years ago, Cassidy was offered a well-paid job with a good title at Amazon. Despite the fact that it was going to be practically impossible to maintain the level of life-work balance she had been enjoying at her previous firm, she took the job. For Cassidy, this turned out to be a huge mistake. She no longer had the time to work on side projects and got very little job satisfaction out of her new role. It was a tough way to learn what really mattered to her.   (9.04) CAREER HIGHLIGHT In the podcast, Cassidy shares four great highlights from her career. Including her work at Clarifai which gave her the chance to build a programme from the ground up and share it with the world.   (13.28) THE FUTURE OF CAREERS IN I.T Cassidy is really excited by the direction that frontend development is going in. React, Angular and Vue have really mixed things up and the possibilities are now endless. These more advanced front ends will make websites a lot faster, more functional and accessible.   (15.42) THE REVEAL What first attracted you to a career in I.T.? – Creating her first website is what got Cassidy hooked on IT. What’s the best career advice you received? – Ask yourself, what’s the worst that could possibly happen? Cassidy finds that thinking this way stops her from worrying too much and unnecessarily holding herself back. What’s the worst career advice you received? – Sign up for absolutely everything. It will make you better at time management. Following that advice will lead to burn out and leave you working on things you don’t really care about. What would you do if you started your career now? – Cassidy would start out by working for a large company. Then move onto working with smaller firms and start-ups. In the podcast, she explains how this can benefit your career. What are your current career objectives? – Cassidy is figuring out how she can earn enough relatively passive income, so she can spend more time working on side projects that interest her. What’s your number one non-technical skill? – Communication, both speaking and writing. In the podcast, Cassidy explains how she went about developing these skills. How do you keep your own career energized? – Working on interesting side projects is what keeps Cassidy’s career energized. It is the main way she learns about new tech. What do you do away from technology? – Cassidy and her husband are musicians, so they both spend a lot of time playing music. She also loves making funny videos and coming up with new jokes.   (22.12) FINAL CAREER TIP Periodically, sit down and have a meeting with yourself about where your career is going. Every quarter or so, review your goals, objectives and what you are working on. Make sure that you are happy with what you are doing and where you are going. At this stage of the podcast, she shares the questions you should be asking to ensure that you stay on track and enjoying the work that you are doing.   BEST MOMENTS (4.34) – Cassidy - “Know what you don’t want just as much as what you do want.” (13.06) – Cassidy - “Technical workers should take full advantage of the freedom being able to work from anywhere offers them.” (18.06) – Cassidy - “Start your career working for a large firm, later you can switch to smaller firms.” (20.01) – Cassidy - “Learn to effectively communicate what you are thinking and don’t be afraid to ask questions.” (22.23) – Cassidy - “Periodically, take time out to honestly evaluate your career and ensure the work you are doing will keep you happy.”     ABOUT THE HOST – PHIL BURGESS Phil Burgess is an independent IT consultant who has spent the last 20 years helping organisations to design, develop and implement software solutions.  Phil has always had an interest in helping others to develop and advance their careers.  And in 2017 Phil started the I.T. Career Energizer podcast to try to help as many people as possible to learn from the career advice and experiences of those that have been, and still are, on that same career journey.   CONTACT THE HOST – PHIL BURGESS Phil can be contacted through the following Social Media platforms: Twitter: https://twitter.com/philtechcareer LinkedIn: https://uk.linkedin.com/in/philburgess Facebook: https://facebook.com/philtechcareer Instagram: https://instagram.com/philtechcareer Website: https://itcareerenergizer.com/contact Phil is also reachable by email at phil@itcareerenergizer.com and via the podcast’s website, https://itcareerenergizer.com Join the I.T. Career Energizer Community on Facebook - https://www.facebook.com/groups/ITCareerEnergizer   ABOUT THE GUEST – Cassidy Williams Cassidy Williams is a software engineer at CodePen and the director of outreach at cKeys.  Previously she has worked for Amazon, L4 Digital, Clarifai and Venmo. She also runs a weekly newsletter and loves teaching and helping people become better coders.     CONTACT THE GUEST – Cassidy Williams Cassidy Williams can be contacted through the following Social Media platforms: Twitter: https://twitter.com/cassidoo LinkedIn: https://www.linkedin.com/in/cassidoo/ Website: https://cassidoo.co/  

On this episode Abadesi talks to Cassidy Williams. Cassidy is a great follow on social media and is a software engineer at CodePen. Prior to CodePen, she worked for Venmo, Amazon, Clarify and others. She is a true maker and a huge mechanical keyboard nerd (which you hear a bit about on the show). In this episode they discuss... How she got to where she is today, including lessons learned from working at big and small companies “It gets more political the more you go up the career ladder. At CodePen, we only have eight people, so you can’t really be promoted, and past Cassidy’s mind might be blown that she can’t be promoted and she’s okay with that.” Cassidy talks her personal career trajectory and how she learned “the hard way” that big money at big companies isn’t all it’s cracked up to be. She talks a bit about working at Amazon and why it didn’t work out for her and explains why it’s just as valuable to know what you don’t want to do as knowing what you do want to do. She also talks about some of the differences between working at a big company and a small company. Her personal definition of success as a software engineer “My definition of success is having the flexibility to build whatever I want. Right now I’m building for CodePen but because my job is so flexible I’m able to build things outside of work. Someday I would love to be able to not have to work and build things for fun, whether for money or not. I love building things in general, whether it be keyboards, code, or Legos.” Cassidy says that she used to be obsessed with “climbing the career ladder” and explains why that’s no longer the case for her. She says that she would go into jobs with the intention of collecting titles and experience in order to make a case for a promotion. She’s realized now though that being at the top is less important to her than the freedom to be able to create and do the things she loves. The future of programming “When I first started using React, it seemed magical, but over time it has changed to be a lot more granular and less magical. That is a very interesting metaphor for a lot of things that are happening in the tech industry.“ She talks through some of the trends in software engineering, including how programming for the web has changed over the past few years. She explains how and why languages and the way that programmers use them have evolved over time. “People want to be more granular with their coding and engineering practices. A lot of people want to get to the core of adding more low-level and theoretical computer science practices to web development.” Why she loves mechanical keyboards so much “It’s so fun to be able to build something that is both pretty and functional. Typing on them is actually really fun. Typing on a mechanical keyboard feels like actually accomplishing something. When you feel that tactical feedback, it’s great.“ While doing the interview, Cassidy mentions that she had nine different mechanical keyboards sitting next to her. She waxes poetic on the virtues of using and building mechanical keyboards, including a breakdown of some of her favorite builds. She also talks about some of her other favorite non-keyboard products as well. We’ll be back next week so be sure to subscribe on Apple Podcasts, Google Podcasts, Spotify, Breaker, Overcast, or wherever you listen to your favorite podcasts. Big thanks to Copper for their support.

Cassidy Williams is an engineer at Codepen. In the last five years, Cassidy has worked for five companies. She had left each on her terms as she learned through experience what she wanted and didn't want. Figuring out what you like and what you don't like is critical for ending up somewhere that you're happy with, Cassidy calls this establishing your personal brand. The term "personal brand" has negative connotations to it, it seems unauthentic, but really what it means is figuring out who you are and making that public, it's as authentic as you make it. Kent challenges you to take five minutes and write down what you like and what you don't like. Afterward, reflect on that list and ask yourself if where you're at now lines up, if it doesn't dig deeper into figuring out how to make the necessary changes for your life to align more with your likes and dislikes. Resources Boundaries Cassidy Williams Twitter Website Github Kent C. Dodds Website Twitter Github Youtube Testing JavaScript

Cassidy Williams is a Senior Software Engineer at CodePen. Before joining CodePen, Cassidy worked at a ton of different companies ranging from startups to Amazon. During the interview, we talk about her journey from beginner to senior and Cassidy shares her own strategies for growing as an engineer. Cassidy on the internet: https://twitter.com/cassidoo

Cassidy Williams is a Senior Software Engineer CodePen in Seattle — using React, Redux, GraphQL, and Apollo Client to build the frontend of CodePen and CodePen Projects. Chantastic asks about building a startup on a plane, maximizing side hustle effort, the importance of networking, and what it's like to meet your heroes. They discuss tips for getting great advice from smart people, building passive income, finding safe workplaces, and what it looks like to lift as you climb.

Welcome back to another episode of The Decoding Success Podcast. Today, I'm joined by my wildly successful and insightful friend, Cassidy Williams. Cassidy and I talk about finding the courage to spearhead initiatives to create a greater tomorrow, overcoming challenges when you might feel alone, creating flexibility in your life, and so much more! Want a free Audible book? Make sure you listen in to the intro! Make sure you connect with Cassidy: Twitter - https://twitter.com/cassidoo GitHub - https://github.com/cassidoo LinkedIn - https://www.linkedin.com/in/cassidoo/ http://cassidoo.co/ Find Me On Social: Instagram: www.instagram.com/matt_lebris/ Twitter: twitter.com/Matt_LeBris LinkedIn: www.linkedin.com/in/mlebrisnyc/ Facebook: www.facebook.com/TheMattLeBris/ www.mattlebris.com Rate, Subscribe and Share!

The Division III basketball season is nearly a month along. We have reached the first quarter pole of the season to evaluate where everyone is and where teams are headed. There have been plenty of surprises, upsets, teams stubbing their toes, and more. There are also some who are doing well despite maybe not being fully saddled when they left the gate. On Thursday's edition of Hoopsville, Dave takes a look at three programs which had very late coaching decisions and how those decisions have affected the programs. Two teams, Salisbury men and Trine women, saw their coaches suspended and then fired in the month leading up to their first games. Another, Brandeis men, saw their coach make national headlines, be fired, an interim hired, but then that decision reversed and a new coach hired just two weeks before practices began. All three, are off to terrific starts accounting for a total of two losses on the season so far. What is it like to adjust to a last minute coaching change? What is it like to take over a program, or enter an athletic department and school, in such perceived turmoil? How hard is it to put the blinders on and focus at the task at hand? We follow up Ryan Scott's terrific story recently with a chat with two players and a coach on the experience of dealing with change. Plus, after years of waiting it finally happened! Division III women's basketball is getting it's own All-Star Game! Williams' coach Pat Manning discusses the long journey to the announcement, how they found a sponsor, and why the game will be the center piece of changing the women's Championship Weekend altogether. Hoopsville is presented by D3hoops.com and airs from the WBCA/NABC Studio. Guests Schedule (order subject to change): - Jean Bain, Brandeis men's coach - Chase Kumor, Salisbury men's senior - Cassidy Williams, No. 11 Trine women's senior - Pat Manning, Williams' head coach & WBCA All-Star Game Committee member

Cassidy is really into mechanical keybards. She talks about how she got into keyboards, some keyboard vocabulary, and the Scrabble keycaps she launched on Massdrop.

Cassidy Williams, head of developer voice programs working on Alexa for Amazon. We talked about voice-first user experience, designing voice-first with a screen, building feedback loops into voice-first tools, the future of voice-first computing and more.

Why aren't there more women and girls working in industries that allow them to change the world? Our guest is Cassidy Williams, and she is doing her part to change the equation.Cassidy Williams, AdvisHerCassidy Williams is a computer programmer and computer science senior at Iowa State University, scheduled to graduate in May 2014.She has worked at a variety of companies including Intuit, Microsoft, and General Mills and plans to work on the front end in web or mobile development.She co-created AdvisHer to help other girls get started in the STEM industries (science, technology, engineering, and math). The online community leverages the power of pipeline programs to advise, advocate, and accelerate women in STEM related jobs around the world.The project won a hackathon as part of British Airways' UnGrounded -- the first innovation lab in the sky, designed to connect industry leaders and creative minds for the purpose of tackling challenges that affect the next generation of global innovators. Cassidy was a member of Team Altitude, who were assigned the challenge of how to foster women in STEM positions... on one flight from San Francisco to London.She is also a public speaker and has addressed audiences at events like the National Center for Women & IT Summit, the U.S. Department of Labor's Diversity in Tech event, the IINSPIRE (Iowa-Illinois-Nebraska STEM Partnership for Innovation in Research and Education) conference, TEDxDesMoines, and even at the United Nations.

Why aren't there more women and girls working in industries that allow them to change the world? Our guest is Cassidy Williams, and she is doing her part to change the equation.Cassidy Williams, AdvisHerCassidy Williams is a computer programmer and computer science senior at Iowa State University, scheduled to graduate in May 2014.She has worked at a variety of companies including Intuit, Microsoft, and General Mills and plans to work on the front end in web or mobile development.She co-created AdvisHer to help other girls get started in the STEM industries (science, technology, engineering, and math). The online community leverages the power of pipeline programs to advise, advocate, and accelerate women in STEM related jobs around the world.The project won a hackathon as part of British Airways' UnGrounded -- the first innovation lab in the sky, designed to connect industry leaders and creative minds for the purpose of tackling challenges that affect the next generation of global innovators. Cassidy was a member of Team Altitude, who were assigned the challenge of how to foster women in STEM positions... on one flight from San Francisco to London.She is also a public speaker and has addressed audiences at events like the National Center for Women & IT Summit, the U.S. Department of Labor's Diversity in Tech event, the IINSPIRE (Iowa-Illinois-Nebraska STEM Partnership for Innovation in Research and Education) conference, TEDxDesMoines, and even at the United Nations.