The home team discusses React’s major version upgrade, how women in software engineering are often shunted into marketing or project management roles, and the brilliant analogy Cassidy used to explain to her parents how software engineers still have jobs after they’re done building the app.
React 18 is the latest major version of React. Cassidy also provides an excellent summary of React history.
Ceora is working on some CSS art (inspired by K-pop, natch) using CodePen.
Cassidy explains why Tanya Reilly’s talk-turned-blog-post Being Glue, which Ceora shouted out in Episode 425, was pivotal in shaping her career decisions.
Why do women in software engineering have to worry about being seen as “not technical enough”?
Today’s tech recs: Ceora recommends the Nintendo Switch™, Matt recommends Flexbox Froggy for people who want to learn CSS flexbox, and Cassidy recommends Loom.
Today’s Lifeboat badge goes to user JosefZ for their answer to Start Windows Terminal from the CLI and pass in an executable command to run.
Cassidy Williams The way I illustrated it was, imagine we were construction engineers of some kind, or civil engineers of some kind building a bridge. If we're all using our own ideas of standards and our own ideas of how something should be written, someone might be building the bridge with wood, someone might be using steel. Someone might be just throwing tar over it, someone might be using toothpicks. There's so many options for how this bridge is put together. And it'll work, someone will be able to drive across the bridge. But over time, well you might want to say, "You know, let's replace the toothpicks with some wood, and then over here we'll replace the wood with some steel, and kind of slowly but surely improve that."
[intro music plays]
Ben Popper As large organizations find themselves navigating their way around hybrid cloud, developers are being asked to shift their priorities as well as their mindset for this new world. For insight on new cloud architectures, deployment strategies, and the shifting culture landscape tune into Cisco's podcast, Cloud Unfiltered. Here comes the URL. It's cs.co/podcast.
Ceora Ford Welcome, everyone, to the Stack Overflow Podcast. I am one of your hosts today, my name is Ceora Ford. I'm going to let my co-hosts introduce themselves as well.
CW I'm Matt!
Matt Kiernander Oh no! I'm Matt Kiernander. I'm a Technical Advocate here at Stack Overflow and I'll hand it over to Cassidy to introduce her lovely self.
CW I'm Cassidy! I'm Head of Developer Experience and Education at Remote.
CF Well as always, I'm excited about getting to record this episode today. We have some fun topics to discuss. I'm going to pass it off to Cassidy to introduce a pretty fun thing that I think most of us probably have some experience with which is React. Why don't you let us know about React, Cassidy.
CW Yes. So React is officially hitting their release candidate for React 18, which is a big deal because React hasn't seen a really major version upgrade in a long time. And so for those who don't know the history of React and things, React first came out I think in 2013 or so, maybe early 2014. I started using it in 2014 and it has changed a lot since then. You might've seen the various iterations of React in kind of being the foundation for the virtual DOM and seeing how it's used in different frameworks nowadays, and a gigantic open source ecosystem that has come from React, and class-based components switching over to functional components and React hooks and everything. So many changes in the React ecosystem. And the last real major change was I think like three or four years ago now. Like 2018 or so when React hooks came out, and that changed everything. It made React kind of lean more towards the functional programming side of things, which we've talked about functional programming on this podcast before. And then React 17 came out last year in 2021, and the change was, “No changes needed, no updates needed.” Like that was just it. And people were kind of confused cause they were just like, "Why would I upgrade if there's nothing I need to do? It just is." And I think it was kind of a turning point for React where the changes that are happening under the hood are much more methodical and less about, "Let's move on to the next version. Let's make this faster. Let's make this better." And it's much more, "How can we make this framework much more robust for the next iteration of the next several years for people using the framework?" And so with React 18 coming out, they created the React 18 working group for people to give feedback on it. And I was in the React 18 working group and also gave feedback on React 17. And it was interesting talking to the React team because it was so different. It was like they changed their tune where they were just like, "Yeah, we were really excited to announce Suspense," and then they kept us in suspense for a few years, ha ha ha. But they announced it, and how Suspense worked changed so much over time. If you wanted to experiment with the new features that were in React that weren't actually released but just on a branch and stuff, it would be changed within a month, where they did a lot of research and development and experimenting with the framework to make sure that their ideas were sound and so that way it would work well in the future. And because Meta, Facebook/Meta owns the framework, a lot of their changes were being used in production on the Facebook website to see like, "Okay, can this handle it? Great. What if we change this? What if we change that?" So, it's been a very, very slow methodical race, journey, to get to this point of the React 18 release. And honestly, if you want to upgrade to React 18 from React 16 even, if you want to skip 17, you only have to change one line. It's just the root of your application is different. Everything else should work just fine. And I think because it has been so slow and because it's been so methodical, it feels like React has entered a different phase of where it was before. Where it's now like the big frameworks, like Django. It's now like the big frameworks or even languages like Python when Python switched from 2 to 3, granted that was a big change. It's something where you don't have to care as much about the fun little new features that might be added and you don't have to make a lot of breaking fixes to fix your application when you upgrade. It should just work. It's very backwards compatible and it adds features that should hopefully in theory, be very future-focused.
CF That's the kind of update that I like.
MK Can we just acknowledge the fantastic summary that Cassidy just gave over the last five minutes? Well done!
CW Thank you so much. I'm done. Let's end the podcast here.
CF I just have to say though, I love when things like this are updated and you don't have to basically change how you fundamentally understand whatever the thing is. You don't have to relearn anything about React essentially, or really change too much about your existing React applications. You can just kind of update and enjoy the little new quirky things that it does now, the new updates, without having to, like you said, introduce any breaking changes because you're trying to keep up with the times. I like that. That's the kind of stuff I like to hear.
CW It's very comforting as a developer when you're just like, "Okay, I can upgrade and it'll be fine." Because people who are upgrading from like React 15 to 16 when hooks were introduced, whew, that was a change. And there's still codebases today that I occasionally work with where I'm like, "Oh, I have to change so much to get even close to modern now." So the fact that you don't have to worry about that is a major relief.
CF Oh yeah, absolutely.
MK I remember being in teams where we actually had to fight to upgrade. I think we were on an older version of React and we had to kind of sit down with our product manager and be like, "Hey, we think hooks and everything else that's coming bundled as part of React 16 is going to provide value to us long-term. Can we have the dev time in order to actually go through and change things to make sure that we can upgrade?" So I love seeing updates like this where they're non-breaking and they increase the adoption and the likelihood that teams are going to upgrade and then get access to these new features. It's a lot easier. It makes my life easier, and I like that.
CW It's a real lesson in messaging, too. You can't just say, "We're working on it! It's a lot of research. Bye!" Because people will be afraid about these big changes that you have to make. So they had to be very, very careful with how they released new features, how they said, "Okay, we were thinking about releasing this but we're not, and here's why," and keeping people in the loop without making them nervous is a tough thing to do when you have literally millions of people working with your library.
CF Oh, absolutely, absolutely. I was thinking too, from the perspective of a developer advocate one of the things you have to look out for all the time is deprecation when you're creating any kind of educational content, because that means the blog post, the video, the course has to be updated which can be a pain. I've been on teams before where we were hesitant to make educational content just because of how often things can change. And when things change you have to update and that takes time, and sometimes by the time you finally update whatever the thing is, it changed again. So that's another added benefit of these small micro changes that improve the experience for the developer and improve performance for the application but don't necessarily change the fundamental bases of whatever the language or framework is. It's great for us, too, all around.
CW Content creators rejoice. I remember actually, I think it was when React 17 came out, they made it so that you don't have to import React in every file anymore, you can just import it at the top level and it'll just work. And that was literally right after Kent C. Dodds released his epic React course where he had that in every video. And I remember he was just so sad, and he was just like, "Are you kidding me? If I had known this was coming I could have changed my entire course." And he had put so many hours into it. And once again, it's a lesson in messaging and being able to be like, "This kind of stuff is coming. This isn't out yet." And it's tough because you don't want to give people false hope, you don't want people to worry. And it's dev advocacy.
CF Yeah! Whew. I'm having flashbacks.
MK One thing I'd absolutely love, I'm not sure if there's a solution that exists for this already. But I'm not sure how many times you'll have been working on CSS and you've made a nice CSS file, you put all the stuff in there. And then you're like, "Why is this not updating? My CSS is not there." And it's because you forgot to link the CSS file at the top of your page. If they could just do that but with the CSS files, I would be so happy.
CF That is one of the reasons why I default to CodePen whenever I'm creating a silly little like offhand thing.
CW A quick thing? Yeah, CodePen is amazing for that.
CF Honestly, yeah. Not to make everything about K-pop you guys.
CW It had to happen. Let's go.
CF I'm currently working on my first CSS art thing that I've done in a really long time. And it's supposed to be a replication of some K-pop poster. And I went straight to CodePen because I hate having to do all the boiler plate. I don't want to think about that. You all know that I'm a lazy developer, I just want to finish what I have to do and get it done, and CodePen is great for that. So whoever is in charge of maintaining CSS updates needs to get on that. Please, if you're listening. That would be very helpful.
CW And speaking of CodePen and projects founded by Chris Coyier, Chris Coyier is one of the founders of CodePen, but he also founded CSS-Tricks, which is a very, very popular blog article conglomerate site of things. Honestly, if you have done CSS you have probably looked at a CSS-Tricks article at some point. And they were just acquired by DigitalOcean which is very exciting.
CF This is awesome. I used to work for DigitalOcean. That was actually my first tech job. That was my first job in the tech industry.
MK Wow! Starting off strong.
CF I guess you could say that. I was a contractor there and they had acquired Alligator.io and another company that's similar, where they would create developer content. DigitalOcean had recently acquired both of those platforms and I was helping to update any of the deprecated content and bring it up to standard to DigitalOcean’s style guide and all that kind of stuff. It was a pretty cool first job. That was my first time having to work directly with JavaScript and React and TypeScript. And I didn't know what I was doing but somehow made it through.
CW But you did it!
CF Yeah. So this is cool. And I have Riverside open, but I have like a million tabs with CSS-Tricks tabs open right now as we speak. So, you're so right. CSS-Tricks is a lifesaver if you work with CSS at all.
CW It was kind of funny because one of the comments that I saw on the announcement was saying, "Okay, I'm okay with you being acquired, I'm happy for you. But just don't lose the Flexbox guide because I reference that every single time I do CSS. Please keep the Flexbox guide." They've confirmed the Flexbox guide is safe and it will still be there.
MK I don't know what it is and it seems like this is a universal thing across everyone's minds. Same with Regex as well, is that nobody seems to be able to retain information relating to how Flexbox or CSS grid works because I have to look it up every time. And Flexbox, I've got it pinned to my bookmark because I need to reference it every single time. It's ridiculous, but it's a fantastic guide.
CF You know what you have to do? You have to teach Flexbox. The only reason why I remember Flexbox is because I had to teach that to a bunch of like 13, 14, 15 year olds and since then I've remembered it. But CSS grid? I just can't absorb it.
CW That. Yeah, same. I have retained Flexbox because of talking about it and using it so much. CSS grid, Sarah Drasner had made a grid generator that does the CSS for you. If it weren't for that, I would just never use it because I cannot figure out a pattern. I'll share a link to it in the show notes. Her generator is a game changer if you ever want to use CSS grid.
CF Maybe that's what I need in my life because I never know what to do with CSS grid. I just don't know. I can't remember it, I can't remember when I'm supposed to use it. It's bad for me.
MK There seems to be quite a bit of debate around when to use CSS grid and when to use Flexbox. It seems like they're very interchangeable, but I'm not sure in what specific use case you choose one or the other. Cassidy, it looks like opinion time.
CW I always have opinions on things, I know. Long story short, if you're doing something that is meant to be 2D, you use grid, otherwise you use Flexbox. So if you have, for example, a linear list of things, let's just say you want your team members listed on the page. It might wrap so that way it is a grid of sorts, but typically it's just one list of things. But if you very purposely want something that should be a 2D grid where certain columns appear and disappear and the columns matter, that's when you use grid.
CF: Maybe I'll remember moving forward.
CW Yeah, because Flex is really good for individual directions, like either having Flex direction row or column, that's it. If you want to be able to use both in one thing, have rows and columns, that's when you use grid.
CF I think the one thing I remember reading, and correct me if I'm wrong, but I think I read something like the rule of thumb is for more smaller components in whatever your layout is you use Flexbox, and for the more bigger things you use grid. I don't know if I remember that correctly.
CW That might be a nice high-level rule of thumb guidance. I don't know.
MK I found CSS grid good for visualizing the actual layout of a page. That's been quite useful because you can kind of see where your divs are going to go and how things are going to scale and work around that. I found that especially with when you're creating the grid in your friend's– what was it called again?
CW The CSS grid generator.
MK Exactly. Yes, I found that super useful because then you could just plug in the overall structure of how your page looks and you're like, "Sweet. I want that one," and you can put that in. That was really useful.
CW I think CSS grid is much more strict than Flexbox as well, and things that it would just kind of shift something over a little bit on Flexbox and you could change it. Things that exact same thing that might shift Flexbox, might completely destroy your grid, and there's pros and cons to that. It's kind of like with TypeScript and JavaScript. With TypeScript, it's much more strict with types and it will yell at you if something is wrong. And JavaScript, it's like, "Yeah, you can try that. Why not?"
MK Speaking of types and texts in JavaScript, I have a little bit of news that I can share if you would care to hear it.
CF Ooh, yes, please do!
CW I'd love that.
MK So Microsoft has proposed Type Syntax for JavaScript.
CF When did this happen?
CW Like this past week.
CF Why am I missing out on all the developer news? Where am I supposed to be that I'm not?
CW That's why we're here. Don't worry. It's interesting to see these types. Now, I only read a high level little bit of it. It's not exactly like TypeScript from what I've seen. It's more like you can add type declarations and comments, and JavaScript can read those and be just like, "Ah, this is what should happen." So it's like type checking, but not necessarily generating like generics or strict typing that you can do with other languages.
MK It's an optional syntax to add types by the looks of it. So you can, exactly as Cassidy said, you can have for example, a comment, and within that comment block you say at param A is a number and that'll be above a function, and then that'll determine whether or not that variable there is of type number or text or string or whatever that might be.
CF Oh, cool.
CW I'm down for it. I definitely lean more towards the loosey goosey JavaScript. Like, let's just see what happens because it's fun to mess with those kinds of bugs. But by having it just be an optional thing that you can add to certain components or functions or things, I think that could be particularly useful where TypeScript and Flow and other languages can still innovate in this space, but it still adds some of those features to JavaScript. Because for example, once again, I like writing JavaScript but I still often have a TypeScript linter anyway, just so that way if I am accidentally parsing a string as an int or something, I can fix that quickly before running anything.
CF I think I've mentioned this probably several times on the podcast, but one of my major gripes with JavaScript is that it's too flexible, in my opinion. When I was learning it, that was one of my issues. I was like, "It feels like I can do anything, but sometimes when I do anything I still get errors. So what is going on?" So I think that probably could help fix my little beef with JavaScript, because that was what kind of made me interested in TypeScript is the fact that it's more constraining.
CW You got guardrails.
CF Yeah, you have guardrails so that kind of limits what you can do which isn't always the best thing, but when I was learning that's kind of what I wanted.
MK That's exactly one of my issues when I was learning JavaScript and working with older legacy codebases, or where you have smaller teams that have a lot more autonomy around how they build stuff. With that autonomy comes the flexibility to build things that maybe shouldn't have been built the way they should've been built. And it can get really confusing because I was in a situation where it was a small team, there was a high amount of turnover, people coming in and out of the team. It was an agency and so people were just coming in and putting their own flavor on this particular codebase, so I think that the biggest issue here is consistency, because you didn't know how things worked in terms of a logic perspective. And, oh my goodness, that was the most frustrating codebase because you just didn't know what to touch and how that was going to affect other bits. And getting anything done was a huge pain in the bum. I'm going to get down a real deep, personal rabbit hole here so I'm going to cut that one off. But consistency, I think, is probably the key here. JavaScript is great because it allows that flexibility, but with that flexibility comes I think a responsibility to be consistent.
CW I remember I was talking to my parents, actually. They were kind of confused about how software engineers have jobs when an app is done, basically. They were just like, "It doesn't make sense. If the app is done, what are you doing? What's the point?" Because, for example, I worked at Venmo back in the day. Venmo's functionality hasn't really changed since I worked there seven, eight years ago now. Oh my gosh, I'm so old. Anyway, it hasn't changed that much and yet they still have plenty of engineers and are hiring a ton to make this app work. And so they were like, "Why is this still a thing?" And the way I illustrated it was, imagine we were construction engineers of some kind or civil engineers of some kind building a bridge. If we're all using our own ideas of standards and our own ideas of how something should be written, someone might be building the bridge with wood, someone might be using steel. Someone might be just throwing tar over it, someone might be using toothpicks. There's so many options for how this bridge is put together. And it'll work, someone will be able to drive across the bridge. But over time, you might want to say, "You know, let's replace the toothpicks with some wood, and then over here we'll replace the wood with some steel and slowly but surely improve that.” And unfortunately, that's just kind of how a lot of software is. We probably could do better at the software engineering aspect of having those kinds of standards in place. And that's why things like TypeScript and really strict linters and those kinds of rules that enforce consistency are annoying, but good, because it keeps everybody on a team on the same page, and software written in a way where cars can still drive across the bridge and the software will still work. And unfortunately, that is very much in an ideal world and the work will rarely ever be done.
CF It's funny that you mention this because I was just thinking to myself, in general, I feel like in software we just don't really know what we're doing. And I mean that in a very general kind of way. We're all just kind of figuring things out from every level when it comes to interviewing, when it comes to figuring out architecture, figuring out how we want to use JavaScript in our application and all that kind of stuff. I think that kind of ties into what I wanted to talk about. Ever since I read this article I always think about it. It's called Being Glue, and it is an article that started out as a talk, and it basically describes what happens to some people in their careers. So like I said, software is not a new thing, but it does not have the same level of standardized regulation as some other industries have. So, every company is different. Everywhere you go they're going to have a different way of doing things. And so sometimes a situation that we find ourselves in, depending on what kind of company you work at, what's the size of your team, is that you'll be doing what she in her article refers to as 'glue work.' So basically what that is is, maybe you're a software engineer. Maybe you're like me, you're a developer advocate. Each of those roles have a certain task that you're supposed to be doing for your role. Build software. You advocate for developers. Glue work is the more managerial stuff that needs to be done and that is important, but doesn't directly tie to what your responsibilities are in whatever your role is. So that could be working on improving the onboarding process for people on your team. That could be working on getting projects on track and making sure that your teammates are unblocked and that they're able to collaborate with whoever they need to collaborate with. That could mean scheduling meetings and taking notes during those meetings and checking in with people to make sure that they're following up the way they should be. And this work isn't necessarily bad. It's actually very important, but sometimes it doesn't directly tie to whatever your tasks are. So what happens is sometimes, if you're a developer, because you're spending time doing this glue work, you don't really get the opportunity to code and build features and ship software and all that kind of stuff. So when performance time comes around, what happens with a lot of people is that, because they've been busy doing the glue work they miss out on the work they actually are supposed to be doing, and so they don't get promoted. And when they ask why, it's because, "Well, you've helped with onboarding. You've helped with collaboration. You help facilitate meetings and all that kind of good stuff. But how much code have you actually done?" Depending on what's your role that's going to be important. For me, it could be, "How many articles have you written? How many talks have you given?" It's different for each person. I came across this article at a very pivotal time in my career where I was in a position where I was doing a lot of glue work, and it's not necessarily bad. If you want to be a manager, if you want to be a project manager, then it's important for you to do that stuff and maybe start doing it before you have the title so that you can move into that kind of role. But for me, that was not my desire. My desire was to work on technical things and to get to do developer advocacy. And I found myself doing a lot of this in-between work, which I didn't want to do. So in the article, she kind of outlines what your options are if you want to stop doing that or if you want to continue doing that, what things you should keep in mind for each of those options. It's a big reality in our industry that when you do technical work you're viewed differently. So, if you're a software engineer, you're going to be viewed differently than if you're a project manager, even if you have a technical background as a project manager. That's just how it is. So you have to think about that when you're deciding whether you want to make that move. Is this something you truly want? Are you okay with doing that work? Are you okay with the, I hate to say it, but the stigma that comes with that work? That's the kind of thing that she talked about. A few months ago when I was reading that I was like, "You know, I've worked really hard to learn how to code. I've worked really hard to get the certifications that I have. Am I willing to give that up to essentially be a manager or a project manager which I don't really want to do?" I'm interested in hearing if you've ever confronted this issue before in your own career. If you ran into the issue and you figured out ways to fix it, if you didn't figure out ways to fix it. Any tips, things like that. I'm interested in hearing what your take is on that.
CW I've both leaned in and away from this type of work and that type of direction throughout my career, because I've kind of gone back and forth on if I want to do managerial type stuff or not. Because it is fun, but it is a very different job to figure out if that's the type of job that you want to do. I remember I was doing some kind of work like that many years ago and I was talking to a mentor of mine and she was just like, "Okay, if you want to go in this route, that's great, you can do it. But, if you want to stay an engineer and you want to keep being technical, you have to be as technical as possible to maintain credibility." And she was just like, "Especially because you're a woman. Especially because you are mixed." All of these different things, it's just going to be something where you have to face the reality that people are going to look at you differently anyway, and you have to be as technical as possible. And that kind of shook me up a bit, and I was just like, "Okay, I'll lean in more towards the engineering, the just doing my job stuff." And then I found myself at another job saying, "Oh, I revamped the peer review process so that we can give each other feedback better." And lo and behold I ended up in a management position, which once again I enjoyed, but I wanted to go back into technical stuff. And so it's one of those things where you really have to figure out what you want to do, because it will guide where you go.
CF Yeah. And it can change the whole trajectory of your career. I've been in situations where I was being pushed more into the marketing side of things, social media marketing, PR, email marketing, and I was just like, "This is not what I want." I would like to be doing more, not even necessarily purely engineering because that's not what I do now, but more of the technical kind of stuff. That's what I wanted. That's what I had learned. That's what I wanted to keep pursuing. And in the article, she mentioned that this is a problem that a lot of women run into as well. A lot of us tend to be good at communication– I don't want to say that because I don't know if that's necessarily true.
CW Society has conditioned us to be particularly good at communication and that type of work.
CF Right. The issue for a lot of people outside of software is that they get pushed into secretarial work for a lot of women. And for us, that version of that is being pushed into doing project management. Now, is project management or even secretarial work a bad thing? No, it's totally not. If that's something you want to do, beautiful, go for it. But that's not always the case. For a lot of people that isn't the direction you want to go in. So you have to stop yourself and put your foot down a little bit and talk with people on your team who work with you and let them know that that's not the direction you want to go in. And sometimes the results can vary, they can vary. Sometimes you have to end up moving to a different company, moving to a different team, whatever the case may be. But it's important to have a level of self-awareness when you're moving through your career to really know if this is what you actually want to do to avoid one day waking up and you're like, "Wait a second. I wanted to be an engineer. I wanted to be a developer advocate. I wanted to be a cyber security engineer, and now I'm doing something completely different that has nothing to do with that and I have to find my way back to where I started." So I really think, especially if you work for a small startup, it's really easy to get into.
CW You wear a lot of hats in startups.
CF Yeah, I think it's a good article to read. I'm glad that I read it so early on in my career because I don't know where I would be right now if I didn't. It's super, super helpful. So yeah, I just wanted to bring that up because I think that's a good thing to think about when you're navigating a career in the software world.
MK I haven't read this yet but I'm really excited to, because I think this is the first time I've heard about this and my mind is just going, [explosion noise] remembering my previous history. Because from what I understand of what you two have said, some of this work I feel is valuable to do at some stage in your career because you'll gain skills there which will benefit you longer term and understanding what an underperforming team has looked like so you can be a performing team later on. You kind of know what is wrong in order to later on identify those signals as to how a high-performing team operates. Things like the peer review process or improving the onboarding documentation because you've just went through that and you're like, "Nobody should have to go through that experience again." I think it's valuable to do, but a hundred percent, it seems like the name of the game here is stagnation in terms of your career. You can either get stuck doing all of these minutiae things that don't add to your performance and you don't have anything to talk about in your next role to be like, " I achieved this, this, and this."
CF Yeah, absolutely. And it's about finding a balance with it. You have to do some of it. Some of that work just comes with being a part of a team, especially if you're on a smaller team. But you have to find balance and learn how to say no so that you're not stuck doing all of it, or all of that work is taking up a hundred percent of your time.
CW It's kind of like that phrase, “Dress for the job that you want, not for the one that you have.” Do the tasks for the job that you want and the ones that you have to. But still it matters. It's not just in companies, too. I know someone where she was on the core team for this very large library that is popular and they had a community issue and people started turning to her and saying, "Hey, will you help us with this?" And she was like, "I'm a technical core team member. There are community members who are willing to do the community work. I don't want to do the community work because I don't want to be pigeonholed into it." And it ended up being a whole thing because they didn't understand why she didn't want to do it. But meanwhile, the men on her team weren't stepping up and doing it either and it was a whole thing. But you have to be able to stand up for yourself and say that so that you, like you say, aren't pigeonholed into it. And there's degrees of this, you do want to be a team player, and especially if it's a small company you want to make sure they succeed, yada, yada, yada. But if you're going to be doing this kind of work, you should be acknowledged for it so that it doesn't hinder any promotions, raises, or future performance.
MK If the company sees value in that as well and they can recognize that you have added contributions to onboarding, peer review processes, all that kind of stuff. I think that's okay. One of the things I will add on top of this as well, is that if you're a male engineer out there and you're on a team and you notice that one of the female engineers is the one responsible for doing all the meetings and admin work, be cognizant of that and be mindful of that, and maybe take responsibility for sharing that load.
CF I think for any member of the team, if you notice anyone in your team who doesn't have the title, you should just be like, "Hey, maybe you should learn to say no." It just happens to be that a lot of women tend to fall into that, but obviously it's possible for anyone, or anyone of any gender identity at that to fall into that habit.
CW It's the kind of thing where if you see someone consistently doing that and it's not their job, you can volunteer to do it for one meeting and say like, "Hey, I'll take on the notes for the meeting this time." Something like that. It's so simple, but it passes the responsibility a little bit. Or even just, if you did it the last time and they kept doing it, you could be just like, "Hey Matt, will you take notes for this meeting this time?" It sets an expectation that it shouldn't all just be on one person.
[music plays]
CF Okay, so we're coming to an end of our episode. We're going to end it off like we always do now, with our tech recs. I'll kick it off by saying my recommendation this time around is the Nintendo Switch. I finally got one over the weekend, and I'm really bad at video games. I've been playing Legend of Zelda: Breath of the Wild.
MK Yes! 10 out of 10.
CW So good. So good..
CF I mean, it's good, and I'm having fun while I'm losing all the time. So that's how you know it's a good game. If you can have a good time while you're losing then it's great. So that's my tech rec. I've been having a good time being a really bad gamer and it's been a lot of fun for me. So I'll pass it on to everyone else here too if you have any recommendations for our listeners.
MK I have a recommendation. It's nowhere near as cool as the Switch, unfortunately, but it is incredibly useful and it's Flexbox Froggy. Does anybody know Flexbox Froggy?
CF Yeah! Absolutely!
MK Okay. This is what I used to learn Flexbox. It's basically a maybe 15 to 20 minute game which teaches you how to move a frog in certain positions across the screen and get it populating within a grid system. It's an incredibly fun little way to refresh your memory when it comes to Flexbox, and it's something I've used in the past to great effect. So Flexbox Froggy, thank you for existing. We'll have the link in the description.
CW A tool that I've been using more and more and that I'd like to recommend is Loom. It's a video company, I think it's just loom.com. And what's cool about Loom is it allows you to just quickly record a video. And it could be just of your face, it could be of your screen, it could be of both. But it quickly records the video, as soon as you hit stop it uploads it, and you can share the link with people to share that video. And at Remote, what's been nice is because we have such a low meeting culture and it's a very async culture because some people I work with are in Japan who are in very different time zones, or Europe, Hawaii, all over the place. And so instead of having a meeting where everybody can sync up, people often record Looms where they quickly say, "Hey, here's the update on this. Here's what we have to do. I'll explain through this." And it's a great way to just kind of get your words out without having to write a doc. I've used it personally too, where I talk about a Go game that I just played. I'm like, "Look how wild this move was. This is what happened here." And it's been very, very useful.
CF Awesome. Yeah, we use that in my company as well. It's a huge facilitator for communication and stuff like that, especially async. So we're finally going to come to an official close of the episode with a lifeboat. So for those of you who don't know, a lifeboat is an answer score of 20 or more to a question score of -3 or less that goes on to receive a score of 3 or more. It's a badge that can be awarded multiple times, and today, we're going to shout out JosefZ. His lifeboat was awarded for "Start Windows terminal from the CLI and pass in an executable command to run." So like I said, my name is Ceora Ford. I'm a Developer Advocate at ApolloGraphQL. You can find me on Twitter. My username there is @Ceeoreo_.
CW My name is Cassidy Williams, I'm Head of Developer Experience and Education at Remote. You can find me @Cassidoo on most things.
MK And I'm Matt Kiernander. I'm a Technical Advocate here at Stack Overflow. You can find me online in many of the places @MattKander.
CF Awesome. Thank you all so much for listening. See you soon.
All Bye!
[outro music plays]