Screaming in the Cloud - Open Sourcing GitHub with Denise Yu

Episode Date: May 13, 2021

Links:Github main site: https://github.com/The Open Guide to Amazon Web Services:https://github.com/QuinnyPig/og-awsSlackhatesthe.cloud: slackhatesthe.cloudGlobal Diversity CFP Day: https://www.globaldiversitycfpday.com/Twitter: https://twitter.com/deniseyu21Personal site: deniseyu.io

Hello, and welcome to Screaming in the Cloud, with your host, Chief Cloud Economist at the Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud. This episode is sponsored in part by Thinkst. This is going to take a minute to explain, so bear with me. I linked against an early version of their tool, canarytokens.org,

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

whatever you want to. When it gets NMAP scanned or someone attempts to log into it or access files on it, you get instant alerts. It's awesome. If you don't do something like this, you're likely to find out that you've gotten breached the hard way. Take a look at this. It's one of those few things that I look at and say, wow, that is an amazing idea. I love it. That's canarytokens.org and canary.tools. The first one is free. The second one is enterprising. Take a look. I'm a big fan of this. More from them in the coming weeks. This episode is sponsored in part by VMware. Because let's face it, the past year hasn't been kind to our AWS bills or honestly any cloud bills. The pandemic had a bunch of impacts. It forced us to move workloads to the

cloud sooner than we would have otherwise. We saw strange patterns such as user traffic drops off, but infrastructure spend doesn't. What do you do about it? Well, the CloudLive 2021 virtual conference is your chance to connect with people wrestling with the same type of thing. Be they practitioners, vendors in the space, leaders of thought, ahem, ahem. And get some behind-the-scenes look into various ways different companies are handling this. Hosted by CloudHealth by VMware on May 20th, the CloudLive 2021 conference will be 100% virtual and 100% free to attend. So you really have no excuses for missing out on this opportunity to deal with people who care about cloud bills. Visit cloudlive.com slash Corey to learn more and save

your virtual seat today. That's cloudlive.com slash Corey, C-O-R-E-Y, drop the E, we're all in trouble. My thanks to VMware for sponsoring this ridiculous episode. Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by Denise Yu, who's a senior software engineer at a company that mispronounces itself as GitHub, but is actually pronounced Jithub. Denise, welcome to the show. Thanks so much for having me, Corey. I am excited to scream in some clouds with you. Yes, and I do want to point out that Jithub is not accepted by the Jithub marketing team, and they're upset. But that's the nice thing about this being my show. They don't get to dictate the nonsense that I say. But this is not you endorsing my correct pronunciation as an

employee in any way, because that's not your role. You're a senior software engineer. What do you do? So I work on a bunch of different things. I actually originally joined GitHub back in March at the beginning of this global pandemic that we're still living through somehow in the year 2021. But I joined a year ago to work on a team called Community and Safety. That team has been rolled into other teams by this point, partly because the original team did too good of a job at creating abuse prevention tools for the platform. But these days, I still work on community-facing tools, which is very exciting. I'm actually in a department called Communities, and our whole charter is build tools that make

life better for open source maintainers. So that's a mission that I'm actually really excited about. I think of all the products that I've worked on, this is one of the few that I can say, like, I actually, like, really want to make life better for the end users. Oh, absolutely. For better or worse, GitHub or Jithub has taken a central role in the open source community. And on some level, I find it, how do I frame this? Kind of weird in that we've taken this protocol that is widely decentralized and that's its entire point.

Well, what do we do about this? Oh, immediately we're going to recentralize it. That's the right answer. And it just never ceases to amuse me that that's what we have taken from it as a society, but it works. I can't argue otherwise. And I maintain, and this is a bet that I am definitely going to the wall with, that in

five years or so, we are going to look back at Microsoft acquiring GitHub as a transitional moment. Yeah, I think so. I think even though the Git technology is built for resilience and distributed work, I think what GitHub as a platform has shown that the process of building software is more than just pushing lines of code, right? The code is the artifact of collaboration, but we still need a place to do that collaboration, which is why I've been using GitHub for five or six years now. And I only realized a few years ago that things like pull requests and issues

