 This is Cam but she's going to introduce herself and today we're going to be talking about becoming a mid-level developer and our two perspectives on leveling up. So I'm Kinsey Ann Durham. I am based in Denver, Colorado. I love to fly fish and that's my dog Harley in the middle. I'm very obsessed with her. And then there's me teaching code in Peru, which is something I'm really passionate about. I also have a different background. I didn't go to a code school or have a computer science degree and I started to learn to code after I went to a Rails Bridge workshop. And I'm coming at it from the more junior perspective having recently made this transition or trying to make this transition thanks to Kim. And I'm Kim Barnes. I'm coming at it from the salty dog perspective. I've been doing this a while so sometimes I use words or tools that other people don't understand. I have to explain them and that's unfortunate and embarrassing. I have been doing this a while. I got introduced to programming from my dad who would assign me basic programming assignments that I had to do before I could play games on the Apple II Plus. So he also graded them. He said, okay, this one's this hard. So if you get an A you get to play this many games of space invaders or sneakers. I have some passions, including my two amazing kids who are both in college right now. I don't recommend that both your kids start college at the same time. It's not real convenient. I also love TDD and pairing and mentoring. And there's an early attempt at my coaching, trying to get this pony to pull my little sister. Didn't work very well. What's really cool right now for Kim to give us talk is that we're on the same team. And so we have the opportunity right now every day to work together and to mentor. So we both work for a company called Ghost Spot Check in Denver, Colorado. And we are always looking for engineers. So come talk to us more if you have any questions about that or want to relocate to Colorado. And we have a lot of t-shirts in general. Yeah. As Kinsey and I were planning this talk, we were trying to decide what words to use. Junior doesn't always apply to people, senior, mid. Who knows what mid is, it's kind of fuzzy. But I think we're going to use junior and mentor a lot. But what we found was that we think we have a lot of ideas that we can share and benefit you no matter what level you're at. So hopefully you can listen for things that maybe you've seen work for you or maybe some ideas that will help you with some problems you're having in mentoring in general. We're going to cover a couple different areas here. First, technical learning where we're going to talk about ways to level up your technical skills. Domain knowledge where we can talk about getting better at learning the why. You're writing the code you're writing. Mentoring, so helping people become better mentors. And then some more diving into the actual relationship between juniors and mentors themselves. And we want to talk about some ways that you can make mentoring work for you whether you're in a pairing or a soloing environment and balancing the two. And then finally dive into some soft skills to help everybody become better, well-rounded developers. So I think Kinsey's going to kick us off with some technical learning ideas. Yeah, and someone's still air dropping me pictures. I see you, I don't know who it is. But it keeps popping up on the computer. So thanks for that, I'm not going to open them on the screen though, I'm a little scared. So I definitely think that the best way to learn as far as technically goes is to teach. And a lot of people think that you need to be a senior developer to do that. And I really think that it's the opposite of that. Even if you've been programming for a month or two weeks, you can teach someone who has never programmed before. Teach your brother, teach your parents. And it really helps establish what you're doing and kind of what's happening because people ask a lot of really good questions. And it also helps combat imposter syndrome because you realize, hey, I actually have been learning. And I really do think that it helps solidify concepts in programming. Also, side projects. You need to be doing extra learning outside of your current job. So doing something like a breakable toy is something that's really awesome. Side code project contributing to open source. There are a lot of barriers to open source, but there's a lot of awesome people at this conference who are doing a lot to mitigate that. So contributing to open source, it also doesn't have to be code. You can volunteer for something like a RailsBridge workshop or get involved in the community. But make sure whatever you're doing, it's something that you're passionate about because already you're writing code all day every day and you want to make sure that you don't get burnt out. And speaking of burnout, I really think that it's important to take breaks. I don't know if any of you have heard of the Pomodoro technique, but I do that a lot when I'm soloing because it actually makes me get up and step away from the computer. So basically you're working for 20 minutes and then taking a five minute break, so on, so on. Also maintain your hobbies. A lot of times I hear people who are in boot camps and code schools who they used to be really into horseback riding or they used to be really into fly fishing. And then once they start doing code school or programming all of their hobbies, kind of stop being a thing. And I think that you should, as much as you can, make time for it. Even if it means like, hey, not finishing this project that you were supposed to finish. I think that it's really important because burnout can really blow up in your face and be a terrible thing. Also, languages you don't expect. I think it's important to learn other languages while you're learning even your first language, and I, Kim, will talk more about this. It'll help solidify core concepts. So one of these, for me, was SQL. This is an example of my first day at GoSpotCheck. I found this, and it was terrifying. Did it find you? It's like it came after you. Yeah, and I was really overwhelmed. Code schools aren't really teaching SQL. I don't really know a code school that is, but if there is one, I would love to know about it. And I think that SQL is a really important language and a skill to understand. So find a mentor that can help you with SQL, be playing around in the database. The only reason I started to talk to Kim is because she was a SQL expert. That actually isn't true, but- I am a SQL expert, but there's other reasons to talk to me, right? Right, Kinsie? Right, sure. Also, approaching problems. I really think that it's important to be aware of how you're approaching problems is not something you think about. You usually just sit down at the computer and do your job. But actually, having awareness around this, I think is super important. And I definitely think there are best practices as far as approaching problems goes. I'm sure you've all heard of breaking things down as small as possible. And working with Kim and other mentors has really, really helped me with that. And they're always constantly reminding me of it, which is what I need. Also, understanding the why and the bigger picture. Like, why am I doing this story? Like, what is the bigger impact? What are the customer needs? We do something called iterative planning meetings? Iterative? Iteration. Iteration, I always get that wrong. Iteration planning meetings where we can ask these questions and say, hey, why are we even doing this? And kind of understand the bigger picture. Also, when you're sitting down to write code, you can use techniques like pseudocode. Here's an example of where I was writing pseudocode before I wrote a line of code. So not only did this help me figure out what I needed to do and the code I needed to write, but it also helped me realize that this was a code smell because I have this assign user places method. And I have so many lines of pseudocode. I'm like, hey, this method's probably doing too much. So another benefit of pseudocode. Also, focus. We get distracted by dogs running around the office, social media phones. And a mentor, so like Kim was for me, can really be that bug in your ear to help keep you focused. Constantly, even when we were practicing for this talk, I think she took my phone away like three times or something like that. So if you have other things that are distracting you, take a break and go deal with them. Like say, hey, I need to take care of this. And Kim gave me that advice and that was really, really helpful. Because then I could actually be present when I was pairing. And it was a lot better for me in my pair. Also, focus on getting better. Set the intention. A lot of times, we don't really think about it in our day-to-day grind. But remind yourself every day that, hey, I want to level up. I want to get better. I want to be the best developer that I can be. And communicate this with your mentor and that way you can both work on it together and constantly have that annoying bug in your ear and keep that in mind. Also, time and practice. I've recently started mentoring myself for a online code school. And a lot of students I have who sign up are just expecting it to be really easy. They expect to know JavaScript backwards and forwards in two weeks. And I definitely think that you're gonna have to make some sacrifices and take the time to really learn and dig in. And I really don't believe that it is an innate talent. We hear that a lot. I think that it takes a lot of grit and determination. So, Sandy Metz gives a really great talk that I've seen a couple times on this. And basically she is saying that you need to be willing to put in a lot of hard work and effort. So go to the ditch every day and dig. So just keep going, putting one foot in front of the other and keep going. So now I know Kim wants to talk. I've been talking a lot and she has some good points on how to level up technically. Thank you, Kizzy. First of all, I love this tweet by Venkat Subramanyam who's one of my heroes. But the idea is that to kind of start the day with what do you want to learn. And actually it's one of ghost bot checks values is go to bed smarter. So I like that idea. Technical learning actually is an idea that my friend David Maduros introduced me to, the idea is that there's two axes, cool. Sorry, the clicker thing isn't working, I messed it up. Must be that airdrop photo. Yeah, the airdrop photo totally threw me off. So there's a horizontal axis which is different languages and technologies that you typically think of when you talk about technical learning. But then there's a vertical axis that here, I'll do that. Okay, you go. Okay, thank you. That's the core concepts that go across different languages. So this is a picture of the horizontal axis. And like I said, it's specific things like Ruby, Rails, JavaScript, React, Backbone, all those things that we are supposed to be proficient in. Who here gets excited about learning a new language? Well, probably everybody because we're here at RubyConf. So yeah, I think that's, I did too. I think that's a big thing that interested us in this career. This area is that there's so much to learn, and it is really important. We have to keep up with the latest languages and the latest features of the new languages or the old languages to stay relevant, to keep our resumes current. And there's jobs that say you need this many years experience in this language. So it's definitely very important, but there are so many, and there's only so much time. And so it seems like we spend a lot of time chasing the latest technologies. And our learning in each area can be kind of shallow. So I think it's important to remember to balance that with the vertical axis, which is the core concepts that go across all the different languages. These are the things like TDD refactoring, design patterns, maybe your IDE or specific tools, UNIX command line, design principles. These are the things that you can apply no matter what language you're working in. And these are the things that help you get jobs in languages you've never worked in before because you've proven yourself in a couple languages and you know the core concepts that work across all of them. And they also help you go beyond solving just simple problems with simple solutions. So you can really level up well if you work on these vertical axis areas. So yeah, I'm supposed to flip the card here. Like I said, the horizontal is important too. And balancing the two is pretty important. What's really cool is that they both build off each other. So the more languages you learn, like if you learn a new language, you already have a couple under your belt, you can apply those core concepts with that new language. You can learn the language better and quicker and you get to build on that concept. And the reverse is true too, as you learn, say, some new design pattern. You can try it across different languages and get so much better and understand it so much better. What I found is that if I'm pairing with somebody mentoring somebody or just pairing with somebody, I can find out kind of where they are on that vertical axis by what language they use. There's like a language of development. And I hear it when I hear people use the words coupling and cohesion correctly. Or discussing design trade-offs and not so much focus on the actual syntax of the language we're working in. So if I'm working with somebody and they're pushing me to think bigger picture, I know that they're growing in that vertical axis. So those are some ideas for technical learning. And we want to talk now about domain knowledge, which is getting better at the company you're working in, the application you're working in, the why you're writing the code and the problem space you're working in. One way to get better at this is to ask stupid questions. So who here is like me and hates asking stupid questions? I want to call on somebody to make them ask a stupid question right now. But- Great question. I have a problem too. I'll often raise my hand and say this might be a stupid question. But, for example, you're in an IPM or a grooming meeting and there's right off the bat they're like, well, we're going to talk about such and such. And you're like, I don't know what that means and maybe I'm the only one. But you have to ask those questions because you can't provide value. Developers provide value with more than just the code they write. They really need to understand the problem space, like I said. We're here to solve problems. So if you don't understand what we're talking about, you gotta go ask, you gotta understand it. And another example is like in a meeting they're talking about, we're going to add this feature to this screen. And you're like, well, what screen's this on? You can much better focus on better questions if you have more context. And you understand what they're talking about. The thing that I've found is pretty cool about asking these stupid questions is that once you do it, people start trusting you. They know that you're not going to hesitate to speak up if you don't understand and so they can relax and know you're going to do your job. And if they don't hear from you, they know that you're understanding and you're doing the best you can. So that's one way to get more knowledge or to grow your technical knowledge area. Kinsey has some more ideas for us. Yeah, so at Graspatchek we do something called field trips. So our customers are primarily big alcohol brands. So now instead of going to the zoo or anything, we get to go to the liquor stores for field trips. It's actually really awesome. So it's awesome because I get to put myself in the customer shoes. And I know a lot of companies aren't really doing that. As a developer, how often are you actually getting to interact with customers or put yourself in their shoes? So something like field trips where you actually use your app and do what they're doing I think is really awesome. Also they're really fun. Like I was saying, we get to go to bars and use the app. And also a bigger picture of understanding the why. And it's really helped as far as problem solving goes. After doing these, I feel like I approach writing code so much differently. Also I've been sitting in non-customer meetings and sales calls. And learning all about the customer as much as I can, their needs, why they're using our app. And which makes me much more aware of the bigger picture. And I'm not off in a silo in the corner with all the other developers just writing code all day, every day. So I think it's important to be proactive about this. Like I said, I know very few companies that do this proactively on their own, so you going out there and saying, hey, I actually want to interact with customers. Can I sit in on this demo? Can we do this field trip or something like that? I think it's really important. And that way you're always remembering the end user. It makes you more well-rounded as a developer. You can provide more value, more than just raw technical horsepower, which I think is really important. And better at solving the problems that you're dealing with as a developer. So now we're going to talk more about mentoring specifically and what we think makes a quality mentor. So my biggest piece of advice is just don't be an asshole. She tells me that all the time. Yeah, and really be aware of the word choices that you're using and even body language. It's important to always be encouraging and recognize your biases and also to not be kind of sending. It's really hard to do that, to not be kind of sending, because you know this thing backwards and forwards. It's hard to not be like, hey, how are you not getting this? So make sure that you're being aware of all that. And also watch your own frustration. It's been really interesting, because I was kind of judgmental of mentors who got really frustrated with me. And now that I'm in the other shoe of actually mentoring students through this code school, it's been interesting to see how easily frustrated I get. So definitely, I really think it's important to take a break. If you're getting frustrated, end the session early, or say, hey, I need to go to the bathroom, something like that. Because imagine how frustrated the student is. And it's really discouraging when your mentor that you're working with is frustrated with you. It's like, I don't want to recode anymore when that happens. Also, teach in metaphors. It's super helpful, especially with harder concepts. It's really helped me. So something that I was struggling with was this keyword in JavaScript. And the only reason that I was finally at the light bulb went off when I heard a metaphor for it with a soccer player and kicking the soccer ball. And all of a sudden, that light bulb went off. And it was only because someone taught me in that metaphor that I was able to understand it and apply it in real life. Also, think about the bigger picture. A lot of different jobs and companies, I feel like I was judged just because the raw technical skill wasn't always where it needed to be. But it's not just about that. Junior developers have a lot more to offer. And it's really important as you transition into becoming that mid-level developer that you're not just raw technical horsepower. You're the whole developer. And really honing in on these soft skills that Kim and I are going to talk about later. But always seeing what else they can bring to the table. Also, really be that balance of support and challenge. I think it's important to be a support system. Even if I have personal things going on in my life, I go to Kim. And also, she just really inspires me. And I think that's really important as a mentor to try and instill that in someone that you're mentoring. And push and challenge them. If they're slacking, if you think they're being lazy, push them, challenge them. That's something that I really needed. Also, remember that juniors can teach you things too. A lot of times we forget that. They're your peer. Don't treat them as a support in it, because they're not. They can make you a better developer. There's so much to learn as far as this industry goes. And they can also help you keep your code simple and readable. Because if they don't understand it, maybe you should look, hey, is this too complicated? Is this too clever? So yeah, Kim is really good about mentoring. So I'm excited to hear what you have to say about mentoring. Well, first thing I want to share to people being mentored or considering becoming a mentor is that it's not necessarily a senior developer. Does it necessarily make a good mentor? Even a great senior developer isn't necessarily a good teacher. It takes practice. It takes a lot of conscious thought about what you're doing. It's not just coding it at advanced level, letting somebody watch, because that's not teaching. And that's not fun for the person either. Another thing you can do to grow your mentor skills is to think about how the person you're working with thinks and explain in their terms. Like Kinsey said, metaphors work really well for her and worked for the JavaScript, this keyword. Other people, like, for example, I like concrete examples. You can teach me some, explain some abstract concept to me. But I need a concrete example to work through in my head as we're talking about it so I can, you know, make it a little bit more, learn it better. Solidify it. Solidify it, thank you. Also, as a mentor, know when to step in and when to let them struggle. I'll talk a little bit more about this in pairing versus soloing, but you wanna find the right balance between letting them struggle so that you're not too much of a safety net and they can learn those hard lessons. You need to see the error messages and then work them through to the actual solution so that you know what those error messages mean next time. But don't let them get too frustrated and don't let them go too far down the wrong path. So step in when you see them struggling too much. This is an idea of Teachable code that I read in an article Peter Jang wrote in Prague Pub. I really like this idea because I've heard that on teams with a lot of junior developers, there's this concept that you wanna teach the lowest common denominator level so that anyone at any time now or in the future can pick up this code and understand it because you don't want somebody coming in and writing this code that now the rest of the team can't maintain. But I don't think that writing in it at lowest level is really the way to go. I think that does a disservice to the developers and to the code. You wanna level them both up. But there's this idea of Teachable code and for example on the right you see my production example and maybe this is some code that someone you're working with doesn't understand. But you can break it down and create more of a Teachable example. You can extract temporary variables and give them meaningful names. You can inline methods to make it more procedural because sometimes that's easier to think of and then you can turn higher level methods like inject into the simple each. So that's a great teaching tool but also go the other way and then maybe you've written that code that way or maybe they've written that code that way but then you can take it to the next level and like I said level up the developer and the code so that it's more of the way you wanna see in a while and they're gonna see and have to maintain. So Kim, this has been super helpful of Kim doing this with me. So if you are a mentor in the audience I definitely, I highly suggest reading this article and practicing this because it's been super helpful for me on not understanding concepts and it's helped me really level up I guess. I hate that word too. Yeah so we're gonna talk now about some more specific ways that you can help work on the relationship between juniors and mentors or juniors and mentees. Something I find really useful is giving and asking for feedback. So I'll ask often, how is my coaching style working for you? Some people have told me that I'm too nice and I think that maybe I spend too much time worrying about how I say it or am I gonna hurt someone's feelings and that probably works for some people. I think that's probably the way that I wanna be taught because I'm very sensitive but Kinsey just wants it direct and blunt and so if I'm too nice to Kinsey I think it comes off as condescending because it's like, do you understand that? Did you understand what I said there? So ask how your coaching style is working for the person you're working with because everyone's different. Also give feedback and try to do it as quickly as you can but only if you can do it without emotion. As an example recently I had a one-on-one with someone and I told her that I told her some specific feedback on when we pair. Her navigating style wasn't working for me and I think she understood it but it was much better when we were working again in that pairing situation and I could say that right there. That's what I was talking about and then she could understand what I was referring to. Also as a mentor, be humble. You're still learning like Kinsey said and juniors, mentees, anyone has something to teach you. In fact it was my very first person I was mentoring who asked me what map meant in Ruby and I knew what it did but I didn't really know where the word came from and that's what she was asking. So don't quiz me. So. I'm gonna say what's map. So I had to look it up. I had to Google it and find out it comes from the mathematical term and that really helped me learn it too so that was pretty cool. Also when somebody asks you a question you don't know admit you don't know because first of all you're gonna help them with their imposter syndrome. Second, that's what we do. We don't know everything. We have to figure stuff out all the time and it's a great opportunity to model how you solve problems when you don't know them. So how many people here actually have a formal like mentorship or apprenticeship program at their company that they work for? Oh wow, there's a lot. Okay, so Kim and I we don't have a formal mentorship or apprenticeship program at GoSpotCheck so we really had to build this structure and priority into our relationship on our own which has been really great. So I think it's important to have dedicated time where you meet one on one which Kim and I do regularly and with one on ones to make sure that everyone's on the same page and that everyone's working towards the same goal and have that goal of leveling up. Also, make sure that you're in the right environment. So for, you know, this is a lot harder for juniors to find the right environment because you wanna make sure that learning is valued. Like Kim said, we had, you know, go to bed smarter clause or that's one of our values which I really appreciate. So if you're looking to really progress and become that middle-level developer I really think that's important. Also, don't tolerate bullshit. I know it's really hard with saturation in the market, you kind of wanna take any job you can at this point, at least that's how it is in Denver but I really think that it is important to find that learning environment and leave when you're unhappy and treated poorly because your happiness, you know, truly does matter and there are a lot of places that you can be happy at. And also, if you are in a situation where you can't really do anything about it, leave or say whatever, even if so, speak up about your needs, try to change it before you move on, help them see like, hey, I really want this, I need X, Y, and Z in order to transition into like a mid-level developer that way, you know, both the company and you win. So goals are super important, taking actionable steps like I said, since we don't have a formal mentorship program, it's so crucial for Kim and I to do this on our own and actually follow them, like be accountable for them and help each other and meet regularly with your mentor about those goals. And also define what a mid-level developer looks like at GoSpotChek, I'm sure, a mid-level developer looks very different than a different company. So I think it's really important to say, hey, what does a mid-level developer look like? What will my pay be, blah, blah, blah, and how do I get there? So now we're gonna dive into pairing versus soloing. How many people here pair on a regular basis? Wow, a lot, that's so awesome. And how many just solo most of the time? So half and half. It's kinda half and half. Yeah, that's awesome. So for me, the biggest thing with pairing was the confidence to drive more. So a lot of times when I was working with mentors or more senior developers on my team, they would never let me drive, but that wasn't necessarily their fault because I didn't have the confidence to speak up to drive more. I was super intimidated and I was not getting a lot out of pairing. There were probably months where I was not progressing as a developer because I was literally just sitting there watching someone write code all day. It sucked. So Kim has really pushed me to drive more. So even, it was really annoying. I was in the bathroom one time and she was under the stall like, hey, you need to drive more. So everywhere I went. I don't know what just happened. Someone's probably air dropping me more photos. Everywhere I went, she was constantly telling me, hey, you need to drive more. And I got so annoyed to the point where I finally started doing it, which was awesome. It helped me get a lot better a lot faster. And so I'm actually thankful for that. You didn't add a new slide about boundaries in here, did you? No. Okay, good. That's important too. Also the right amount of time. So it is really important to struggle. So I let Kim know as my mentor that I needed more time soloing. At Coast Batchek, we pair pretty much 100% of the time. Now I only pair probably 80% of the time because I really wanted that 20% time to be able to struggle and read blog posts and really learn about things that I was struggling with instead of having Kim step in and help. So this balance has really, really helped me progress quicker. Also, we've started doing these things called pairing retros. Those of you who are familiar with Pivotal Labs, they kind of coined this. All you do is have a retro on what went well, what didn't, and how to improve, and just on the pairing relationship. So that really helped me communicate like, hey, I wanna drive more, blah, blah, blah. And really get the most out of pairing and obviously accelerate my learning. And work on being a good pair, which is hard because I was constantly being distracted, so that was super helpful. Yeah, so Kim has a lot of experience with pairing too, also soloing, but mostly pairing. You're big into pair programming, so. Yeah, I like pairing. But Kinsey was talking about her needing some solo time and I think that works well for her. What, maybe a day a week or every other week or something like that. And I think everyone's different too. The people in our team who are happy pairing all the time, even though they are still learning as well. But what I found works really well with solo time is to combine it with code reviews. These can be a great safety net if you've got, you're trying to make sure that somebody's not pushing some big problem to prod. But more than that, it's a great opportunity to have the discussion. So, Kinsey might be off soloing and then submit a pull request and I'll pull her over so as to review it. I wanna discuss the trade-off she made. Why did you decide to go this way or versus that way? What are the pros and cons of each? But I have to remember I didn't have all the context. I wasn't sitting with her when her test failed or when her code got kinda cumbersome. So I need to ask questions about why she made these decisions. But the discussion is the important part. And also, if there are two equally valid ways, Kinsey's implemented one way, but I look at it, it's like, that's not the way I would have written it. But we've discussed the pros and cons and really there's no one right way or much better way. There's no reason I have to force her to change it to the way that I would have written it. Cause then you'd just be an asshole. Yeah. A right asshole. Yeah. Oh. Damn. Who here has tried ping-pong pairing? Cool, not too many. Ping-pong pairing is literally taking turns like ping-pong. Kinsey might write a failing spec and then give me control to implement it and get it green and then we'll take a pause to refactor and then I'll write her a failing spec and we'll go back and forth. What I really like about ping-pong pairing in particular with mentoring is not only does it help divide the time a little bit more evenly than driver navigator, like Kinsey said, she didn't progress, didn't get to touch the keyboard because they were probably using the driver navigator model. So it shares the time better, but it also keeps both her people much more engaged and on the same page. So if Kinsey's writing a failing spec and I'm like on the edge of my seat wondering what she's gonna write for me next. You know, what code am I gonna have to write? I'm much more engaged and there's much quicker feedback cycle if we're on separate pages. If she writes something that is totally unexpected to me or vice versa, then we have that conversation of well, I was thinking of this kind of design. You know, what were you thinking? So I think this works really well. Also the refactoring opportunities are a great time to model how you do that. You know, maybe stop her right before she's writing the failing spec and say well, do you see any refactoring opportunities or I'm gonna show her what I might do here. And again, great opportunity for conversation. Ping-pong pairing keeps you engaged and also there's other ways you can make sure your pair is engaged. When you're writing a failing spec, for example, often I'll stop Kinsey or whoever I'm working with and saying okay, what failure do we expect here? And I'll do this for myself too. It's kind of a good habit to get into. It's like I'm expecting it to fail because I got a three instead of a two but it turns out that I passed at the wrong number of parameters. That's really good to make sure that I'm thinking clearly because we often get into a habit, especially with TDD, of writing the failing spec, writing the passing code and then writing the failing spec and then much later you realize you actually weren't testing what you thought you were because you weren't reading the failures very well. And as far as driver navigator and helping grow someone in the navigator role, it's nice to ask what's next. You just finish a task or some part of a story to say where should we go next and to help them take that navigator role and think at a higher level. So we've talked about some technical learning, some relationships between junior mentors and I think we wanna dive now into some more soft skills to help make sure we're all well-rounded developers. One example that I wanna talk about is time management. As this tweet refers to, we are really bad at estimating. In fact, I think that's one of the big advantages of Agile over waterfall if anyone has heard of waterfall, I don't know, but it's not that Agile helps you estimate better, it's that it acknowledges that estimates are hard and kind of tries to remove them, make sure that we're working on the most important thing at any given time. One way you can get better at estimating and I think it's important to get better at estimating just for your own benefit, not necessarily that you should broadcast your estimate, but that so you can manage your own time better. And Kinsey mentioned the Pomodoro technique for helping with her soloing and for taking breaks, but also it can be used to estimate tasks. So you can write down all the tasks she used to do for a given story. You can write down how long you think each of them will take and then when you're done, you can go back and compare to how long they took. So this can help you identify patterns maybe in how you estimate or how you can improve, like you always forget that one part of the development cycle or there's always a surprise and you should just allow some extra time for that. Also as far as time management is important to avoid multitasking, but we can't always do that. We can't always control what we're working on. So what I found is if I'm working on something and a higher priority issue comes in and I have to pick it up, I wanna get what I was working on to a definition of done first kind of for myself before I put it down. And that's gonna be much better when I'm done with that high priority bug fix or whatever it is to go back to it. And finally on time management, there's a book, Go Spot Check's doing a quarterly book club right now on getting things done. It's got some great ways to manage a lot of different things coming at you both across work and home life. The final soft skill I wanna talk about is emotional intelligence, which is this huge, huge area and I'm not gonna talk for an hour on this. I just wanna talk briefly about the fact that as developers we can't be the stereotypical heads down, antisocial, introverts that people think us to be because especially with Agile, there's impairing, there's a lot more collaboration and communication required out of all of us. And in particular, empathy. I think empathy is important no matter who we're working with, a product owner, a QA developer, your pair, your mentee, your manager. And I think of empathy as just understanding where the other person's coming from. Not necessarily agreeing with them, but if you can have an open mind enough to understand where they're coming from, you might find that your opinions are a little bit challenged and you can work a lot better together. So we're from Denver, so I of course have to have my hippie-woo-woo slide in here. But I do think it's important to have a balance, importance of balance and mindfulness. I don't know if anyone meditates here, but I think that's awesome thing to do in order to cultivate that. Have work-life balance and another value at Gosbashak, have fun, stay sane, take care, which I really, really like. Also that self-awareness, know your strengths and weaknesses and communicate that to your mentor. Know how you work best with others. We had to take these personality surveys and understand how we work better with others and that was actually really helpful because some people would really piss me off and after I, really annoy me, and after I saw that I was able to have more empathy like Kim was talking about. Personality tests, you can take a bunch of them are another great way to see that and communicating that with not only your mentor, but everyone else on your team. Also knowing how you learn best. So there are obviously a lot of different ways to learn and experiment with that. So originally I was just reading a bunch of coding textbooks and that was not the way for me to learn. I realized that I needed to be hands-on and I was just wasting my time with those textbooks. So really know that. Also your attitude, having a growth mindset. So Kim really helped me with this. I would get super frustrated and be like, I don't wanna do this stuff so I'm not gonna write this JavaScript thing, like any stuff like that and she really helped me realize that I needed to be more optimistic about it and see these challenges as exciting and as a good thing. And that's the beauty of being a developer is we get to solve problems all day, every day and having a good attitude about it. Also networking. I really do think this is crucial for as far as leveling up goals. Find a mentor, as far as finding a mentor goes, finding a job. Also I've never submitted a resume for any of the jobs that I've gotten in tech and I really do think that's because of networking. Making myself known, going to a meetup on Twitter, stuff like that, it can really save you a lot of time as far as that goes and find the right people in order to help you grow as a developer. So we are finally at the end of our talk and we have a couple parting words of wisdom. I really like this quote and I guess I would say to juniors who are trying to level up, just keep going, really set that intention. Find the right mentor, be in the right place and I think it'll all fall into place from there. Cool and I like this tweet by somebody you might have heard of. I like the idea that it's more than just writing code. There's a lot more to it and what I wanna share in particular to juniors is to speak up and ask for what you need. Like Kinsey said, be aware of how you work and setting goals. Also find a mentor. If you're somebody in your company and your team is willing to mentor you, great. But if not, find somebody outside the job. That can be super useful too because you can go to them for maybe things you don't wanna talk to somebody about in the company and they can help you level up on a specific area. Maybe even help you work on a work problem that you got through and got shipped but now you wanna spend a little bit more time understanding it. And to seniors, I wanna say ask for feedback. It's super useful and powerful tool to ask for feedback. It opens those communication lines and you can find out how you can work better with that person. Also if you are in an environment that maybe doesn't pair but you're interested in pairing, you're interested in mentoring and you're more senior, somebody might ask you for help on a bug or a problem. Don't just go over and help them. Offer to pair with them on it or offer to pair with them for the day and see where that goes. And we just wanna say thanks to a couple people for helping us and giving us their advice. Yeah, and thank you all for taking time and coming here and gritting a shirt, we appreciate it. Thank you. Thank you. I just wanna say thank you.