Software Development

Seven tips on mentoring entry-level developers

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:

J.Ja

Disclosure of Justin's industry affiliations: Justin James has a working arrangement with Microsoft to write an article for MSDN Magazine. He also has a contract with Spiceworks to write product buying guides.

---------------------------------------------------------------------------------------

Get weekly development tips in your inbox Keep your developer skills sharp by signing up for TechRepublic's free Web Developer newsletter, delivered each Tuesday. Automatically subscribe today!

About

Justin James is the Lead Architect for Conigent.

26 comments
D Walker
D Walker

Have not specificly been assigned as a mentor but often worked with new hires - some fresh out of training/school. As I was not really in charge of what was assigned sometimes they got into the deep end a little too soon... Always glad to help answer questions and point in the right direction - sometimes just finding good samples to see how the system worked would get them on track. Questions about what it is they are trying to accomplish until they break it down to a point they can get a handle on what to do often works well. I tend ask this sort of questions when I am the new person. Sometimes finds holes in the design/process along the way.

brooks_winston
brooks_winston

Cannot open the "Comments on this Blog". Below is the message I got (not the first time). "We were unable to find the page you requested. If you arrived here by typing a URL, please make sure the spelling, capitalization, and punctuation are correct, then reload the page by hitting the Enter or Return key on your keyboard. You have landed on a 404 error page -- the result of a broken link. The information you were seeking may be available on TechRepublic, but it is not at the location specified. If you were looking for a specific product, recent news story, or general topic, you may find it by entering one or more key words in our search engine above. Your other options are: return to the TechRepublic home page, contact Customer Service, or click your browser's Back button to return to the previous page."

Robsta
Robsta

Great article on Mentoring J. With those tips, she's likely to blossom into a great next gen developer!

mattohare
mattohare

This is a good case for having a suitable version system. Let them do something in a way that might not be the best in your mind. When it comes to bringing the whole project together, you may find that it's not suitable, but the new hire will be on the same page, and understand why. Or, maybe this will be one of the best new bits of the new project.

NickNielsen
NickNielsen

[i]...entry-level developers do not realize that the way they were taught to approach a problem may not be the only choice. [/i] When I was teaching, the first question I was asked after I assigned design problems in every one of my intro to engineering and digital electronics classes was "What's the correct answer?" My response was "The correct answer solves the problem you were given." I spent most of those classes teaching my students not electronics or engineering, but problem-solving techniques.

jslarochelle
jslarochelle

I enjoy it but it is sometimes frustrating. I don't mind inexperience if a new programmer is conscious of his limitations and willing to learn. I find that many new programmers are just too eager to impress. I agree with your recommendations. One thing to watch out for is the language used on the projects (or module) they are assign to: I would avoid C++ or even C (or assembly) if possible and assign new team members to Java or C# modules. On C# modules I would monitor closely the use of the more exotic features of the language (operator overloading, ...). I would also be careful with dynamic languages like Ruby, Groovy and others. Unit tests are critical for those languages. Static checkers are great tools to help monitor and guide new team members with code conventions and good practices. At work programmers are required to run Findbugs and get rid of all Java compiler lint warnings before a code review. Otherwise the code is rejected immediately. If possible a more senior programmer should sit and help new programmers through the first Findbug session. JS

jgarcia102066
jgarcia102066

You make some very valid points but I think they extend beyond an intern and should be applied to all developers in your organization. 1. Mentoring (Knowledge Sharing) should be a top priority for any development team. 2. Having a Roadmap - Even experienced developers need to know what they need to accomplish in order to move up to the next level. For example, what skillsets, years of experience differentiate a junior developer, developer, and senior developer. 3. Be tolerant of mistakes - We all make them. The focus needs to be on how to fix the mistake and how to prevent it from happening, again. 4. Assign appropriate projects - This one should be coupled with number 5. A team leader needs to know the developer's strengths and weaknesses in order to assign appropriate projects, regardless of the developers level of experience. 5. Give and accept feedback - I would actually place this at the number one spot and should be coupled with item #2 (roadmap). Developers need to know where they stand and team leaders need to know if they need to do something different to make the team more productive. Two-way communication is very important and helps to build a highly productive team when utilized correctly. 6. Listen (omit new employee's idea) - This is part of knowledge sharing. You can't hear potentially good ideas if you're too busy talking over everyone else. Good ideas can come from anywhere, you just need to listen and be prepared to recognize it when it comes. 7. Respect - You must treat all developers with respect. When you disrespect someone you lose that persons confidence and have potentially killed any good ideas they may have had.

