 I'm Rachel, that's my Twitter and my email. And so, like Luke was saying in my past life, I taught elementary school and middle school for seven years. And now I teach software development at the Turing School of Software and Design in Colorado. And so over the course of seven months, we turn people into developers and then we release them out into the wild world of programming. And so we hear all sorts of stories about the great things that they encounter as junior developers and problems that they run into when trying to integrate as a junior developer. So I thought that today I would talk to all of you about the common pitfalls of junior developers. But then I decided that making people aware of the common pitfalls wasn't really gonna change anything. So instead, we're gonna talk about how software development teams and mentors can prevent these problems in the first place. But preventing these problems can be difficult because being an expert doesn't necessarily make someone a good teacher or a good mentor. An experienced developer may be able to write very clean and performant code, but they may not be armed with the strategies to best help junior developers. And it can also be difficult for an experienced developer to remember the pain points that they went through as a junior developer. So I decided to talk to some junior developers, some senior developers and some people in between, and figure out what was successful and what wasn't. And in the process, I saw three key points that were echoed. So my hope today is that you'll not just start thinking about these problems, but you'll be able to take away some strategies that you can start applying in order to best support junior developers. So one of the frustrations that was voiced was lack of structure. Many places say that they have the capacity to take on a junior developer, but what does that really mean? A lack of structure can be overwhelming and turning a junior developer loose on a random tracker story is not only stressful to them, but it's ultimately less productive. So what structures can we put into place to increase productivity and decrease stress? So the first thing I recommend is creating a long-term plan. This involves answering questions like, what are the minimal essential skills that this developer needs to know right now in order to become a productive member of our team? What or should he or she be able to do by next week, by next month, and next year? And how are we going to get there? So having a long-term plan provides a roadmap for both the company and the junior developer. The next thing I recommend is create a structure for pairing. How often will the junior developer pair at our company? With whom will they pair? Pairing a junior with a junior can be beneficial because juniors tend to have similar thought processes, similar skill levels, but they'll most likely bring different skill sets to the table. So if specific stories in your project management tool are tagged as being junior level, meaning that there are problems that are going to be challenging but not out of reach, it's almost guaranteed that a junior-junior pair will provide a productive learning experience. But at the same time, we don't want our junior developers to be stuck indefinitely with these easiest stories. So build in time for juniors to pair with seniors in order to be exposed to different ways of thinking that will allow the junior to grow. And remember that ultimately in a junior-senior pair, the measure of a successful pair is not how much work gets done, but how much the junior developer learns. And finally, create a structure for consistent feedback. For example, code reviews. When will they happen? Who will be reviewing them? How often? And it goes both ways. Make sure that the junior is also reviewing pull requests from more experienced developers. One-on-ones are also an easy way to provide feedback to the developer and also solicit feedback from the developer, both on a career level and a personal level. So a well-thought-out structure makes it easy for a junior developer to drop into the system and start thriving. This is a problem that we hear a lot about. And it's natural for one to be, want to be really, really good at something. Often junior developers come into an environment where their coworkers are people who have been programming for five, 10, 15 years, and so the junior developer realizes how much he or she doesn't know. And so it's easy to start thinking, I don't belong here, I'm a fraud, or if I can't figure this out, they're gonna think I'm incapable. And that's the kind of mindset that causes a junior developer to go down rabbit holes, searching for an answer when they could easily turn to the person next to them and just ask. So we need to create an environment where a junior feels comfortable asking questions and exposing gaps in their knowledge. So how do we do this? When you're bringing on a junior developer, one of the first things that you must do is let them know that if they have a question or if they're struggling, it's fine and even expected to ask another developer for help. And then the follow-through on this is just important. Be patient when those questions are asked. Be willing to really listen and show that their questions are valuable. Make sure to set and share realistic expectations. It seems pretty logical that a junior developer is not gonna have near the productivity level as a senior developer, but it's not gonna be as obvious to the junior developer when the people that they're surrounded by are moving at twice the speed that they are. So be upfront with new hires. Tell them, we don't expect you to complete this giant feature in two, three days. And finally, allow junior developers to see other developers struggle. One of the junior developers that I talked to in preparing for this talk said that one of the most relieving things was watching a senior developer struggle with a problem that they had just been having. And it made him realize that it wasn't a problem with his abilities or his intellect. It was that programming is hard. And so be open with junior developers. Make it clear that nobody has all the answers. And finally, I think the last problem that I heard kind of commonly was having a surface-level understanding. And one misconception that I see among people learning how to code is that it's just about memorizing implementation, which it's not. I just wanna be clear. So without true understanding, it's very difficult to distinguish between bad code and mediocre code and good code and really good code because you have nothing to base that on. And so only having a surface-level understanding can result in big problems when you're trying to debug something or when you're trying to implement a feature that's maybe slightly different than the norm because those memorized patterns aren't gonna work anymore. Ultimately, we want junior developers over time to expand their knowledge and to have a deep understanding of how and why something works. So how do we do this? When working with a junior developer, use proven teaching techniques. One of my favorites is creating visual representation. So whether that means whiteboarding or drawing diagrams, it forces a mind to process information in a different way. You're connecting the abstract with the concrete. Using analogies is another one of my favorite teaching techniques. For example, how can you relate mapping over an array to taking individual Polaroid pictures of people in a line? Or how is an ORM like a translator between two people speaking different languages? So both visualizations and analogies bridge that gap between abstract code and situations that a junior developer is already familiar with. And finally, one of the most effective ways to deepen understanding is to provide junior developers with opportunities to work on projects that build on or reinforce concepts that they've already seen. So assigning projects with slight differences provide practice opportunities, but they do it in a way where the developer is forced to consider how those differences impact the way they choose to implement it. So I have a challenge for you during this afternoon's tea time, which sounds very fancy. I want you to find someone to talk to. And I want you to share mentoring strategies. How does your company currently support junior developers? If you're here with a coworker, discuss what you want to take back to your team. What will you implement? What do you want the outcomes to be? And finally, find someone who needs a mentor. And this is particularly relevant for those of you who may be newer to development. I know it sounds counterintuitive, but you're able to better remember what it's like to learn something for the first time. What worked for you? Where did you find those pain points? And so with that, a shout out to Will, Andrew, Troy, Steve, Jason, Aaron, and John for letting me pick their brains for this talk. Feel free to reach out to me on Twitter or by email and enjoy your afternoon tea and thank you.