Mentoring Junior Developers

One of the biggest struggles of the development community is the mentoring, encouragement and development of entry-level and junior developers. A couple of years ago when I was adding people to my team, two of those I hired were women essentially right out of college. I found myself faced with a struggle that many dev managers and leads have faced over the years:

How do I encourage, train and develop junior developers?

I certainly didn’t want either of them to go through the same struggles I went through. When I was hired out of college, I had both advantages and disadvantages. I was a career changer in my mid-30’s. I had worked for more than a decade in various jobs, so the work mindset was not new to me.

However, I was hired onto a team as the only .NET and web developer. The others included a Lotus Notes dev, and a handful of other devs who worked on proprietary banking applications that had their own custom programming languages. My manager handed me a book on VB.NET & ASP.NET 1.1 and told me to get to work. It didn’t help that over the next two years before I left we went through a half-dozen different managers over our team.

There was no way I was going to let my two junior devs go through that experience. I immediately started working on developing and implementing a number of procedures and policies that I hope helped them during their time working for me. Hopefully they can help you as well.

Feedback

Developers receive feedback all the time. Most of it comes from clients and most of it isn’t all that helpful. Junior developers need constructive feedback. They have no idea if something they wrote is good or bad, efficient or crap. Most of the time the client can’t tell them that either. They need someone who has experience to review their work and their progress. There are a few ways that this can be accomplished.

One on Ones

Establish a policy of holding a weekly (or at least every other week) 1-1 sessions with every member of your team. Make it a “closed-door” meeting in an office or conference room where you can talk openly about how you feel they are doing and how they feel they are doing. Cover patterns that you’re seeing in their work ethic and code and what you feel is good and/or bad about each pattern. Make sure you also get feedback from them as well. It should never be one sided.

This is not the place for specific code reviews. If you’re seeing a particular pattern they use consistently that is not productive, this is a good place to provide training on the correct pattern.

Take notes on the things that they talk to you about and make sure that you follow-up on those where appropriate. This is critical. If they tell you something and you never follow through, they will eventually stop talking to you about the things that concern them. Eventually, it will drive them to leave.

Make sure also that the feedback you give them includes the good as well as the bad. If all you do is point out their mistakes, it’s easy for a senior dev, much less a junior one, to get discouraged. This will eventually make them want to quit at least their job, if not the dev field entirely.

Code Reviews

A critical process for teams are group code reviews. I’m not suggesting that every code check-in should be reviewed as a team. There isn’t time for that in any team. But you should spend time on a few random samples to go through as a team each week. This is the best place to teach best practices for the team. It’s one thing to talk policy during meetings. It’s another completely to learn it by example and doing with your team’s real code.

Get the team in a conference room with a projector or TV, put the code up, and walk through it together. Have people provide feedback on what’s good and suggestions for improvement. Emphasize that feedback should be constructive and not negative in tone. The goal is to work together to learn and improve everyone’s skills.

Also make sure that you aren’t picking on any one developer’s code more than the others. Even your most senior developers can learn a lot. If they have the attitude that they know everything and are unwilling to listen to feedback, they have to go. It isn’t worth having them around to poison the attitude of the whole team.

Annual/Bi-Annual Reviews

The leadership process should include annual or twice a year reviews. These reviews should be more general than the weekly 1-1’s. They should focus on broad and long-term goals. Whether it’s tied to a pay raise or not, you should be holding these review sessions with your team members.

Take this time to review progress on goals from the last 6 or 12 months. Set new or revised goals for the next 6 or 12 months. Follow up on progress with their goals at least once a month during your 1-1 sessions. Goals not discussed are goals forgotten.

Open Door Policy

Your junior devs need to feel like you are willing to hear what they have to say. But this doesn’t just apply to you. Cultivate an open environment on your team. They need to feel like they can go to anyone else to ask questions, suggest ideas for improvement and so forth. If they feel like you’re the only one that will listen, you have far more serious problems with your team that need to be addressed as soon as possible.

Make sure your junior devs feel like they can ask any question. They should never be told their question is ridiculous, silly or stupid. The quickest way to stop someone from asking important questions in the future is to ridicule the “obvious” questions they ask now. The answer may be obvious to you now, but it’s not to them. Remember, there was a time it wasn’t obvious to you either.

Learning

Encourage learning and provide opportunities for your devs to learn. Even if there is no training budget, a pathetic and sadly all too frequent situation for dev teams, you can at least make time for training opportunities. Even if you have to bypass, ignore, go around or openly defy the corporate overlords who have denied you a training budget, make it a priority. Figure out a way to make it important.