KSoniat
KSoniat

AT an early job I had a mentor - Started easy, clear instructions, copied programs with small changes - worked up to more complexity as time passed. We had an intern and I mentored her. She was sharp as a tack and it was a pleasure to work with her. We tried to hire her but were in a neighboring town and she opted to go to a closer company. We gave her a good recommendation anyway. :)

Tony Hopkinson
Tony Hopkinson

From first their job to more of an appraisal / inducting role for intermediates. Agree with you on all points. The main thing I make clear is I'm there to answer questions and help them make it, not let them flounder during probation and then tell the boss they are useless. I've been the poor git chucked in the deep and, I manged to doggie paddle to the side, but that's going to be break far more often than make. Work them in gently small fixes, enhancements, tools and utilities. Let them find their way and how they should apply what they know.

Justin James
Justin James

Have you ever been a mentor, or have been mentored? What are your experiences with it? J.Ja

Justin James
Justin James

The forum system here is, unfortunately, not 100% reliable (it used to be much worse, but they've made a lot of improvements, thankfully). When you see that message, it really means "try again in a few minutes". Sorry about that! J.Ja

Tony Hopkinson
Tony Hopkinson

You could teach a few teachers the technique while you are at it.

tv_p
tv_p

Thanks Joe for making excellent list of points. I really N'joyed reading because I felt same way. Thanks

johndecoville
johndecoville

Great article Justin. And I enjoyed all the responses it triggered. Cheers! --John

victor.gutzler
victor.gutzler

My brief experience as a newbie programmer/intern was to document the code for the mentor while shadowing him on his project. After swallowing my pride, I learned to appreciate the opportunity to learn the coding standards by example. Of course, it still didn't seem to prepare me for my first project assignment (there's nothing like having a team jump on you as you show them how you coded a real app), but such is the life of any tyro (today's word is -- tyro). By the way, the article was great, except it sounded a bit anti-chauvenistic. Unless the word for a novice programmer is linguistically gendered (m?glicherweise auf Deutsch), can you stick with nongender pronouns (one, person) rather than hammer out an attempt to be politically correct? Doesn't English, for good or worse, still default to using male pronouns in nonspecific references?

debposton
debposton

I believe for a mentoring program to be successful, you have to learn to listen more than talk. As a mentor, ask the right questions to get them thinking and doing instead of giving them instructions. Help them to see if something will work by asking questions...not just stating.."that will work or not work". If they fail, help them to see that failure is good. It teaches us how not to do something and helps us learn another method. If they succeed, ask why, what, when....keep them thinking at all times. Mentoring is wonderful. It is hard because I want to get in there and do the work...however, you have to let them learn and grow. Develop a strong relationship and be honest with them.

Tony Hopkinson
Tony Hopkinson

are the most valuable thing you can give to a any new programmer when they join. If what coding experience they have has all been working alone, at best their standards will be different, straight out of academia you'll be lucky if they are even aware of the concept. :(

Sterling chip Camden
Sterling chip Camden

You have to let them do things on their own and make mistakes. Don't always provide all the answers. They learn better if they discover principles on their own. When you discuss principles of programming, don't make it a lecture -- make it a mutual discussion. Ask questions, and try to get them to discover the answers for themselves.

mattohare
mattohare

Go back and paste it again. It usually works on the 2nd go.

NickNielsen
NickNielsen

I walked out of the classroom with 10 weeks left in the school year because the other options were a nervous breakdown or physical damage to a student. Once I made the decision, my stress levels dropped like a rock. I got the first good night's sleep I'd had in months that night.

Justin James
Justin James

Interesting, the version I sent in uses "they" (I almost exclusively use non-gendered pronouns in my writing). Looks like my editor here changed that, and I didn't notice it at all when I reviewed it (I double checked what I was sent, it was indeed changed to "she" and I overlooked it). Hmm. J.Ja

jslarochelle
jslarochelle

Check InfoQ: Static Analysis Tools Roundup Mentions Flay, Reek, Roodi and Rufus. JS

jslarochelle
jslarochelle

Findbugs is a really good one. It will catch several of the deviation from the good practices described in Joshua Bloch Effective Java Programming. It works at the bytecode level and can actually catch cases of resource leaks (failure to close files or JDBC resources in all paths). Another good one is PMD. Although not as smart as Findbugs this one incorporates a bunch of code conventions rules like variable name length and such. I like the Metrics tools to check things like Cyclomatic complexity, Efferent coupling and other such metrics not covered by the other tools. JS

mattohare
mattohare

I don't remember noticing such in your writing before.

Editor's Picks