 My name is Mark Jay Lehmann, and today I'm going to be talking with you about growing into a, from a junior dev into a beautiful coding butterfly. Before we get started, I just want to say thank you to all the organizers and the volunteers who are helping to put this great event on, and I also want to thank all the sponsors in the room who are making this possible, and definitely thank all the fellow speakers who have just been killing it all day, today and yesterday. Yeah, I'm seriously really humbled by everyone, kind of wondering how the heck I got picked to speak alongside all these super talented people, but anyway, today we're going to talk about what it means to grow from a junior dev into something more and why it matters. Specifically, we're going to discuss what it means to be a junior developer and what distinguishes junior from everyone else, as well as how to best manage and supervise junior developers. Then we're going to pick six of the most effective activities one can engage in to make discernable progress both in one's skills and career, and we're going to talk about how managers and supervisors can help junior devs reach their goals and become more productive members of the team. And lastly, we'll touch on a few other methods for growth, and time permitting will discuss any ideas from all of you that we might have missed. So by the end of our discussion, hopefully we'll come up with some good ideas and answers for what can a junior developer do to grow into that beautiful coding butterfly, and how can their manager help that process along. A little bit about me, I've been doing some very basic coding for years, starting with my first website, I built in ninth grade. On a hosting service, some of you may remember called Tripod. Writing my own, yeah, there we go. Writing my own version of Dope Wars for my T82 graphing calculator, came next. Followed by a couple of AP computer science courses and my first paid gig as a webmaster. Anyone remember when that was an actual job you could have? I thought it was pretty cool sounding job that I'll have in high school, but maybe that's because I'm a nerd. Anyway, I didn't really get into coding as a career until several years ago when I left the world of residential real estate and enrolled in a code school in Portland, Oregon. And for those of you who have not been to Portland, yes, that is actually someone dressed in a kilt and a Darth Vader helmet and a Santa suit riding a unicycle playing bagpipes to shoot fire. There's a reason our unofficial city motto is keep Portland weird. Code school started in earnest but has so far been the most interesting, enjoyable and rewarding career I've had so far. I currently work at a really great company called Carista, building tools to help pathology labs, better manage their work and achieve more accurate results. So I'm not a household name in code circles. I don't maintain any large open source projects. And I haven't created any groundbreaking Shazam for Vood type apps. So if you're wondering why you should listen to anything I say, I really can't tell you more than this. I have put in a lot of legwork, talked to a lot of other developers and done a lot of research into this topic. So while I certainly don't claim to have all the answers, my hope is that you'll leave here today with a few more than you had when you arrived. That said, this topic does generate a lot of opinions. And while I believe I have some insight, maybe a little bit, and I'm sure the conference organizers hope I do as well. I don't really want to be talking at you for the next 45 minutes. So I'm gonna be asking for a little bit of audience participation from time to time. Don't be concerned, I'm not gonna be picking on anyone at random, probably. But I do hope you're all interested in participating in this research. I'm gonna be doing several real time polls during the presentation, trying something a little new. I did hand raises last time and I think this will be a little bit better, but we'll see how it goes. So you don't need to install any apps or anything, just visit the link. And keep the page open throughout the presentation to participate. Also, I got that sweet QR code, anybody remember when those were, that thing? So you can use that if you're feeling adventurous or nostalgic or lazy. To start, I want to get a sense of everyone's background and experience. How many years of full time coding experience do you have? Not necessarily employed full time, but coding on a regular basis full time. What's that? Yeah, there's another, I don't know if you can see that. It's not the friendly URL that I had on the other one. It's also bit.ly slash coding butterfly, coding dash butterfly. Nope, everybody good? Everybody get a chance? We've got about four more, so okay, I'm gonna keep going. How would you classify yourself? Yeah, sure, okay, everybody good? Pretty good mix. Do you work alongside, supervise, or manage junior devs? Or would you like to some day soon? Just pick which one you want to answer, I guess. Pretty good. If you identify as a junior developer, how much full time experience do you have? Now for that same group, for the last question, does anyone feel like sharing what they think needs a change for themselves before they start identifying more as like a mid-level or just stop feeling like they're a junior developer? Definitely, confidence, anybody else? Yeah, okay, higher value of the company and less time from your fellow developers. Cool, if it feels like I'm picking on like the self-identified junior developers, I apologize, but what I'm really trying to get at is where exactly this kind of really highly subjective line is between a junior developer and a mid-level developer, because it is highly subjective. So with that in mind, does anyone else feel like sharing when maybe they stopped feeling like they were a junior developer, if there was like a moment in time you can pick out, or maybe a big project you finished or something? Okay, so helping more than asking for help, definitely. Yes, okay, definitely, yeah, first senior title for sure. Yes, and folks around me start taking your advice. Cool, thank you all for sharing. I did a survey of friends and colleagues and other coders and a few different user groups that I take part in and I asked all these people some of those same questions. How many years of full-time coding experience do you have and how would you classify yourself? And here are the results of those questions. So there's a lot to look at here, I'll leave this up for a minute. I'm not exactly sure what direct conclusions we can draw from these two charts, but hopefully it'll help inform us a little bit as we discuss all this today. I became interested in this subject because when I changed careers into code a few years back and graduated from the code school I attended, I felt like it was a great thing for me and I've definitely had a lot of success since. But I also know at least one colleague from my graduating class that was still identifying himself as a junior developer on LinkedIn more than three years after that. And so it just got me wondering, why is that? What could this person and their managers or supervisors do to change that? And why does it matter? Now I'm gonna try to answer that last question first because this seems like the most important. It matters because like it or not, in the tech world, many companies still think in terms of junior, mid-level, and senior. And these titles often come with different responsibilities, tasks of different complexity, and certainly different pay scales. So I'd wager that anyone who enjoys coding would like to see progress in their careers and the amount of responsibility, their complexity of tasks that they take on, and certainly in how much they get paid. And anybody who manages coders will want to see these same progressions in each of their team members so that the team as a whole becomes more effective. So that leaves the questions of what can a junior developer do to grow into that beautiful coding butterfly and how can their manager help their process along? This brings me to the next couple of questions I asked in my survey. But before I show you the results, I wanted to hear some of your thoughts on them. What is the most beneficial thing a junior developer can do to level up? Or what is the most beneficial activity a manager or supervisor of a junior developer can do to help them level up? And I know that's two questions, but feel free to answer whichever one you want. Yeah, different tasks or different experiences? Yeah, I'd say the- Teach someone else for sure. Yeah, yeah, either one. Automate yourself, okay? But the junior's on board, that's a good plan, yeah. So I think that it's okay to make mistakes that you don't have to be perfect all the time. Otherwise, you can't innovate and people don't learn in that kind of work. Cool, yeah, two very good points. Pairing and developing the good culture where it's okay to fail. Yes, okay. And then two, open this on expectations. If they're very clear with you of what they expect out of you, then you're allowed to grow, you're allowed to make mistakes. Yeah, definitely, cool, lots of great, did I miss anybody? Yeah, definitely, yeah, cool, okay, lots of great ideas on the script. Thanks for raising hands. Here's what the survey respondents from my survey had to say. So I know there's a lot to take in here. Don't worry about studying this too carefully. We're gonna be seeing these charts a few more times today. But as you can see, there was some overlap, though also a disparity of opinion. And that's one of the things that makes this topic so challenging to condense into such a short talk. So today I'm gonna be primarily discussing kind of the shared opinions between the two. Speaking of challenging, overwhelmingly the most suggested thing for both answers was to challenge yourself. So we're gonna start with that. Seeking challenge, when was the last time you learned something big or important or really difficult? And how did you do it? Do you have a short story that they wanna share? It's okay if not, I have one. One of the times that I learned something really difficult was a little while ago when I needed to build two different versions of a feature, one behind authentication, and one without any authentication. Other than that big difference though, both versions should behave basically the same. So I could have built the whole thing in one app and then painstakingly copy pasted all the code into the second. And it would have worked, probably, hopefully maybe. Of course, I'd then have to take an extra long shower every time I looked at the code because I would feel so gross and dirty about that approach. Another option, the one suggested by my team lead and the one I ended up choosing was to build an Ember add-on. So Ember.js was the framework we were using. And add-ons are the note packages basically just your average external library. It seems like a pretty obvious choice to most of you I'm assuming and it was for sure. But it was a special challenging to me for a few reasons. Even after working in and around Ember.js for the better part of a year, I still didn't feel very confident in it. And we heard a little bit about confidence from a lot of you. The second one, I didn't even know where to start when talking about developing an external package and hooking it into two separate apps. And the third one, Ember.js itself and add-ons in particular, had stabilized a lot but at the time it still seemed like they were undergoing a lot of change with regard to best practices. So, nevertheless, after a lot of time I spent scouring docs online and asking questions and pairing, lots of pairing. Oops, there we go. And banging my head against the wall. I got everything wired up and working together and now I have a ton more confidence with Ember and add-ons. So moral of the story, always stretch yourself. Volunteer to tackle things you've never done before. And especially things that you have no idea how to do. It's really important for junior developers, but it's also pretty critical, I think, for developers anywhere on the experience spectrum. Actually, I think it's pretty good advice for making progress in any career. It's pretty easy to understand why this is such a great way to grow. Because when you don't know the first thing about a problem, every single step that you take to solve it, you're gonna learn something new. So, the next thing I'd like to talk about is code review. We heard from that, about that from, nope, same URL. It should, if you had it open already, it should automatically update. Okay, ready good? Bit.ly slash coding dash butterfly. Do you work in a place where everything gets merged to matter as code reviewed first? Okay, that's good, that's what I like to see. And have you worked somewhere that did not do any code review? What's that? I don't like so. I mean, you should be reviewing your code, as you write it. But besides the other category, code review was the second most popular answer for how junior developers can level up. And it was in the top five for what managers and supervisors can do to help. I think it's awesome that so many of you folks out there are already practicing regular code review. So sorry if some of what follows may seem a little bit like reaching to the choir, but hopefully there's still a few good takeaways for you. So, in my first job out of code school, I was working remotely with just one other dev, the project lead. Whenever I finished a feature and opened a pull request, he would merge it. And I would assume it was all good. And I thought I was just doing awesome. Like junior dev, first job out of code school, getting branch after branch merged. That is, until we started getting bug reports for just really simple exceptions that should have easily been caught during code review. And then I thought about it and it dawned on me that I had never gotten a single comment on any of my pull requests. So they probably were not being reviewed. Now, for me, this wasn't really shocking because it was my first professional dev job and I didn't really have anything to compare it to. However, after trading war stories with some of my code school buddies a couple months in, I realized just how unsettling this was and kind of started explicitly asking for code review. And by this time, the team had brought on another developer who happened to be a colleague of mine and since our lead still wasn't providing hardly any feedback, my colleague and I just agreed to review all of each other's code. So not the most ideal scenario, but and since we were at very similar experience levels, it was a little bit of a blind leading the blind situation. But in result was we usually didn't go off the cliff together, but found our way more frequently than we would have on our own. So just point is review your code and your team members code as much as you can with whoever's willing. So code review, it's one of those things that tech managers who don't actually code may not understand the value of or need for. But code review is hugely important both to the code base and to the growth and learning of the developers. As a junior developer, you should have at least one other more experienced developer working on the same project and in the same stack. Hopefully, I've certainly been in the opposite situation before. But and if code reviews, particularly on pull requests, don't come standard at your company, I'd encourage you to ask another dev on your project to review your code and offer to review theirs and probably need to get management's approval before you start spending the time. But even if you feel like you don't have enough experience to do a good job, most developers will definitely make mistakes and overlook simple things like syntax stuff and typos. Also tunnel vision is definitely a thing and can occur pretty easily when working deeply into a feature or bug or issue. I think all developers, myself included, can get so wrapped up in trying to solve a problem. Once we finally solve it, our brains are just totally fried and we don't do any more development or refactoring. So takeaway is it's always good to have an extra set of eyeballs and a mouth to go with those eyeballs to ask questions like, why did you do it this way or couldn't we try this instead maybe? Now, I don't want to leave out any more experience tips here. It can be a huge help for them to have to explain complicated parts of the code to someone who doesn't understand. I would suggest encouraging and probing some of the less experienced developers for questions about parts of the code that don't make sense to them because often those types of discussions can actually lead to refactoring ideas to make the code clearer and easier to parse. And hopefully a lot more maintainable in the long run. And managers and supervisors, if your team does not practice regular code review, I would definitely encourage you to implement that. I don't think there's anything else in this talk that will be a bigger win for your team's growth and your apps reliability and maintainability than good and thorough code review. Now you may consider doing some more training on more effective code reviews. There's a lot of resources out there on that. I'm not going to talk too much about it. There is a really great article on Medium, like I called Joel Kemp that I found. Or you can also just Google, something like code review best practices. And it will spit out pages and pages of answers. Next up, practice. I'm not sure I have anything to share on that topic that isn't covered by sort of general common sense and wisdom. If you practice something, you will get better. A few quick ideas for where to practice in case you need them. Game like apps, like rubycoans.com is great. What was that? Coding game, yep, codinggame.com also good times, nkey.com. I'm sure there's a lot more that I don't even know about. They keep cropping up every day. Open source projects, including just building things on your own, can also be really rewarding. And they allow for a little bit more free form learning, which is good. I know when I was starting, I had trouble thinking of what kind of projects to start with, so there is a great form on Reddit, r slash beginner projects that has a lot of good ideas for that kind of thing. All right, next up is take the lead. This also featured in the top five responses about what junior desks can do to level up and what the managers can do to help. When was the last time you took on a solo task or led a project? Was it within the last month? Within the last six months? How is that different from working on a project someone else is leading? Does anyone want to share experience or story? Yeah, definitely. Anybody else want to share? There's a mindset that I've come across a few times, mostly in less experienced developers, but sometimes in others too, where they think this code I've written is good enough, someone more senior or someone who knows the app better will fix it if it breaks. And I myself have lapsed into that mindset on occasion. It's definitely easy to do when you're on a team working within a large app where you may not really be familiar with all the pieces. It's important to realize that the reason for thinking this, I think, in my experience, is that there's some lack of understanding about how the app as a whole works and how all the pieces are interconnected. And understanding that can be a daunting task. And in fact, it's something that some devs just never quite get to, because some apps are just too big to know everything. And I think this happens more frequently when the developer isn't given, or doesn't take responsibility for responding to unplanned site outages or critical time-sensitive bugs. So they're not invested in whether their code truly works. And I think we can get rid of this mindset by making sure that we're taking full ownership of our code. One great way to do this is to take the lead on a project, either with other developers or solo. And when I say take the lead, what I mean is work out the architecture, break up the project into manageable pieces, track the progress of the project, ensure adequate test coverage for haphaz and sad-paths in edge cases. QA thoroughly, be a bad user and deliberately try and break your app. Deploy, or help with deploy, and after the project is finished, be responsible for fixing any bugs that arise caused by your code. Now I know that's a lot to handle, but taking your project from start to finish like this is both a hugely rewarding experience and often a humbling one, because there will definitely be errors. Tests will miss edge cases, dev time will far exceed estimates. Sometimes a whole project will have to just be tossed out the window halfway through because the architecture just isn't flexible enough. All those have certainly happened to me. But in the end, there will be something built that functions properly and fulfills some need. And there will be a developer who has probably learned a lot of tips and tricks and lessons to get it there. When I started my career in code, my first professional full-time job was on a very small team, so everyone was expected to take on solo tests. I learned a lot during this period. And then six months later, our lead developer quit, leaving me and one other developer of equal experience responsible for the whole app. So that's when my learning kind of really skyrocketed. Suddenly we had to take ownership of this entire app, making sure that we knew every single piece of how it was wired together, squashing urgent and critical bugs, resolving server and memory issues, being dependent on to diagnose and fix literally everything and anything that went wrong. At times it felt a little bit like this. Now, I may not have learned the best way to accomplish all these things, but because my fellow junior Dev and I had no safety net and nobody was available to help us, figuring this stuff out on my own made this period in my career where I grew the most. All right, next, ask for help. Ask. Three letters that make up a powerful tool for learning and growth. Ask questions, ask for help, ask to pair, even if it's from people working in other languages and frameworks. And before you ask any real people for help, ask your imaginary friend. I'm not joking. Who here has heard the term rubber duck debugging? Okay, many of you. Who has had success with that method? Yeah. It really works. In my experience, more than half the time. So, for those who don't know, the rubber duck debugging method gets its name from how it works. You set a little rubber duck on your desk, not quite that big, probably a little smaller, and you talk through your problem that you're trying to debug with your rubber duck. And in the process of explaining your code to your duck, you'll hopefully hit on the solution. Now, personally, I don't actually ask an imaginary friend or an inanimate object, but I do follow the underlying principle of the method. However, I call mine the Seeger method. Now, that's not to be confused with the lake great folk at Singer and social activist Pete Seeger, famous for such hits as if I had a hammer in the hammer song. Now, this is my Seeger method. When I spent about half an hour stuck to a problem, and when I say stuck, then I mean I've tried everything I could think of and everything that Google can think of to solve it. I start writing out my question. I try to be as detailed as possible in explaining the situation. What the end goal is, what things I've tried, what I've Googled to try to figure it out, what errors I've received, and what steps are needed to reproduce those errors. Now, usually in the process of writing all of that out, I realize something I've missed. And often that something I missed will actually be the key to my problem. Sometimes it's not. That's okay too. Every little bit helps. But at the end of that process I'll have a very clear description of the issue that I can easily use to ask someone for help. And when I do all this work before asking for help, the person helping is able to tell all the effort that I put forth to try to solve my own problem and be a lot more willing to help. I know I definitely am more willing to help when I can tell that. Just remember though, you do have to give as good as you get. So if someone asks you questions or asks for help or asks to pair, even if you don't want to or think you won't be able to help, at least give it the old college try. You'll be amazed at how much you can help out even if you're pairing in a language you're totally unfamiliar with. Sometimes just being the second set of eyeballs and asking clarifying questions can help get someone unstuck. I have another story but I'm running a little over so I'm going to skip this one. Before we move on, I want to bring up something about asking for help that a lot of people, myself included, struggle with. And that is at what point do you ask for help? Programmers more than many other people I have had experience with are a lot more likely to get stuck on a problem and remain stuck trying to figure it out all on their own. I think that's generally a good thing because frequently it's those types of problems that when you finally work them out on your own, the resolution sticks with you. I heard, I remember somebody mention that. You don't want to rob yourself of an opportunity to succeed at this really meaty challenge but at the same time there's obviously trade-offs between spending all day trying to solve a problem on your own or asking another developer for help and fixing it in like five minutes. Unfortunately there's no hard and fast answers I'm aware of about this. For me personally, if it's an architecture related question that could affect the whole project if it's been poorly at the outset, I often try to run my ideas by at least one other person before starting coding. However, if it's a situation like I just mentioned where I'm stuck on some problem, I'll ask myself these questions first before asking someone for help. Am I completely stalled and have not made any forward progress on the issue for at least 30 minutes and have I taken a short break away from the computer and then returned and still felt stuck? How many of you got stuck on something late in the day? Spent way too much time trying to figure it out, gave up, went to bed, and next morning just kind of figured it out immediately. Yeah, that's the reason for that second question. Excuse me, sorry, I'm still getting over a little cold. If I answer yes to both of those questions, it usually means it's time to start the Seeger method. Now before we move on in the spirit of this point, any questions? That's like a mildly amusing two-year-old pop culture reference to really liven things up. Okay, now get ready for some potential controversy or controversy. Para-program, who here believes para-programming is beneficial? Who believes it's a waste of time? Nobody, really? Okay, I usually get a couple people at least. Who isn't sure, anybody? Well, if you're in office, both people sitting at the same place working on the same problem together. Yeah, I would think of either of those as para-programming. Any time you're working... Yeah, I'm not necessarily talking about full time, like all the time. Yeah. In my conversations with Devs, it seems like there's no more polarizing topic than pairing, although that doesn't seem represented in this group, which is cool. But that is reflected in the, oops, that is reflected in the survey responses. Although pairing was near the top of the helpful activities, it was also near the top of the unhelpful activities. So granted those who said pairing was unhelpful frequently gave the caveat that they meant excessive pairing, which we just heard about, or pairing when there's an extreme mismatch of experience level. I've also heard from developers who believe pairing is helpful, but who hate doing it themselves because they feel like they learn a lot better on their own. And sometimes when pairing, you run into less than ideal situations like this. Anybody ever encountered a nostril whistler? For me, I don't really just subscribe to the extreme programming of every piece of code deployed to production should be written in pairs. But I have found that probably 90% of the pairing sessions I've done, I've learned at least one new trick, even if it's just an editor trick. And also in probably 90% of pairing sessions, one of us has caught a type of our syntax mistake, or an edge case that may not have been caught when soloing. So there's definitely best practices for pairing that make it a lot more worthwhile. Here are a few that I've come up with from asking that question from other developers across the experience spectrum. Have the less experienced person drive more often. On occasion, it can help to have the more experienced person type keyboard, but in those situations, make sure they explain clearly what they're doing and why. And the less experienced person needs to speak up when they don't understand. Work from only one computer and keep cell phones and tablets put away. This is both to keep distractions to a minimum and also to avoid situations where both people in the pair are looking at different solutions. The goal is, in my mind, is to talk through the problem and come up with a solution together. Now, this can definitely test the patience of either person in the pair. And when patient starts wearing thin, just switch up who's driving for a bit. I think this is a lot better than working on separate machines. Personally, I think it's one of the biggest benefits of pairing is seeing how other developers search for solutions and solve problems. Don't be afraid to ask a lot of clarifying questions. Like, why'd you do it that way? Or what's the advantage of this over that? Sometimes we all live in our own little code bubbles doing things in a particular way just because that's how we learned it. And so, asking these types of questions can lead to a better way. Discuss expectations up front, such as whether the pair wants to gain a deeper understanding of some piece of the app or just whether they just want to finish the task as quickly as possible. Now, pairing may not be for everybody, but in my experience, even those who find it to be a waste of time often get something out of it when they do it. So if you're in that group, I would encourage you to get pairing another shot and after the pairing session, write down a few of the things you learned. You might be surprised by what you write. All right, let's wrap up. We've talked in some detail about six great ways for developers to grow and their managers to help. Now, I would be remiss if I didn't point out that there are so many more. When I was developing this talk, one of the titles I almost used was 101 Ways to Grow as a Junior Dev. I thought at the time it was a facetious title and I was always also trying to be clever by saying 101 was binary for five. However, after talking with more and more developers, I actually don't think it would be impossible to come up with 101 different good ideas. So I want to touch briefly just a few more before we call it a day and I'm gonna kind of run through these quick. I've had a lot of great experience with working on well-maintained open source projects. Now, I almost didn't include this because I got so tired of hearing this advice when I first got started. But I mean, there's a reason why everyone spouts this line, it works. The growth for me has come from being able to jump and do a new code base and try to understand how it works and getting to review code by other people that I don't usually work with and have my code reviewed by them. And it's also great for practicing my get food and beefing up my Github strict read. Something I didn't touch on at all but that many survey respondents mentioned is networking. We've all heard about how great networking is. Like any other industry, building a personal professional network is a great way to advance your career. Meetups, hack nights, job fairs, conferences, all great ways to meet like-minded folks. If you don't work on a team or even if you're on a distributor or remote team, it's especially critical to find and immerse yourself in a good community to keep you motivated and have people available to help you when you succeed, when needed. Excuse me. My personal favorite type of networking has been volunteering at events because it provides a little bit more structure around networking besides just kind of, here's a swarm of people, go talk to them. I don't really do that well in those types of situations. This is from EmberConf this year. I got to be topster. Keeping notes of interesting things you've learned is something that wasn't mentioned much in the survey but that I personally have found very helpful. I maintain a blog, which unfortunately like many blogs is not updated very frequently. But I also have a nice long Gmail conversation with myself of about 100 messages with ideas for blog posts. I've also been on teams that have, today I learned Slack channels to get a few posts per week. On one of those teams, a lot of the posts were something snarky. Like, today I learned something else, terrible about Outlook for Mac. I'm glad you all liked that joke. I did this talk in Nashville, Tennessee where there is apparently a large Microsoft presence. And it didn't go over so well. And don't undervalue interpersonal or soft skills in your tech career. When I first started the path toward a career as a programmer, I was told pretty frequently that soft skills like the ability to communicate clearly and work well with people are in high demand in this industry. Now, I'm pretty grateful to say that I haven't had much negative experience in this regard in my tech job so far. But I have noticed a lack of people skills that many of the networking events that I've been to. And I'm very well aware of the importance of soft skills by hearing about the crazy stories that HR consultants help others handle. So I worked for a while at a fantastic company called Mammoth HR that offered HR consulting as a service. And one example I heard from one of our HR pros was this. And by the way, this is a real question received by a real client. So sorry in advance if you're offended. It's not too offensive, I don't think. All right, here's the question. We had an incident last Friday with two of our employees. A male employee walked into a female's office and asked if she had some lotion. When she gave him the lotion, according to the female, he dropped his pants and started applying the lotion. How should we handle this? I can't make this stuff up guys. So in this scenario, male employee could certainly improve his interpersonal skills among other things and how to appropriately interact with colleagues. Now clearly this is an extreme example but it's apparently very common for HR consultants to receive these types of questions. For many people it's difficult to realize they may be lacking in these types of interpersonal skills. So managers, I encourage you in particular to help point out soft skill areas where your devs can improve and resources to help with that improvement. And lastly, I wanna stress that if you're doing something that works for you, don't stop doing it just because we didn't talk about it today. So if you have thoughts that you wanna share about developer growth, we're kinda running out of time so I don't have time to kinda engage here. But please come talk to me after I love hearing about this stuff or find me online and shoot me a note. And I would also encourage you to continue these discussions with your programming colleagues or your tech team or even people you're meeting at conferences and networking. Before we go, I wanna circle back to one of the first questions I asked today. Why does a title junior developer matter? Seems to me the titles mean a lot less in the tech sector than they do in other industries. And in fact, seems to me they're almost arbitrary. A senior developer at one company could have skills and abilities on par with a junior developer at another. A colleague of mine suggested that the biggest reason it matters is that every organization will benefit greatly if they're able to develop their developers. And if a company defines a role as a junior developer, then odds are that that company is dedicated to helping that person in that role expand and evolve their skill set. And although we use the term junior developer many times over the course of today's discussion, it's also important to realize that a good developer, in my mind, junior, senior or otherwise is constantly learning and striving to improve. Hopefully the things we talked about in the last hour will help you regard this at your skill level. Thanks for coming, thanks for listening. Appreciate it. Thank you.