 Hello, I'm Hilary, and I'm going to be talking about what I learned my first year as a full-time developer. So I'm a software developer at Ten Forward Consulting in Madison, Wisconsin, in the States. It's a very exciting state. I'm sure everyone is dying to go there. And I tweet a lot. I'm on Twitter. So about five years ago, I started my first programming internship. So I'd been programming as a kid, but literally no one told me that could be a job for a whole number of reasons that we don't have time to get into. So I didn't pursue it in my studies or as a career, but kind of fell into it through the work that I was doing in journalism and then realized I don't want to do the journalism. I just want to do the programming. And so switched careers, got into tech. Today I'm a co-owner of and the second most senior developer at the same company where I started as an intern, which is pretty exciting. So I just, a little gift for myself. So the idea with that is just, you know, this talk is kind of aimed at folks who are maybe feeling like, don't always feel like tech was the right decision for them or are kind of struggling early in their career. So this is just kind of illustrating that there is a light at the end of the tunnel if you are feeling like that. So okay, I've been doing it for five years, at least in the States, you know, where I am that feels kind of like I'm a middle-aged programmer. So why am I giving a talk about being an early career programmer? A couple of reasons. So it's based on a blog post that I wrote after my first year. So when I was all fresh in my mind, kind of what I was thinking at the time. And then I do a lot of mentoring, not only in the community with students who are learning programming and computer science, but also at my company. We have an internship program and apprenticeship program and we take on a lot of junior developers. So constantly being around people who are in that sort of early career mindset. So before we get started, I just want to kind of pull the room a little bit. Who here has ever thought everyone knows more than I do? It's pretty much everyone. This is just too hard, I will never get it. I should raise my hand for all of these two by the way. Everyone else seems to pick up things faster than I do. And then maybe getting a job in tech was a terrible idea. Yes, good, I've got the right crowd. So pretty much everyone raised their hand at least once, which is a good thing in the sense that you're very basic, which if people don't know that American slang, it just means you're kind of super typical, your average, right? I've resued in that I have mentored, and even myself when I was going through my coding bootcamp, everyone had those thoughts, right? It's super common to feel like you are the only one who is struggling, and who doesn't know what you're doing. So this talk is kind of like, how can we sort of change that mindset and reframe things so that we don't have at least as many days where we feel like being coming a programmer was a terrible idea. So we're going to look at four different primary topics, and then room for questions at the end too if people have any questions, or just want to do more of a group discussion because we're kind of a smaller crowd. So first, who here primarily does coding for their job? Pretty much everyone, cool, okay. So you're not the most important people in tech, right? We are not the most important people in tech. And I think especially in the states where you have this paradigm of Silicon Valley and the boy genius and work, I mean there's all of this cultural build up to this idea that programmers do everything and should get all the respect and all the money and all the accolades and everything. And that's just not true, right? This idea of that, I don't know if y'all use the phrase like rock star or like a ninja coder, like a 10X, yeah, I made that, it's pretty great. We talk about that a lot, right? And there's been a lot of backlash, especially in the states, about like moving against that idea, right? Of like, well, we just put up with John because he's such a good programmer. And they've actually done research. Harvard Business Review did a study of what they call superstar workers. And this wasn't just in tech, this was across all industries. And they found that they actually cost companies money, which a lot of us probably suspected, but now we have like the hard data to show it. And there's a number of reasons for that, one, they're overconfident. So they're a lot more likely to make mistakes and to not catch them. More likely to break the rules. And sometimes breaking rules is good, that's how we innovate, that's how we can improve, it's how we iterate, but some rules are there for a reason. And if you're constantly breaking them and not telling anyone and not having a reason for why you're breaking them, obviously that just leads to chaos. And sure, they might produce more lines of code, but it's not as good of code. And so in the end, it's just kind of a wash. And then the worst part, I think this is where in particular, they have that really, that strong causal negative effect on a workplace is that their behavior is infectious. So, people see them getting, not only getting away with these behaviors, but being praised for them, getting raises, getting promotions. So people think, well, that's what I need to do to get ahead, right? Especially, again, if we're talking about people who are just entering the industry, and maybe you don't know better. And so then everyone starts doing this. And so yeah, you've got tons of code, but it's all terrible. You're not getting anything done and everyone hates each other. And no one really wants to work that kind of environment. So if we know what we're not supposed to do, right? What they've shown actually harms the business and what are the things we should be doing. So not going rogue, right? Working together, collaborating with your teammates, talking things out, being really communicative. And then slow and steady. So, the expression, move fast and break things. Maybe we shouldn't break so much. Maybe we should move a little slower and have a better product. And then we're not iterating to, when we're iterating, we're not fixing explosions, we're just fixing small things. And then again, right? Collaborative, not competitive. So not trying to out-code everyone else or get things done faster or spending late nights getting there early to get it done first. And then everyone's trying to scramble to like reconfigure what they were doing to match what you just did. Working together so that everyone's on the same page and you're producing something together instead of competing with each other. So I love this quote, this is from that study from the Harvard Business Review. Converting a superstar worker to an average worker enhances performance to a much greater extent than replacing an average worker with a superstar worker. So, if you had a company that was 10, those rock star coders, knew a company that was 10, just like, yeah, they're fine. They perform about average. The average company would actually do way better in the long term. So part of the reason for this is because unless you're like working for yourself and the only person working on your product, no programmer is working by themselves. Sorry, no one is an island. There are tons of people that contribute to making good software, good websites, right? And some of these people are also programmers. But then again, it's all about how we work together, right? We can't just do everything ourselves and expect it to magically work. There are a lot of different roles that contribute to the work that we do that are just as vital to what we're doing because we can't do it without them. Or we definitely can't do it as well without them. And so kind of looking at this idea, one of the things that I think it's really important to focus on, especially earlier in your career, but also a lot of this is really good reminders for me now being like five years in that I should still be doing this, right? Because you're always finding opportunities to learn from people around you. And so the idea is like we had all of those different roles that are contributing to the work we're doing. And even though they're not necessarily programmers, there's so much that you can learn from those roles. So how do you learn where you are? The question is to think about like who writes the clearest documentation? Who leaves the best feedback? Who finds the most bugs during testing? You know, one of the... I think one of the best days that I had in the first year that I was a programmer was just sitting with our QA analyst for a day and watching how she went through the software. And that really changed how I did my own testing before pushing it up to QA but then even just how I thought about the code. Questions that I wasn't asking at the beginning that saved me a lot of time in the long run. Who can tell you more about who you're building the software for? Right? Again, that's going to inform decisions that we make as programmers. What about design? You know, why are we doing things a certain way? That might allow you actually building the software to see things that the designer didn't. And so that's kind of another idea, right, is... Especially if you're on a new project or you've maybe switched to a different framework or a different language or you got a new company. You know, you might feel like all you're doing is playing catch-up and you're not actually contributing anything. But there are a lot of ways that we can contribute to our companies apart from just writing code. So for example, doing some research. So we have a new junior developer at my company and we had her research a freight... You know, how it was the best way that we were going to integrate with government data for a project. And this wasn't just like giving the junior something to do so that we could ignore her for a few days, right? This was... It ended up being a really great decision because not only did she look at this with fresh eyes and pick one that had the energy to do all that research instead of just being, oh, well, this looks good enough, we'll just use that, right? She really wanted to find the best one. And then when it came to implementing it, you know, our seniors could kind of look at the specs and the documentation and really need a lot of time to get familiar with how it worked and be able to integrate it. Because she had done the research, she also could just like hit the ground running and start working with it instead of taking a few days to look at something someone else had picked so that she could understand how to work with it and how to use it. Pairing on code reviews. So this is one of my favorite things that we do is if you're a senior bring a junior on to look at your code and pair through it together in real time because they're gonna catch things that you hadn't thought of because, again, you know, that confidence, right? Which isn't a bad thing, but you sit there like, oh, well, you know, I know what I'm doing. This is a really simple story or, you know, what have you, like, it's fine, I just need someone to look it over. And then they ask questions that you wouldn't have thought of. Improving the test suite. So this is a huge one that, you know, not everybody likes writing tests. Tests are kind of important. And that's a good way for juniors not only to learn about the importance of writing tests but also become more familiar with the code base. Which can help later on. Adding to documentation is always a huge thing, right? That isn't directly coding related. And then assisting with QA because you can never have enough testing. Who here has heard the expression we are not our users? Couple people, okay. So I'm not actually a PHP developer. I don't know any PHP. I come from a Ruby and Rails background and this is something that this phrase really permeates the Ruby and Rails community. We are not our users. You hear it all the time. And it's basically the idea that the people who are using the products in the software we're building are probably not very similar to us. Of course, depending on what you're building, right? So quick exercise. Who here has a name with like a quote unquote non-standard character, like a hyphen, apostrophe, accent? Not that many people. Okay. You are all very lucky because it is very, very frustrating. One of my friends gives a talk about this idea that we're not like focused just on this idea that we're not our users. And she starts it by saying the internet hates the Irish. Because her last name is O'Neill. And this is the same thing that happens, right? And this might seem like, oh, it's not that big a deal. Just take the hyphen out. But this has caused some serious issues. And this is where these are just examples where they have, the form has actually told me what is wrong. There are so many times where the form just says something went wrong, it didn't work, and it doesn't tell me what it was. And when you're trying to like buy something online and you find out it was the hyphen, it wasn't you put your credit card in wrong, it just drives me like a wall. But I think the worst example was when I had this happen to buy a flight. They actually let me fill out the form correctly, but then when they saved the information, they stripped out the hyphen. You never know if they were placing it with a space or with a period, or maybe they just squished the two names together. And this was for an airline ticket. But then I went to check in, and I have pre-check, which is like the skip security certification thing in the States. And my pre-check name has my hyphen because that's my legal name, but it didn't match. And so I couldn't check in. And the airline wanted me to pay like a $200 name change fee because they said I had put my name in incorrect. I had to call someone. It was just like a hot mess. And it was really annoying when all they had to do was just accept my hyphen. Like this is not a hard thing, but I bet a lot of us don't think about it because if we don't have that character, we're not encountering these situations, right? So again, this idea like the people, all the people who are all of this software, we're writing it for themselves and not for me. And it's very frustrating. Who here is a woman? Hi friends. So lots of examples that we could give about this, right? Software that is built by people who are not thinking about us as their users. And it means that we literally can't use it, right? Like people who aren't white. Tons of examples. This is one from the States, which is particularly egregious, which is software, you know, facial recognition software that assumes that people of color are criminals. And this is not just like, oh, that's really embarrassing. They should change that. This is being used by police departments in the United States. Like this is very serious repercussions for people's lives. And all that it would have taken was thinking about who's gonna be the user, having a more diverse team, doing user testing with more diverse audiences, taking the time to think about the fact that the people writing this software were probably not the people who were gonna be most impacted by it. So that's really great and depressing, but what do we do about it, right? Like it's not that simple to just have a more diverse staff. So there are a lot of ways that we can think about this in our work in more individually centric ways. So diverse staff obviously is one. More diverse user testing, just doing user testing. So we, at Ten Forward, where I work, we build a lot of software for startups. And tons of them don't even have budgets for doing user testing. So there's so much of this that's just getting missed. We wrote an app for coaches, like personal trainers, and then the folks who utilize their services, like an exercise app, basically. You can track all of your data, do a ton of different things. And the colors that the client had picked out were not, did not match accessible standards for colorblindness. This is an app that primarily had, or more than half of the users were men, who are more prone to colorblindness. And if we hadn't caught that, there would have been a ton of people who just wouldn't have been able to use that app because they were using the colors for a lot of metrics and display that wasn't just aesthetic. And so things like that, right? And user testing would have caught that. Or it definitely would have given us a better chance of catching it. Cross-cultural checklist. So this is one that I love to use for forms. So you can download, I mean, there's a lot of free resources. So it's just a list of names from a bunch of different cultures and countries. And then you can just automate it to run through your forms and it'll hit if ever there's a name with a certain character that you're not accounting for that messes up your system. Device labs and virtual machines. Testing on, we did a project that was for, is a job matching site specifically for people who are or have been incarcerated and have a very different technical needs than the general population. So a lot of them are in sort of interim homes between prison and being out in the real world that tend to have much older computers, right? With older versions of an explorer and things like that. A lot of those folks are, we know from statistics, are much more likely to use a mobile device to look for a job. And so thinking about all of these, and luckily the client that we were working with was very aware of this, had done a lot of work in this area. So they came to us and said, these are the things that we need to think about. But if we hadn't had that knowledge, that sort of deep knowledge and that those expectations up front, this software that was meant to solve a very real problem in the States wouldn't have been usable by a lot of the people who needed it the most. And so we were able to ensure that it was usable through our device app, which has a bunch of older phones that we could test the website on, make sure everything worked properly. And then using virtual machines to use older versions of Internet Explorer and Windows and all that kind of thing. And then accessibility testing. So I mentioned the color blindness earlier. You know, there are just a lot of things that the average programmer doesn't encounter in their daily life. And so you don't think about it. But I think in the States, it's like one out of 10 people has some kind of disability. And so that's a lot of people. So just something that we need to think about and that's a lot easier to think about when you do it from the beginning, right? Rather than going and trying to retrofit an existing product. And then localization is the last one. So this is one, one of my current clients is an international company and the software we're building is used by international users. And so it has the most robust localization of any project that I've worked on. And I've learned a ton about localization through this. But even with this, those things that we didn't think about, like the way that numbers can affect nouns in different languages. And it's all really interesting, right? Like this isn't meant to be, oh, here's a whole other list of things that you have to do with all that free time you have, right? It's really interesting and it makes your product better and it makes the work that you're doing better and it makes sure that people can use it, which really is the whole point of what we're doing, right? So we want people to be using the code that we're writing. So kind of along those lines, right? Like it's very unlikely that you're going to be a PHP expert and a localization expert and really good at accessibility and you can recognize color blind, you know, color issues, right? That's just not a thing. You're never gonna know everything. And that's totally fine, right? If people do rubber ducking, is that a thing here? Couple head nods? Okay, I'll explain for folks that might not be familiar. It's the idea of just saying out loud what you're gonna do. And actually everyone in our office has a little rubber duck on their desk that are like little dinosaur rubber ducks. And you just talk to it, right? Say out loud what you're trying to do. You hear it out loud and suddenly there are things that make sense that you didn't think about because you're too in your own brain to see it when you just look at the code. So we're gonna talk about what are some of the ways that we can clear our heads. So reframing your feelings. When I was doing research for this talk, this is one that I think is really stuck with me that is so applicable in lots of areas of your life, not just with coding. And there's a psychotherapist, Dr. Lori Nadel, and she said that frustration isn't an emotion. Like we think about frustration the same way we think about anger or sadness or... But it's not an emotion. It's a distorted cognitive response to a presupposition that we are entitled to get what we want in a particular moment. So the idea that we are frustrated because we feel entitled to know something. And when I think about it like that, at least for me that's been super helpful because I would get frustrated a lot my first year. And just kind of taking a step back and thinking like, there is no reason I should know how to do this. I've never been taught or I haven't done it in four years or everything's different than the last time I did it or maybe I didn't get enough sleep last night. Like there's no reason that this should be easy, right? Programming is not easy. If programming were easy, we wouldn't have like a huge shortage of programmers. It's really hard and like that's okay. So we're not entitled to know things. So when I feel frustrated to try and sit and think, okay, why am I feeling this way? If there's no reason I should know this, like give yourself a break, right? Going for a walk. So studies have shown that even a short walk inside a building, you don't even have to be outside, we are more creative immediately after a short walk. So that can be a good way to just take a pause, take a walk, literally be more creative and come back to the problem. Switching to paper. So some studies have shown that we retain, we have a deeper understanding of things and we retain the knowledge better when we physically write it down rather than typing it onto a laptop. So I have a ton of post-its all over my desk and if I can't figure something out I just sit there and I write down, what am I trying to do? What have I already done? Like what isn't working? Cleaning your desk, right? Rearranging your desk. So just changing up your environment can cause us to think in different ways and see problems in different lights than we did before. And also if you have a very messy desk, which I do, cleaning your desk is a great way to get rid of all those distractions and then helping someone else. So this again we found that when we behave in altruistic ways it improves our mood, it makes us feel more valued and that allows us to kind of again come back to problems with a fresh perspective feeling better about ourselves which means we're gonna, those pathways in our brains are gonna work better because we're not just sitting there feeling angry and frustrating getting down on ourselves. But sometimes you just can't figure it out, right? You've tried all these things, you took a walk, you took a break, your desk is spotless, you still can't get it. And that's also fine. So going back again to the idea that no programmers and island, right? Like use those in-house experts to get the help that you need. But there are more and less productive ways to try and get help. So how do we ask for help? I tend forward, like I said, we have interns, apprentices, juniors, and there are times where I get really annoyed with them for the way that they ask for help. Because I feel like it's just wasting both of our time and it's not in a way that's actually enabling them to learn, which is the whole point of them being at the company. And so one of the other senior developers and I put together a blog post that's like literally how to ask for help. So what are the steps that you take? So the first step, what are you trying to do? So this is like, if you're posting in SOC or you come over and talk to us in person, first thing I wanna know is what are you trying to do? What is the problem you're trying to solve? What have you already tried, right? Because it doesn't do me any good to offer a solution just to have you go, no, I tried that, no, I tried that, no, I tried that. I'm like, whoa, what haven't you tried, right? So what are you trying to do? What have you already tried that didn't work? Is there anything you found when you were doing your research, looking at Stack Overflow, anything you saw that you think might work but you're not sure or you don't wanna break your computer or you don't wanna ruin your test data, so you're a little hesitant to give it a try but you thought, well, maybe this would work, right? Tell me what you think might work. And then how would you like me to help you? And I think this is the biggest one. Are you on deadline and you just need me to tell you what to do? Because I can do that. Do you have a few days? And so really, you just kinda wanna be pointed in the right direction, you know? Do you wanna pair on it? If so, put something in the calendar, let's make it happen. And this comes in to this idea of not wanting to just give people the answer unless, again, that's what they really need. But finding out how can we enable you to get to the solution that you want in the way that you want? And this has been really successful for us. And it's also great to have it written down because then when someone does just post in Slack, like, this isn't working. I can just post a link to the blog and be like, well, try again. It's not how we do it. And so this is a collaborative way for them to ask their questions and for me to provide help, but in the way that they want, which I think is really important because I've definitely been in the position of the more junior person and I ask for help and someone just gives me the answer and I'm like, well, now I still have more questions. Why does that work? Have you done that before? How do I implement this? And so then it's just not giving me what I actually need. So this framework has been really successful for us and then that's a link where you can find it online. So I think the kind of flip side of that is like, there will always be things that you don't know. Pretty much anywhere you work, there's gonna be someone who knows more than you. But that doesn't mean you aren't learning new things all the time. And I think it's really easy for everyone to forget that no matter what stage of your career you're in. And it's really helpful for, I find for not only your own sense of personal worth and value, but also the value you bring to the company to find ways to specifically track and celebrate the growth that you do have. So keeping a journal, right? Maybe it's something private just for you. Maybe you just have a word doc where you throw things in and when you're feeling bad or you feel like you can't figure something out, you have those doubts creeping in, just go check that out and see like, oh yeah, that's right. Like I didn't know how to do this and now I do. Or all of the things that you've learned because you always know more than you did the day before and it's easy to lose track of that over time. If you wanna do something a little more public, right? You can document things on a company or personal blog. So the 10 forward blog we have found through our analytics that actually are far and away our most popular blog posts are very simple, like how to do a thing. So I started writing some of these when I was a junior for the same reason, right? I wanted to remember that I was learning things even if it didn't feel like it a lot of the time. So we have like how to create a copy to clipboard button or how do you integrate an array column with simple form which is the gem that we use in Rails. Like very simple things, but things that a lot of people don't know how to do or that you don't do often and you forget, you don't have to memorize. And so even though those were things that I felt like everyone else knew how to do, it really wasn't the case because like I said, those are some of our most popular blog posts. Tutoring or mentoring is a great way to do this as well. A lot of times you don't realize how much you know until you're trying to explain it to someone else. And so that can be a really good confidence boost to help you make yourself aware of how far you have come since you first started. And then speaking of local meetup which I know speaking can be really scary for some people. But I recommend giving it a try, right? And especially if you're at a local user group tends to be friendlier, it's smaller. And again, that's a great way to share what you know and feel like you're contributing more to the community if that's something that you're interested in. The journal one in particular, going back to that for a second, is really helpful if you're asking for a raise or a promotion because you can just kind of reformat that and print it out and be like, here are all of the things that I learned and did in the last six months or year. And it's just an evidence journal of everything that you've done. I actually literally did that for my last raise. I just printed out that document and put it in front of my boss and got a promotion. And then the last one is about fitting in. And so for some folks this isn't going to be perhaps as relevant but maybe something to think about with coworkers who might be feeling some of this. So when I started at my company I was the only woman developer on the team. And the only other woman at the company was part-time office manager. And I was coming from a different career so I already had a lot of imposter syndrome and feelings like, again, should I even be in tech? Is this even what I want to do? And then being the only woman. And then also working with a lot of men who were more of the sort of stereotypical like one of my coworkers, and this is not a bad thing, but one of my coworkers literally does laundry, jumps the laundry basket from the dryer on the floor and just picks up a t-shirt until they're all gone. And then he washes them. Which works really great for him, right? But like, that's not how I operate. But that was the environment that I found myself in, right? And it's kind of natural that you wanna feel like you fit in, you wanna blend in. And so I realized one day that I had worn like eight t-shirts in a row to work. I only owned like 10 at the time. And it was just sort of this wake-up call like why am I doing this? Like this isn't how I like to dress. This isn't kind of how I wanna present myself. This is actually my office style. It's really cold here. So I didn't do it today, but like, yeah. And I didn't look like any of my coworkers, but that was fine, right? I was at a company that was really positive and inclusive and embraced that. And I think it's really important. You know, we talked earlier about how we are not our users, right? But there are ways that each of us can represent a different part of our users. So whether we grew up in poverty or we've lived in a bunch of different countries or maybe English is in our first language or we have a hyphen in our name, right? There are different things that we can all bring to help make our software better and more inclusive and easier for our users. And so our voices matter, right? Even if you are the lowest on the totem pole and you've just started at the company and literally everyone knows more than you, you still have things to offer. So you should use that voice, right? Here are some of the ways that you can do that. Office culture or environment. Is there anything that you see? And obviously this list really depends on the privilege that you have at your company and how comfortable you feel saying things and how you think that's gonna be perceived, but we're gonna get to that in a minute. Is there anything about the development process that could change, right? It's easier for companies, especially if they haven't had new people come on for a while or if you've been on a project for a long time to just do things the way we've always been doing them. But that's not necessarily the best way, right? Documentation is a huge one. When I joined my company, we had like nothing written down because everyone had been there forever and everyone just knew everything and they didn't need to write it down. And then I joined and had no idea what was going on. So we started doing a lot more documentation. Bonding activities. So we did what we called, are people familiar with Minecraft, the video game? Okay, some heads. So it's like a multiplayer, like you're all in the same universe and you basically build things. It's very fun. We would do Minecraft or Noons. So every Friday we will go for lunch as a company and the Friday afternoons, we would all just play Minecraft in the same world. And it was really fun. But that presuppose that you liked video games, right? And that's not even a gender thing, that's just, it's a very specific thing that we did every time. We really didn't have any other kind of bonding activity. It was just playing Minecraft. And so one of the things that I talked about, like why don't we do other things? Like kind of change it up a little bit. And I think that's been really useful. And you don't have to like every activity. You know, we did a craft night. We have a craft bar where you can get craft beer and craft cocktails and you literally craft things. And we had two people who went who just got beer and didn't make a craft because they don't like crafts and like, cool, that's great. You know, maybe the next one you're gonna like more. But really just changing it up so that you're not being homogenous in the things that you do. Workspace arrangement, you know, is there a way that you can change things up in the physical office that's more conducive for people? Or again, just changing it for the sake of changing it so that you kind of rethink those patterns and create new ones. And then company swag is a big one. So I was saying how there were only two women in my company when I first started and we order new shirts basically every year like on our anniversary. And the first year I was there, it was time to order new shirts. And so I was put in charge of finding like the women's shirts, which was good for me because I have a lot of opinions. And then we ordered like men's shirts. So basically fitted and then more straight cut. We got two different colors. We had blue and gray. We only ordered blue in the traditional men's cut. So I didn't get a blue shirt because no one thought about it. So like, oh, well, it's just Taylor and Sophia, you know, like they don't need yogurt with the gray. And it was like, that was really hurtful actually because I wanted a blue shirt. And the fact that I wasn't even asked just made me feel very other than like I wasn't a part of the company, right? Like I was an afterthought. So just things to think about, right? Like I spoke up and I said, this isn't cool. I don't like this. Like we should change this. And we did. And everybody felt really bad about it. They just hadn't thought about it. So kind of looking for these, again, if you feel comfortable and if you feel like it's not going to adversely affect your career, I really encourage you to think about all of these things and how could I find ways to improve what we're doing in our company? And then kind of a good way to do this is to make it easy to say yes. So this is something I think about a lot too. And it's related to that list of how to ask for help, right? If someone came up to me and said, this is what I'm trying to do. This is what I've tried. Here's what I need from you. Here's what I need it. There's really no way for me to not help them even if I wanted to, even if I'm super busy. Like they have made it really hard for me to find an excuse to not help, not that I wouldn't. So this has also served me really well at my company. It's like, okay, here's what I want to do. I've thought of the things that could go wrong. Here's how we can address those. Here are the benefits, you know like kind of over the top but making it really hard for my boss to say no when there's something that I want and that I care about. That being said, if you are still hearing no all the time for things that matter to you, there are options, right? Maybe you don't need to say where you are. Has anyone seen the TV show, The Good Place? Couple people, okay. So don't put up with bullshirt because it's not worth it. I liked it up. As of 2018, there were 600, an estimated 600,000 tech job vacancies just in the UK. And they predicted that was gonna go up to like 800,000 by 2020 right now. You can work remotely. A lot more companies are offering full-time remote so you don't even have to work for a company that's based here. I don't know, I guess I'm speaking more from a state's perspective where that's really common. I'm not sure how common that is here but I know that there are still companies that do that, right? Or work for a state's company that lifts you work remotely. And then this idea that every company is a tech company. So I'm sure there are lots of people even in this room who don't work at strictly tech companies, right? One of the biggest tech employers in Madison is actually an insurance company. And they call themselves a tech company but their primary product is insurance that they sell through software that tech people write. So don't feel like you have to be pigeonholed at just being at a tech company. And then for folks who do come from underrepresented groups or have other parts of their experience that are different, like you said, right? Like I'm a woman and there are a lot of companies that really want to hire women and so I will definitely use that to my advantage as long as it's a company that's actually doing it in good faith which is hard to tell sometimes. So yeah, basically if you're working at a company that's importing you, constantly says no or you just everyday feel like you're either not learning or you're not valued, like find another job because it's not worth it, right? The burnout talk this morning, it's just not worth it. Find something else. So yeah, just go out there and be yourself and do your best and you got this.