The most important skill to teach your devs is how to research and resolve problems themselves. Before you can learn to run, you must learn to walk. And before you can learn to walk, you must learn how to “GoogleBingStackOverflow” something. Help them learn how to search for code error and problem resolutions on Google, Bing and StackOverflow. Each has pluses and minuses. But each can save you a thousand times over each year. There is not one more important skill to a developer than this. Pass on what you have learned.

Pair Programming

I don’t necessarily mean this in the commonly referred to way where two devs sit down at a computer and work together on a problem. Instead, as a team leader who wants to help their junior devs learn, I suggest the following.

Spend time with your developers, especially the junior developers, working together on a coding project. But instead of being a full member of the pair, so to speak, let them do the driving. You take on the role of providing suggestions and feedback, but only after the dev makes an attempt on their own first. Think of it as a one on one code review happening in real-time.

Watch them go through the process of figuring it out themselves and making their attempt first. When they have completed or get hopelessly stuck, go through it together. Point out what they did well and suggestions for how it might be approached differently or more efficiently.

Even when suggestions are made for improvement, it should never be a mandate and you shouldn’t tell them how to do it. Make it more in the format of suggesting they look into another method themselves. For example, if they use an IF/ELSE flow in C# to determine if a variable is null and set a value if it is, suggest they look up how to use the null-coalescing operator.

One thing is absolutely critical about this process. You should never touch the keyboard yourself. You should never “take over” and show them how to do it. Instead, help them to learn how to do it on their own. Learning by doing has a far greater impact than learning by watching someone else do.

Conferences

There is no shortage of developer conferences available for developers to attend. In my area, Columbus, OH, each year there are near a dozen different conferences (that I know about) in the immediate area and more across all of Ohio. My favorites are Stir Trek, CodeMash and DogFoodCon.

Conferences will range from a single day, like Stir Trek, to near a full week, like CodeMash. Make time for your developers to attend at least one conference a year. If you can pay for their tickets, even better. But if not, the least you can do is let them go “on the clock” and not have to use a personal day. Do whatever you have to do to give them the opportunity to attend. If they choose not to avail themselves of the opportunity, that’s fine. But it should never be because you didn’t give them the chance.

Developer conferences are an experience unlike any other and every developer, especially a junior dev, should experience it. National/International conferences like Build, NDC, GDC and IT/Dev Connections are great, but nothing matches the enjoyment of getting together with developers in your area to learn and share. And they’re a lot cheaper. Even four days of CodeMash is less than half the cost of Build’s two and a half.

Find a way to get your developers to a conference. Just do it!

User Groups

Developer user groups are everywhere… EVERYWHERE. Here in Columbus there are four user groups alone just for Microsoft technologies. And several others that cover everything from game development to Angular to SQL. And that doesn’t include the various groups that focus on non-language specific needs like Girl Develop It and OWASP.

Encourage your devs to attend one local user group a month. I am constantly amazed by how few developers take advantage of this amazing resource right there in your local communities. For example, by some estimates in Columbus there are a few thousand .NET specific developers. Yet monthly attendance at CONDG seems to average around just 30 attendees. These amazing resources for learning and networking are being greatly under-utilized in my experience. I realize we all have lives and things are busy, but one night a month is a worthwhile investment in yourself.

If you’re a company with some means, talk to your marketing people about sponsoring local developer groups. These groups are almost all volunteer run, with no budget for themselves. Providing some money for food or swag at meetings and events goes a long way and can help the groups grow.

Team Training

Take at least a couple of hours each week to have a team training session. Encourage others to lead at least half of these training sessions. You shouldn’t be the only one responsible for the team’s skills growth. Encourage interaction during these sessions. Ask questions and encourage others to do the same. Make it an opportunity for everyone to grow.

These are excellent opportunities for everyone to learn something. Make sure your junior developers feel like they can contribute. Encourage them to lead some of the sessions as well.

The topics should be a mix of both things you see that the team needs to improve on and things that have nothing, or little, to do with your day-to-day work. For example, if you’re a .NET team, maybe one week is on the latest improvements to EntityFramework and the next week is an overview of creating applications written in Go. Mix it up. Let team members suggest topics as well. It’s not just about learning. It’s about encouraging creativity in your devs.

These are also good times to talk about development policies. I hate team & staff meetings. They seem to just consume time for very little benefit. Aside from code reviews, training is the next best time to cover dev policies and best practices and ensure that the code being created meets your standards.

Code Contests

