X
Business

How to mentor entry level developers

TechRepublic's Justin James has seen enough mentoring boondoggles to have a good idea of what does and doesn’t work. He shares his ideas about how to have a successful software developer mentoring program.
Written by Larry Dignan, Contributor

TechRepublic's Justin James has seen enough mentoring boondoggles to have a good idea of what does and doesn’t work. He shares his ideas about how to have a successful software developer mentoring program.

One of my recent TechRepublic polls covered the topic of why we hire entry-level programmers. According to the poll results, more than half of the respondents hire entry-level programmers so they can mentor them into the type of programmer they need.

Schools alone can’t prepare programmers for the real world; some sort of internship or apprenticeship is needed to complete a programmer’s education. Unfortunately, few schools offer rigorous internship programs; even worse, most companies simply don’t have anyone with the time to properly mentor an intern. (My latest download is an example of what a good training program for developers might entail.)

If your organization is starting or revamping a mentorship program, read my ideas about how to have a successful software developer mentoring program. Before launching into my tips, it’s important to note that not every senior developer makes a good mentor, and there’s no shame in knowing your limitations. If you don’t think you can fully commit to being a good mentor, or you don’t think you have the necessary skills or traits to be one, then say something. It’s better to admit that you aren’t cut out for the task than to force yourself to do it and waste time and probably alienate a promising new employee.

1. Make mentoring a priority

I think the key ingredient in a successful mentoring relationship is giving the relationship priority above anything other than an emergency. It is the inability to give the relationship priority that makes true mentoring scenarios so rare. If you don’t make the mentorship a priority, the new hire quickly senses that she is not important. She also quickly figures out that, when she goes to you for help, she is slowing you down from attending to your “real” priorities. The end result? She doesn’t seek you for help, and she tries to do things on her own. Basically, you’re no longer her mentor.

2. Have a road map

I’ve seen a number of mentoring programs sink because there is no plan. Someone is hired, and a more experienced developer is assigned to show that person the ropes. The experienced developer wasn’t told about this new mentoring role until 9:05 AM on the new hire’s first day. The would-be mentor takes the new hire on a tour of the building and introduces her to a few other teams — and that’s the extent of “the ropes.” The only thing the new employee usually learns is where to find the kitchen. You need to have a game plan with set goals (for the new hire and the mentor) and a list of topics to cover; otherwise, you’ll both feel lost and give up before you even start.

3. Be tolerant of mistakes

Working with entry-level developers can be frustrating. They are not familiar with writing code in a real-world environment with version control, unit tests, and automated build tools. Also, they may have been taught outdated habits by a professor who last worked on actual code in 1987. Often, entry-level developers do not realize that the way they were taught to approach a problem may not be the only choice. But if your reaction to mistakes is to treat the developer like she is stupid or to blame (even if she is being stupid or is truly at fault), she probably won’t respond well and won’t be working with you much longer.

4. Assign appropriate projects

One of the worst things you can do is to throw an entry-level programmer at an extremely complex project and expect her to “sink or swim.” Chances are, the programmer will sink; even worse, the programmer will add this project to her resume, and then she will run out of there as fast as she can just to get away from you. On the other hand, don’t create busywork for the programmer; let her work on nagging issues in current products or internal projects that you never seem to have time to address. Once you gain confidence about what the programmer can accomplish, then you can assign a more difficult project.

5. Give and accept feedback

You can’t successfully navigate a ship in the middle of an ocean without a compass. Likewise, the new employee will not achieve her goal of becoming a productive member of the team without knowing where she has been and where she is going. This means you need to give feedback on a regular basis, and the feedback needs to be appropriate. For instance, being sarcastic to someone who made an honest mistake is not helpful. Feedback has to be a two-way street as well; you need to be listening to them to find out what their concerns and questions are, and address them.

6. Listen to the new employee’s ideas

Entry-level developers have a lot less built-in prejudices and biases than experienced developers. Sometimes the saying “out of the mouths of babes” really applies. A number of times in my career, I’ve seen a less-experienced employee point out an obvious answer that all of the more experienced employees overlooked. When you treat a new hire as a peer, it raises their confidence and makes them feel like part of the team.

7. Treat the developer with respect

Just because someone is entry-level, it doesn’t mean that her job is to refill your coffee or pick up your lunch. She isn’t rushing a sorority — she’s trying to break into the development business. If you disrespect the developer, she might leave or go to HR about your behavior (and maybe still leave).

Rewarding experiences

A few years ago, I had the opportunity to work closely with someone who was not as experienced as me, and we both learned a lot in the process. While I may not have officially been his mentor, it was a good description of our relationship. I still keep up with him, and we frequently talk about business, programming, and so on. He laughs at a lot of my more traditional development techniques, and I get to share with him some of the painful and costly lessons I’ve learned along the way.

If you’re considering being a mentor, these relationships can be very rewarding. I hope the tips I presented will help you the next time an entry-level developer is assigned to your department.

For additional information about mentors and mentoring, check out these TechRepublic resources:

Editorial standards