don't exist outside of GitHub. That's an abstraction that's so, so deeply baked into my idea of what it means to work collaboratively that didn't exist until GitHub invented it, which is pretty wild. Yeah, it's bizarre in a number of different levels, but so much of what we think is part of Git is not. It is the GitHub abstraction, but it's also something that is widely copied by all of GitHub's competitors in many respects. So the line has gotten very, very blurry. And how people come to Git is also fascinating. I used to go to a Git training, I think in 2009,

conducted by a GitHub employee. I may be misremembering the year by a few years in either direction. And it was a multi-day process and it was complex. And I left it feeling in many ways like I had more questions than I answered. Now I point people to a GitHub page that talks about how to use Git

and they're mostly there. So it isn't that Git necessarily has improved as a product. It's that GitHub has made it far more accessible. And let's face it, after a few million times practicing, you get very good at explaining complicated things in simple ways. Oh yeah, for sure.

It's not a huge surprise that internally we use GitHub for everything. So if you want to, I don't know, collaborate on writing even like a new blog post, new marketing copy or new documentation, all of that happens through GitHub. And I think that people with different levels of proficiency with command line, actually, like they say, you don't even need command line.

You do everything through the UI, which I think is pretty neat. Oh, it's phenomenal. And I do want to call out that I am the maintainer of an open source project on GitHub. We know it's good because it has 28.3 thousand stars at time of this recording, almost 3,000 forks. And what it is is the open guide to AWS. It's a big markdown document that more or less explains what all of the AWS services do. There are over 200 contributors. We have a online Slack community at slackhatesthe.cloud because they don't like open source community stuff very well and we make fun of them for it.

But my point being is that even without knowing how to write a single line of code, this is more or less just a big readme that explains different aspects of what AWS is because it's incredibly hard to adjust to that. And that is every bit as much an open source project as anything that's included in NPM or any command line tool that you'll use

in any aspect of your job. Yeah, exactly. And I think the nice thing about editing a document like an AWS guide or anything else really, a couple of years ago, I would have said, okay, that sounds like it should be a wiki page. Wiki pages support revisions, collaboration, or maybe a Google doc or something. But the nice thing about putting it somewhere like GitHub is like, well, you're already probably all your other tools already integrate into GitHub, right? Like you

maybe get Slack notifications when you have a PR that's, you know, requires review or whatever it is. It's just so much easier to have everything in one place. And you also get like the cool green squares for contributing. Oh, of course, the most important thing is fill that thing up. It's talk about gamification causing weird behavior patterns. Yeah, we have a GitHub workflow on this that fires off on every pull request that looks at the entire site and validates the thousand and some odd links are still resolving and valid. Because when you link to this many different sites across the internet, link rot's a real thing. And it's depressing and sad to be able to look at this

and, oh, that didn't work. Now, we do have to fix some of this because it winds up in some cases flagging people's submitted pull requests as not being valid, but it has nothing to do with what they're submitting because I'm bad at this. But the fact that that's built in

and is available for use is incredible. Every time I'm bad at this, but the fact that that's built in and is available for use is incredible. Every time I look at GitHub site, it's gotten better than the last time I looked at it. Oh, that's so nice. Well, I can't shake the feeling that at some point, there's going to be at the proper moment, a deploy to Azure button that as soon as someone clicks, whatever they've written is suddenly running in some environment in Azure. Now, if it comes too soon, it's going to be terribly implemented and no one's going to trust it.

If it comes too late, then people will already have solved this problem in different ways. So timing is going to be critical, but that is going to be, well executed at least, a potential sea change in how people approach cloud and what the default environment to run something on is. Wait, have you looked at Codespaces or seen the demo around that?

I was hoping you would bring those up. Back in the before times, I would travel kind of a lot, and the only computer I brought with me was my iPad. Yeah, a lot of people do this. Oh yeah, trying to get an environment on an iPad. It turns out it's not terrific. The solution that I fell back to was, well, I've been using VI for 20 years, so I'll just SSH into an instance and call it good. But there were interesting projects of varying degrees of success that would run VS Code in a instance somewhere and then just present its interface as a web page. GitHub has actually