One of my favorite ways to encourage learning is the use of coding challenge sites such as CodeEval or Codewars. Every week or two I, or one of the devs, would pick a challenge. Then we would get together Friday afternoons and review each other’s solutions. We never restricted it by language. The dev could pick any language the challenge site supports.

Let’s face it. Friday afternoons are usually a complete waste for devs anyway. No dev wants to get knee deep in a coding problem and then stop mid-way, coming back Monday morning to spend an hour trying to remember where they left off. This takes a typically wasted hour or two each week and turns it into something that can be a productive learning experience for your team.

Department Libraries

Assemble a collection of books and make them available to your team. Generally I would recommend they focus more on style and general techniques rather than language specific since technologies tend to change rapidly. It’s important to include non-technical books in libraries like this as well. Let team members borrow the books to take home and read if they want.

Some of my favorites include “How to Win Friends and Influence People”, “Code Complete 2”, “Surely You’re Joking, Mr. Feynman!”, “Getting Things Done”, “The Mythical Man-Month”, “Peopleware” and “Zen and the Art of Motorcycle Maintenance”.

Online Learning

Online learning libraries like Pluralsight and Lynda.com offer tremendous opportunities for skills development. Their downside is cost. However, many other free resources exist for devs looking to expand their skill set, including YouTube, Microsoft Virtual Academy, Google Developers Training and others.

Lunch N Learns

I will say this about lunch and learns. I… HATE… THEM… There is nothing about a lunch and learn that is positive. It’s even worse when they are mandatory, as I’ve heard some companies do. And worse upon worse is a company that expects you to bring your own lunch to the lunch and learn.

Lunch is non-work time. Whether you’re spending it by yourself or with co-workers, it is NOT a time to think about code. You need a break. You’re mind needs a break. In my opinion, devs who think about or work on code during their breaks and lunches are almost universally less effective.

I will often eat at my desk during lunch. But I will never, ever work on code during that time. I will check Twitter, Facebook, watch YouTube or Netflix, anything at all other than code.

So don’t encourage Lunch and Learns, don’t support them. And if your corporate overlords are pushing them, push back for real training time and experiences that are on the clock. And frankly, if they don’t support that, it’s not the kind of place you really want to be at. Go find an employer with a better culture.

Plan For New Developers

Whether they are junior or senior, there is always a period of ramp-up time for new developers joining your team. Create and implement a plan for getting these developers up to speed as quickly as possible with the specific quirks and nuances of working on your team and the projects they will be working on. This will give new hires, and new junior devs especially, more confidence in your ability to mentor them and improve their skill set for the near time and far future.

Forgive Mistakes

Photo by NeONBRAND / Unsplash

It doesn’t matter if you’re a junior developer or a senior one. There will be times when you screw up. Sometimes it will be a big time screw up. Establish a culture with your team that proactively works to prevent mistakes when possible, but which will also be forgiving when those screw ups occur.

Make mistakes a learning experience, both for the dev and the team. Do a post-mortem to discover how the mistake occurred and implement a plan to help prevent a repeat in the future. Fresh eyes often have the habit of discovering the flaws we’ve overlooked for years.

Assign Appropriate Work

Junior devs are junior for a reason. They haven’t learned as much as others. Bringing in a junior dev to immediately work on advanced portions of your code by themselves is a sure-fire way to create mistakes that you’ll need to forgive later. Make efforts to assign tasks that will practice their existing skills and stretch them a little bit as well. Give them opportunities to stretch, but don’t stretch them so far they snap.

Respect

Show your junior developer respect. Make them one of the team. Make them an equal. This is crucial to building their confidence and helping them expand. There have been times I’ve seen senior developers treat junior developers like garbage. Or even worse, like they aren’t even there.

A note on female developers and the development culture

There is, in more than a few companies, a culture of disrespecting female developers. For myself, I don’t understand how anyone could even think that a female developer is somehow less capable than a male. I have been blessed to work with quite a few over the years. And just like the male developers I’ve worked with, some of them were bad coders, some of them were good coders and some of them were amazing coders.

Thankfully, as far as I have experienced, the culture at the places I have worked over the years has not been one where such behavior is acceptable or tolerated. If that is not the case where you work and you have any influence at all, work to change that culture. There is no room for disrespect. If that means you have to fire the senior dev who has been there 20 years and knows every system inside and out, then get his ass out of there. We are losing far too many fantastic developers because the culture is driving them away. Stop it. Just stop it.

It’s simple. It really is. Treat everyone on your team with respect and equality, give them opportunities to learn and grow, and they will reward your trust a thousand times over.