Career Nav #65: Teaching to Empower: How to Support Junior Engineers

iTunes – Spotify – Google – Video – More Episodes

Rizel Scarlett, Developer Advocate at GitHub and Program Director at G-Code House shares her talk, “Teaching to Empower: How to Support Junior Engineers.” She discusses creating safe spaces for junior developers to ask questions and shares strategies to make it happen. She also talks about adapting your teaching style to your students.
I did some cool things for my first two years as a software developer. I built impactful features. One of my favorite ones was called Auto Translate. It removed language barriers between our users and allowed them to speak their native language. They got to see a real-time translation. I also worked to improve the code base by doing database migrations, taking the initiative to implement automated UI test plans, and managing releases and bug bash sessions. I also managed and mentored interns.

At the time, I did not recognize any cool things I was doing and felt very embarrassed. I felt incompetent under pressure and full of anxiety, and I was often debating if I should quit. I felt like I didn’t belong in tech and that I was a bad developer. Then I figured this is what being a junior developer was like, so maybe I need to produce more work. I would stay up late and try hard to finish as much work. I thought maybe I was not smart enough. I enrolled in college to pursue a degree in computer science. I spent much time trying to prove my worth to myself and my coworkers. I didn’t recognize any of the awesome work I did. I didn’t take the time to acknowledge any of my progress.
Unfortunately, my experience is not isolated. I started talking to other junior developers from Twitter, coding bootcamps I graduated from, and other developer groups. They were having similar experiences where they were getting negative reinforcement. They thought they were bad, and some decided to quit tech. It shouldn’t be that way. My perspective started to shift when I experienced these three things. I started teaching people to code.

You might be able to survive in a toxic environment, but you cannot thrive in that environment. Find the space for you to thrive. Don’t try to stick it through. My confidence increased when I changed my environment into a more positive environment. I started to get more peace, and I got a better work-life balance. That’s still a work in progress for me. I gained a more realistic awareness of my strengths and weaknesses. I also developed a passion for empowering junior engineers and helping them grow. Because of my experience, I thought people shouldn’t be experiencing this.

If you’re a boot camp founder, a teacher at a boot camp, or a mentor, your role is to teach. You could work at a school or a college, and you’re a professor, or you’re in developer relations. The whole point of your job is to teach developers. For other people who are engineering managers, senior developers, mid-level developers, and even some junior developers, you may not realize it, but that’s part of your job responsibility, too. It may not say it in your job description, but you have to. You have to help less experienced engineers and help them grow so they can get to where you are. Many people try to do that, but they’re not empowering others as they teach. As a mentor, you might feel excited to share your knowledge. That can be overwhelming for the junior developer. You may be ignoring their actual needs. Listen to figure out what they want and need and make support available. My husband’s job had office hours. He had a designated mentor to help him answer any questions. Their job was to prioritize answering those questions and helping him. That made him feel safe, that he could ask a question anytime. I was in a situation where the senior developers were busy. They were bogged down with a lot of work, so they didn’t have time to answer my questions. It made me feel like I was incompetent or stupid for asking questions.

Create space or time for them to ask questions. Set clear goals and expectations. Most junior developers don’t want to be juniors forever. They want to know that they’re not stagnant. They want to reach different milestones. Make those clear. My husband’s manager had a checklist to help him get from level one to level two. I asked my manager how I got from level one to level two; he didn’t know. It made me feel like I would never get to the second level.

Teaching at G-Code put me in this position of understanding how other senior developers feel. Teaching people to code can feel frustrating and scary. The first thing I learned was about being vulnerable. I noticed that tech is rooted in elitism and academia. We always pretend to know it all. It’s the norm to be like, oh yeah, I already know that. You have to be honest. You don’t know everything. By saying that, you reduce new developers’ pressure to know everything. At G-Code, I always say, I don’t know, let’s Google it. I encourage the other mentors to do the same. Don’t ask if they’ve Googled it. I used to hate when people did this to me as an early career developer. Then I realized I started doing it to other people, too. Now, I lead them through a question framework. What’s your goal? What are you trying to do? What have you already tried, and what did those results look like? That way, instead of just saying, have you Googled it, they are answering those questions, we’re not wasting time.

I also learned that your teaching style may not suit your learning style. How you want to teach is not always how they learn best. You have to learn to adapt to their learning preferences and provide options for them to learn best. Some people need to learn by video. Some people need to learn by doing it together. Some people need applicable examples, and others need more theoretical ones. So you have to learn to adapt to that. For more formal teaching, here are three quick tips using spaced repetition. It’s a method that people use to review material at systematic intervals because our brains can’t hold everything at once.

For this, I use Kahoot! Quizzes. Every week, we do a little fun Kahoot! Quiz. It’s competitive and not scary in a way. I’ll use some questions from the first week and sprinkle them in with questions from the seventh week. That way, they’ll remember new stuff and then get a reminder of some older concepts. I also gather feedback every week. This is part of listening more than you speak. You want to ensure you understand how the junior engineer feels and what you can do to make it better instead of just assuming how they feel. Gradually increase responsibility or learning. This works for work and in an educational setting. Sometimes, people want to throw the junior developer in on the deep end too quickly. Give them a minor bug and then a bigger bug, but one that is related to the small bug. That way, they start to be able to make those connections.

Once I worked in an environment where I believed I could thrive, one thing that my manager had me do was reflect between tasks. After completing a ticket, I would write a note or blog about my learning. I retained what I learned. It was such a good practice. Another thing was introducing empathetic code reviews. Engineers like to be very blunt. It’s good to be thoughtful and kind and take time to read the code correctly and provide thoughtful advice. Let the junior engineer know when your suggestions are blockers or nitpicks. That was one thing one of my teams did when I switched jobs. They said this one can’t go into production, so definitely change this, but this is a bit of a nitpick. You can still merge it, but make sure for the future this is a better way that you can do this. That way, the junior developer is not feeling so overwhelmed.

Avoid placing blame and help the junior engineer fix an issue when they make a mistake. Let them know it’s okay and that you’ve made the mistake before. Give them tips on how to avoid the mistake in the future. Often, the developer is already beating up themselves for making a mistake, so you don’t need to beat up on them even more. Start thinking about your culture to make the space a good place for junior engineers. Give positive reinforcement to early career devs. Everyone can create that culture of giving positive reinforcement.

That will encourage people to want to do even better. Genuinely highlight their achievements. Let them know that they’re doing a good job. Start thinking of methods to prioritize, helping each other on your team while still making progress on your code base or product. Lastly, write clear tickets and documentation so your junior developer can start working confidently.