integrated this as a core offering. All right, you click a button, it spins it up, and it's there. And oh my god, is that better? Yeah, I think it's still in limited beta. So I think you still have to request access to I don't know if this will still be the case in March. But yeah, I've tried it out a couple of times. And it works really, really well. My only gripe is that I don't like to use VS code. So I'm going to have to learn VS Code in order to use it. I've got to say that is my single biggest barrier to adoption. I already know how to use VI, but a lot of the VS Code stuff,

if you're having a full-featured IDE that does all of these things, is extraordinarily heavy of a lift for me. It more or less is breaking 20 years of muscle memory. Yeah, tons of my coworkers love VS Code and use it every day. I only know how to use RubyMind for large monolithic Ruby development.

And if I'm not doing work on the monolith, I don't want to use an IDE. Otherwise, I want to just use VI. If I'm working in a small enough code base where I know the name of every file, then I don't want to use the IDE for it. VS Code to me sits in this middle ground that I know I need to learn how to exist in that middle ground, but it requires me going off to the internet and hunting down every single plugin that I need to

put onto VS Code to make it feel like RubyMine again. And that's the thing that I don't want to do. Well, I'll take it a step further. And most of the tutorials I see about how to get up with VS Code as an IDE are JavaScript-based, or JavaScript, depending upon pronunciation, once again. And my lingua franca is crappy Python. So whenever I look for, oh, I want a VS Code tutorial for Python, the first eight pages of it are, here are the different ways you can do virtual environments and dependency management, because that is Python. It focuses on that,

and it winds up getting hung up on those implementation details before ever getting to, here's a reasonable Python project that someone who's not very good at Python can understand, and here's how VS Code can add value to it. I mean, those posts exist, but they're hard to find. And it honestly makes me feel like an imposter for not knowing JavaScript.

Yeah. The feature that I use the most in a full IDE like RubyMine is command click to go to definition. And with Ruby, you get the correct definition about 70% of the time, but it's still better than nothing. Because if I'm not doing that, I'm doing a full text search for the method definition. And that's like, my brain can only work with one of those two things. With VS Code, after 15 minutes of trying to find the right plugin that does click to go to definition and failing, I was just like, this is just not worth it. Nobody should have to live through this much pain. It's like, I don't, I don't want to do this anymore. Exactly. It becomes this situation where at least when you're starting to learn something, it's breaking everything you're used to. And it

feels like instead of helping you, you're fighting with it. Yeah, this reminds me of how people talk about switching their keyboard layout to Dvorak or whatever. Oh my god, I want to do that on one hand because I'm deep into the mechanical keyboard space, but on the other is I don't really have six months to teach myself to type all over again. Yeah, that's the thing. It's like maybe it'll speed up my typing by like two 2%, but I already type really fast. I think I would have extremely diminishing returns on that. But also like, I don't want my brain to just not work for weeks or months. Oh, and it's worse than that because as soon as you leave that and go onto someone else's computer, which admittedly is not nearly as frequent as it used to be when I was in

help desk and desktop support. Oh, can you type in your password on this thing? Absolutely not. Thank you for asking. It's effectively having to go back and restart it over. I understand that it's more efficient, but you need a societal shift to it, not individuals doing it piecemeal. Yeah, that's true. So you're relatively recent as far as hires over at Jithub.

You joined mid-pandemic or early pandemic, depending on how you want to slice that, and you've never been to their headquarters. What is that like? Everyone keeps telling me how awesome HQ is, and I'm like, cool. I actually have a brick wall in my office that looks like some of the spaces in HQ, I guess, so people get super confused and I tell them that I'm in Toronto. Oh yeah, I've been to HQ a bunch of times for various things. It's great. You really got to see it.

I'm not helping, am I? You're really not helping. I really want to go to HQ. I was meant to go to HQ in March. So my start date was March 13th or 14th. I can't remember, in 2020. And I was part of the first onboarding class to not get to go out to HQ

because that was when the travel restrictions around COVID were finally being implemented. So I'm very sad about that. I will say that GitHub has the advantage of a lot of other companies in that, to my understanding, they had a remarkably resilient remote culture before this all hit. Is that correct? Or am I misremembering my history? No, you're right. I think the figure was 75% of employees don't live within commuting distance to HQ when I first joined. Well, not with that attitude. Yeah, that's true. We just got to try harder. But I think that number is a lot higher now because

