Over the years I’ve taken many a would-be programmer under my wing and showed him the ways of our world.  Some of those mentorings turned out well, some not so much.  It’s always been my firm belief however that if you are in a senior or lead position in software, it is your duty to mentor and almost create an apprenticeship relationship with the newbies in your charge, to prevent them from becoming bad programmers and ending up as lowlights on the blooper reels of the Daily WTF.

When I was coming up the software lead I worked for was a dick and didn’t mentor me at all.  I had to learn everything on my own.  In one sense, that’s not bad.  I was driven to do well and make a career of this software thing, so I did what I had to do.  But in another sense, with nobody from whom to draw wisdom (and this was the pre-blog days fo sho) I picked up a lot of bad habits, wrongheaded ideas, and missed a lot of fundamental knowledge that should have been imparted to me.  My next job wasn’t much better, as the “software lead” was a no-coding glorified graphics guy who happened to do HTML.  My ability to succeed in spite of this poor leadership led to some of the hubris I described in my Growth of the Corporate Software Developer prologue.  Having recognized the need for mentoring in my own career, I decided I would do what I could to mentor those that came after me.

I have a pretty good eye for talent in software.  It’s not perfect so far (in fact, one notable exception was exceptionally notable in his badness as a technologist and a member of society) but I have helped bring along a couple of potential superstars, one of whom I’m happy to have working with me again several years later.  I’ve found that the key to bringing someone along in software is to provide guidance, but to ration it out.

You have to find the limits of your newb’s competence and confidence, and push him slightly (but not too much) beyond that.  Don’t answer every question, but answer some.  More often than not, encourage your noob to try something on his own, but provide hints on where to find the information he will need to get him going.  Keep in mind that you are probably successful in this business because you can find and process information efficiently, and apply it to your knowledge to solve software problems.  You have to learn how to draw from your past experiences and apply that to new situations.  So you have to make your noob learn this too.  Don’t spoon-feed him everything.

You have to let your noob make mistakes, and make a lot of them.  Then you have to make him tell you why it was a mistake, and what alternatively should have been done.  Don’t yell at the noob, or make him feel like he’s done wrong (unless he has done somehting seriously wrong or stupid) but don’t explain everything and coddle him either.  Part of learning from your mistakes is recognizing the actual mistake, and the ways it could have been avoided.

A big part of mentoring a young programmer is exposing him to the world outside of code.  The stuff that makes developers developers and keeps them from being downsiized and their jobs outsourced to foreign semicolon-jockeys.  I always go out of my way to teach that development is about business and people, and that the actual code is the least significant process.  Involve your noob in meetings.  Have him learn whatever business you are in from the people who do the jobs.  Have him sit with client services and learn what they do.  Have him hang out with sales and learn their processes.  We don’t develop software in a vacuum.  How can you write software that people use in their jobs if you don’t know their jobs?  Teach him that requirements and use-cases are important, and how to gather and document them, but also that they change, and that business is an ever-changing environment.  Teach him that flexibility is the key to what we do every day.

Make your noob learn things that are outside of his current job responsibilities.  Make him read things.  I like to have junior programmers learn about a development subject, say design patterns, or interfaces, or whatever, and then make a 5 to 10 minute presentation at the next dev meeting.  You and I both know that a big part of our job is communicating.  We have to be able to coherently explain technical material on a high-level to managers and customers, and on a very low level to other developers.  Help your noob learn to do both.  If you don’t help him learn all these parts of the job aside from the code, you are setting him up to be a failure.

Encourage any avenue of curiosity (within reason) that your noob shows.  If he wants to play with technology and try new stuff, let him.  The best developers are the ones that have a genuine love for what they do, and love to try and learn new things, and experiment with new ways of problem solving.  If you recognize this trait in your noob, cultivate it because you have a winner.

Basically, what I’m saying here is that if you are a tech lead it is your responsibility to lead those in your charge down the road in a way that will set them up to be productive members of corporate America once they no longer work for you.  Very much like you look back and think of that one teacher that really helped you see the light, or that really helped bring you around and make you the person you are today, your noob should look back and attribute at least a part of his success to your mentorship.  If you can’t accept this duty, you have no business being a technical lead.  This business is about people as much as it is about programs.

Having said all that, pop on over here to see *Doug’s* blog.  Doug is my newest noob (doug is not his name, but if you ever went to Pure Pwnage and saw the FPS doug videos, he’s kinda like that guy but twitchy++ and not quite as scary).  I hired Doug to be a Junior Programmer/Tester and he quickly worked his way onto the production code team, proving to be very bright and motivated.  He still has huge amounts of n00bishness and a lot to learn, this being his first real software job, but at that stage of the game, raw talent can get a rookie a starting spot on the team.  However, he has to work extra hard to keep that spot and grow and take full advantage of the opportunity before him.  My job is to help him do that.  So keep an eye on Doug’s blog, as he will undoubtedly be bitching about me there, but hopefully you will see some good content and good insights on the world of software development through the eyes of a n00b.

Doug, if you are reading this…get the hell back to work.