we have been hiring internationally and we've grown a lot in the last year or so that I've been here. Yeah. So I think we were better equipped grown a lot in the last year or so that I've been here. Yeah, so I think we were better equipped than a lot of other companies to go full remote because it basically just was telling that 25% of employees don't come into HQ anymore and giving people a little bit more office budget, I guess, to get set up fully for full-time remote work. There are a lot of challenges, though, especially when you join as a remote employee and you've never worked in a fully remote environment before. It took me a really, really long time to get used to the fact that Slack was my portal to everything. Oh, yeah. Here at the Duckbill Group, we were full remote from the beginning just because I decided to merge my consultancy with my business partners 10 days before he moved from across the street to Portland, Oregon. So we at that point

decided, all right, we're full remote. And we've never had a critical mass of staff in one city to the point where there became a de facto headquarters. Because as soon as that happens, it changes your culture. Trying to retrofit something like full remote to a company that historically has always been face-to-face, it shatters a lot of the dynamics. So on some level, it was easy for us. On the other, it feels like we're at a bit of a disadvantage in some respects once things return to normal. But that's a future problem, unfortunately. Yeah, I think the biggest thing is learning to work asynchronously,

which GitHub was already pretty good at. So I'm pretty used to opening a PR on Wednesday evening, for example, and not really expecting to get feedback on it until the next day, Thursday or even Friday, especially if I need feedback from a different team. Actually, that's something that I've learned since joining GitHub. That wasn't something I was used to before, because I've only ever worked in co-located environments before. If someone didn't review my PR in time, I would take a Nerf gun and go over to them and gently ask them to review my PR. But it's been very

interesting. So I also used to work at Pivotal, which I'm sure you've heard rumors about our kind of cultish pairing culture. So my default state of working was to constantly be talking to another human about what I was doing all the time. And so suddenly joining a fully remote company in a time when we have to work a little bit more asynchronously than before because people's lives are just completely upended by this pandemic. That was a big adjustment. So in the before time, something else that you were effectively renowned for was not only giving conference talks yourself, but helping other people give conference talks too. Let's talk a little bit about that because speaking at conferences was always one of my passion projects because I love the sound of my own voice. Simply love it. And helping other people do that too was

also something I was very interested in doing, but it was always hard for me to get traction around getting people to let me help them for reasons that are probably blindingly obvious to everyone except me. So tell me about that. What's the story? Yeah, so I have always been pretty comfortable speaking in public. I think it's something that I almost took for granted. And the reason for that is because I spent upwards of 10 years of my teenage and adult years doing competitive debate. I was traveling to debate tournaments pretty much every single weekend in college and spent a lot of time doing both like structured and off-the-cuff speaking in front of large groups of people. And when I got into tech, it took me a long time to realize that not everyone is like me. I kind of had this special strand, I guess, of imposter syndrome where I think that if I know how to do a thing,

then everybody else knows how to do that thing also, which is aggressively not a correct assumption to make ever. Oh, same here across the board. It's one of those, like, I thought for a while I fit in tech because the stereotypes seem to fit me super well. It's like, yeah, we're bad with people. Absolutely. We prefer dealing with computers to humans. Absolutely. I hate my boss. Absolutely. I'm good at programming. Oh, okay. Nevermind. But yeah, there's a lot that I think people miss about what it takes to give a good talk. It's not technical mastery. It is an ability to tell a story. Exactly. I think you hit the nail on the head there. And so after I realized that, okay, I am at least at the median. I actually think I'm quite good at public speaking and telling stories about technical subject matter

and breaking things down in a way that someone without as much technical context as me can understand it. The thing that got me into doing more and more public speaking, specifically at tech conferences, was after I gave my first talk, people just kept coming up to me basically and being like, hey, I saw you talk at this conference. Do you want to come talk at this other conference that I'm running or whatever? I think once you get a couple of larger stage conference talks under your belt, you almost don't really have to look for speaking opportunities anymore. No, they fall into your lap. And then you have different problems such as, oh, I've been invited to speak at this conference. Let me do some checking to figure out, are they a trash fire or are they

a reasonable place? Yeah. Am I going to be the only not white guy speaking at this conference? Right. Am I going to be on a mantle? I won't do it. Is there not a code of conduct that has actual teeth and doesn't treat it as a joke? I won't do it. And that stuff is way more important to me than the technical content of the talk. For sure. for sure. But tying it back to even the stuff that GitHub does, one of the talks that was transformative for how I approached this was a Git talk, Terrible Ideas in Git. And I like to teach people things by counterexample. And the first iteration of that talk would have been great

if the Git maintainers themselves had been the target audience for this, but two people would have loved that, and the rest of the audience would have been looking at this with, what the hell are you talking about? Yeah. So I had to refactor it, and it made it a far stronger talk, all the way to the point where there's jokes for everyone in there. But my favorite time giving the talk,

I said that I now need to be able to explain Git in such a way that my mother would understand it. And that is a problematic way of framing on ageism and sexism basis in most cases, but not this time because she's sitting in the front row. Hi, mom. That was one of my favorite speaker moments that was just, it's hard to get that one pulled off, mostly because getting my mother to fly to various parts of the world and watch me speak is a bit of a heavier lift than one expected. But here we are. Yeah, I use a similar litmus test for my stepdad. My stepdad is not a technologist. He is a

biologist by training, actually. But he asks me a lot of questions about what I do. And back when I worked at Pivotal, I had to explain cloud virtualization to him every time I went home. I don't know if it's gotten easier with GitHub. I feel like GitHub is a little bit easier to explain to the average person than Cloud Foundry. But my bar kind of is, every time I put together a talk, do I think that my stepfather could understand the content? or the enterprise, not the starship. On-prem security doesn't translate well to cloud or multi-cloud environments, and that's not even counting IoT. ExtraHop automatically discovers everything inside the perimeter, including your cloud workloads and IoT devices,

detects these threats up to 35% faster, and helps you act immediately. Ask for a free trial of Detection and Response for AWS today at extrahop.com slash trial. Increasingly, I found the best way to explain GitHub to folks who aren't familiar with it and are non-technical but work in the business space has been, you know how Microsoft Word has track changes?

Yeah, imagine that, only without the copy of copy of file final. Use this one, date. dot a PDF dot doc. Yeah, imagine that. Instead, this makes this streamlined and easy for multiple people to work on at the same time, at which point they stare at you hungrily and say, oh, my God, how can I use this for my work? And I feel like there's a breakout moment waiting for GitHub if they ever decide to focus on that part of the market, because, my God, is there an appetite for it? Yeah, I think that kind of revision-driven editing, I think that's applicable to so many different domains. I've heard people

experimenting with the idea for, I think Figma does something similar for designs and for visuals, but I've also heard the idea floated of this being done for sound mixing, sound engineering, which I think would be super, super cool. I don't know how you could visualize that, but someone who has more knowledge of that space, I'm sure could come up with a way. Oh yeah. The challenge I find with stuff like that for podcasts, for example, is GitHub gets very, very angry because Git gets very, very angry when you start doing things like checking in large uncompressed media files and then making small changes to them but you can't diff that so every revision for video work is oh here's another 150 gig file to put up and that becomes a problem yeah yeah there's there's

a lot that's neat out there i also want to credit github with fixing the state of working with git because let's face it, Git makes everyone feel stupid at some point. The question is, is just how far along are you before that hits? And invariably, the approach was always, when you get into that territory, you wind up asking the question on some forum somewhere, and then you wind up getting, a few minutes later, this giant essay where it starts off, well, Git is not really a version tracker. It's instead a distributed graph that, and then you just skip down eight paragraphs to the bottom where they give you the one-liner that fixes the problem. GitHub has fixed

the result of queries for how do I X in Git and just gives you the answer outright. It's transformative. And it's one of the things that everyone takes for granted because no one really stops to think this documentation is awesome and accessible and answers my problem. But the result of it is, is that you just don't see people complaining about how hard Git is anymore. Yeah. Yeah. Oh my God. Git is so hard. Like I think the first time I correctly did an interactive rebase, like I typed all the arguments correctly. I think I just got up and did a lap around the office. There's just all this random stuff that you have to remember when you're using, especially,

you know, some people use desktop GUIs or whatever. I always just use command line, but it took forever. And I still make a ton of mistakes with it. Oh, we all do. That's the beautiful part of it. The nice thing is, oh, well, the nice thing about Git is that nothing ever really gets truly lost. And you say, well, how do you figure? Oh, I copied the entire directory to a backup before I do anything, which is, on the one hand, awful version control, and two, has saved my bacon multiple times. So, you know, if it's stupid and it works, it's not really stupid, now is it? It's not stupid if it works. So a passion project of yours that I want to talk about has been teaching people to submit to conferences, to give talks at conferences, to convince them that, yes, you can do this and you're good at it. You have a story that people want to tell.

The things you find easy are not easy for everyone. Give that story a voice has been a recurring theme that you do. How has that manifested during this year of isolation? This year's definitely been tough. So usually when I do that pitch, I run workshops specifically around a certain CFP. I help out conference organizers in the Toronto area. I did a workshop for DevOps Days last year

and another one for GoCon, also meant to be last year. And usually it's like, okay, here's how you write a strong proposal. And I'll have the committee in the room be like, here's what the committee is looking for. Ask these people questions about what they would choose to program. And this is how you get your talk submitted. This is how you get accepted. You need to understand who your audience is. It's a product question, right?

It's exactly the same mindset that you need to get into when you're playing product manager or if you're actually a product manager. You need to understand who your target customer or audience is, what they're looking for, and how do you give that to them on a plate. This year, it's slowed down a lot, obviously, because there have been fewer conferences. So I've just had fewer opportunities to do this kind of pitch. It feels weird telling people to write talks without there being a place to submit a talk to. But I think I found that there still is room for content creation, even if that isn't a conference talk. So within the company, within my networks, I do try to encourage people to write blog posts, err on the side of writing what you've learned. If you spent a couple of days doing a technical investigation and you found it interesting, write it down so other people can learn about it.

On the conference talk front, I think the unique benefit of doing conference talks and getting up on stage is you do build a personal brand after a little while that kind of transcends the company that you're at. Granted that you're not talking about your company's products in every single talk. Absolutely. And a lot of companies get profoundly insecure about that. And I'm sorry, they're wrong. That is And a lot of companies get profoundly insecure about that. And I'm sorry, they're wrong. That is not a bad thing. Anyone who gives a talk for your company will eventually

become better known than your brand for some aspects and in some areas, harder at places like, you know, GitHub than it is Twitter for pets, but that's okay. And you have to be okay with that and have a plan for how you're going to transition them out when they outgrow the role and move somewhere else. But that's okay. And companies that are insecure about that drive me up a wall. Yeah. There have been a few times when I went to very cloud-specific conferences and talked about things that my company was working for. But other times I've gone to just very general conferences where it was just like, let's talk about agile or let's talk about software, like super, super generally. And the ones where I've gone to the really general conferences and talked about things that matter to me, like cross-functional

collaboration or test-driven development or whatever it is, those are the ones that I've actually managed to get people to apply to my company without even saying that we're hiring. It's a little mind-blowing. It is. People want to work with interesting people. And when you find someone who's able to tell a story that touches you on some level, which is the point of telling stories, then you, at some point, the idea of, I'd like to work with that person on an ongoing basis becomes actively compelling. People ask, so, well, it's not like you could hire a whole lot of people who do what you do. So hiring and recruiting has got to be a problem. It's like, well, it is, but it's because it's

finding the right people with the right alignment. But we have an awful lot of gadgets to choose from for basically any role, just because, for better or worse, I make a splash. Yeah, exactly. So as people are looking to get into the space and they're new to speaking, how do you get them to a point where there's at least a certain level of confidence. I would say, how do you get them to not be terrified? But I've been speaking almost full-time for years, and I'm still scared to death every time I give a talk when I start out. Me too. I'm still terrified. I almost switch into a different persona when I go on stage,

and I don't remember anything that happens. I don't know what—maybe there's psychology around this, but I literally blank out the 40 minutes that I'm on stage. So the most common objection that I hear about why someone doesn't want to give a talk is they'll say, but everybody already knows about this. The thing that I want to talk about has already been talked about. There's already too much content out there. I wouldn't add anything new. And for a long time, like my response to that was just like, I don't

care. Like, I still want to hear what you have to say. Like, you're going to offer a fresh perspective. You're going to offer a new experience. You're going to explain something in a way that clicks for someone. Your explanation might be the one that works for them that they haven't been able to figure out by listening to anybody else. So I like historically said those things and I still 100% believe those things. And I still say those things to people. But I actually came across something interesting on Twitter today. Someone was actually talking about fan fiction. I don't know if you've like written or like read fan fiction in the past. When I was a kid, I used to... I can neither confirm nor deny. There's varying levels of fan fiction out there, but fan fiction communities are actually incredibly

collaborative places. I remember being, I don't know, like a 10 or 11 year old and writing a lot of anime fan fiction, basically just writing myself into like the Pokemon universe and things like that. And we would post these on forums, like it would be forums of strangers working together and we post drafts. And then we would give each other feedback on those drafts. And in the end, like there'd be, you know be 60 different pieces of fan fiction, roughly about the same universe. Every story is a little bit different. And nobody was ever self-conscious that this had already been done. Because the whole point of fan fiction is that there's a lot of it. The value of the community is in the fact that the content is abundant, not that every single piece of content is unique.

So I think a similar thing is true for content that's technical storytelling. Just because someone else has said this thing before, it doesn't matter. The fact that there's more content out there about this thing is good for the community, like building a community around this thing. So I don't know. That was something that just resonated with me a lot. And I just really like that framing. We have this weird perspective that the things that we know are easy, the things we don't know are hard. So once you've learned how to do something, everyone else knows it. I mean, one of my most popular Twitter threads that exploded that I didn't see coming was just me talking about random things that live in my shell config file and what they do. It's stuff everyone knows and everyone has something like this,

right? And it got into a dissection of what these things do and how it works. And of course, it's snarky because that's my excuse for a personality. But it also shined a light on something that I forgot. Once again, not everyone knows this. A lot of the viral tweets you see going around are people noticing something that we've all seen and been ignoring because that's just the way it is. And someone makes an observation about it. And, oh, yeah, that's right. That is something that everyone can relate to. Yeah.

People want stories. Yeah, exactly. I think about every six months, I try to retweet every review cycle or around mid-year, end of year. It's like, hey, just a reminder, if someone on your team has done something for you, write this down. Catalog what they did, write it down, send it to them, send it to their manager, put it into their file so they can use it at review time. And every time I talk about this, I always get a ton of engagement. And I have to remind myself that this is not obvious. Even if someone was told to do this at some point in the past, reminding people to be deliberate and be active about giving each other peer feedback, writing stuff down. You just can't remind people to do

that enough, I think. Yeah, it's one of those things where, well, I've already given that talk, so I have to give a different one. No, you don't. I promise you, you have not given your talk to everyone in the industry. And the reason I know that is because by that point, you would see the view count on YouTube or whatnot, or the video winds up and be flabbergasted because the industry is bigger than anyone thinks. I feel like I tell the same joke from time to time, but they always get laughs from the audience because it's new to them. romantic partner find it incredibly challenging both. Those are two people, incidentally. And they find it incredibly irritating because yes, yes, we've heard that one. And every once in a while they sit up, oh, Corey got a new joke. But the rest of the world doesn't respond that way. Yeah, exactly. So I don't know if we've talked about this already, but that closes the loop on the whole imposter syndrome piece where just because I think one strain of imposter

syndrome is telling yourself just because I know this thing means everybody else must also know it. Like I must be the last person in the world to learn this piece of information. There is no piece of technology or anything even tangentially related to technology that you couldn't do a tweet thread on and people would learn things about it. Like how an if-then-else loop works, for example. That is, sorry, yeah. Do you see what I'm talking about? That's exactly what I mean. See, I meant to say conditional

and instead I said loop. And we all trip over these things. They're all challenging. And the fact that we can still learn new things about that, how does a flow control conditional actually work? What does that mean? Sure, anyone who spends their days writing code all the time is going to have some topical understanding of it, but not everyone's going to first be that person or secondly, understand why that's valuable and relevant. You could do an entire conference talk on nothing

more than that concept alone, and it would be a dynamite talk. Yeah, exactly. I did go through a wave of imposter syndrome around last year, or maybe, I don't even know what year is it, a little while back. I was feeling uncertain about this talk about distributed systems that I've done a few times. And then I got a random message on Twitter from a student who told me that she had just gotten her first engineering role out of university, ever, ever. And she said, I watched your talk on distributed systems. You gave me the vocabulary to talk about this stuff in an intelligent way, and I've landed my first role as an entry level.

I forget exactly what kind of software engineering, but I forget if it was infrastructure or app dev, I don't know. But it was that kind of feedback that's really cool to hear. I'm going to take it a step further and request anyone listening to this who's seen a talk that has potentially changed the way they view things or helped them advance in their career, track down whoever gave that talk and send them a message. One of the hardest parts about being a speaker is that you very rarely get feedback. Even on this podcast, I almost

never get direct feedback online. People talk to me about it in person when they run into me at a conference in the before times, but it's not a thing where people wind up drafting an email. Dear sir, I found your podcast to be compelling and also you are a jackass. I would love letters like that. Well, I don't love letters like that, so please don't write me letters like that. Well, in my case, they're well-deserved. In your case, it would just be offensive. But yeah, reach out to the strangers whose content you've learned from. I think it can actually make someone's day. Absolutely. So on the other side of that, if someone's listening to this and they want to

start giving a talk, but they don't know where to start, how to build a CFP, where to begin. Where should they start? What is the next step for those people? So there's an initiative that I, in the before times, mentored and helped organize local chapters for. It's called Global Diversity CFP. It's either Global CFP Diversity or Global Diversity CFP. I always forget, day. And even if you're not a person who has a marginalized identity, they've done a really, really great job of consolidating a bunch of

resources to get first-time speakers off the ground. And we will put a link to that in the show notes, of course. Cool. So I recommend just reading through what they have. So it's actually an event that takes place on a full day. It's a little bit different this year. I think they might be running it remotely this year. But all of their content is geared for first-time speakers, and they have a lot of material that's pepping people up to take the first step. But I would say that beyond that, the best way to get started, honestly, is to just pick a topic that you care about and just try to write a talk.

And if you don't have a place to deliver that talk, if there's no meetup or a conference or anything coming up, you should just record yourself giving the talk to your computer. Actually, this is a thing that my debate coach used to have us do in college. The best way to improve as a speaker is to record yourself speaking and watch it. It's going to be terrible the first few times because you're going to be like, oh God, I look so awkward. Power through it. I still can't watch myself speak. Like what are my hands doing? But you can only catch those things and improve at them once you're aware that you're doing them. So that is like the fastest way to improve your presence and

your speaking ability. Yeah. I want to thank you for taking the time to speak with me and go through all these various topics today. If people want to learn more about you, where can they find you? So you can find me on the internet on the cursed blue website at denisiu21 is my handle on Twitter. My personal website is denisiu.io

because I used to have.com, but some kid stole it and squatted on it after I forgot to renew it. So I'm not DeniseU.com anymore. Yeah, the joy of changing usernames on different platforms and the rest, I hear you. Yeah, but yeah, probably those two places. If you want to talk about anything

that I talk about on the podcast, feel free to DM me on Twitter. Please don't send me mean feedback that starts with dear sir in my Twitter DMs. But other than that, I'm... Generally never a good plan for anyone. Thanks so much for taking the time to speak with me. I really appreciate it. Yeah, thanks so much, Corey, for having me on. It was a lot of fun. I feel like we covered a lot of ground. Probably too much. It really was, and we did. Denise Yu, Senior Software Engineer at Jethub.

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 comment containing a correctly formatted git rebase command. If your AWS bill keeps rising and your blood pressure is doing the same, then you need the Duck Bill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duck Bill Group works for you, not AWS. We tailor recommendations to your business, and we get to the point.

Visit duckbillgroup.com to get started. This has been a humble pod production stay humble