For an industry that prides itself on its analytical ability and abstract mental processing, we often don't do a great job applying that mental skill to the most important element of the programmer's tool chest - that is, ourselves.

For those of you who haven't had time to keep up on your recent video game releases, “Battlefield 1” (EA) is a traditional first-person shoot-'em-up (much like the rest of the “Battlefield” family), this time set in the timeframe of World War I, from 1914-1918. Numerous storylines are available to play out. Just last night, I found myself playing the Gallipoli campaign: You take on the role of an Australian named Bishop, an old grizzled veteran of war who is assigned a young (“lied about his age”) kid who's never seen war before. The kid's excited, but in way over his head, and Bishop has to get the stars out of the kid's eyes before his youthful enthusiasm and innocent views about the world gets him killed.

It's a tale as old as time: Grizzled veteran, with far too many years and emotional scars behind his eyes, sees something in this kid that's too precious to risk losing. Stuck, the veteran takes the kid in, trying to impart years of wisdom in a few key lessons, teaching the kid how to survive where so many others have perished for lack of that wisdom or knowledge or insight.

It's a classic story trope, to be certain, but merely the stuff of fiction. Until your boss walks into your cube and says, “By the way, we have a new junior engineer joining the team next week, and I'd like him to shadow you for a while. Be a mentor. Show him the ropes. Teach him the critical stuff so I don't have to, you know, fire him.” You think your boss is kidding, but… You're pretty sure you don't want to find out.

This leaves you with the rather uncomfortable question: How, exactly, are you to be that mentor?

Mentoring 101: Rule #1

In some respects, mentoring is simple: Just be the person that you wish you'd had when you were starting out as a young, wet-behind-the-ears programmer. Be the kind of caring, nurturing person that you always wished you'd had when you were stuck, wrestling with problems that seemed far beyond your capabilities at the time, and….

Yeah, OK. That wasn't me, either.

Part of the problem with mentoring new developers is that half of the time, like all newcomers to any sort of profession, the newbies not only don't want the help, they're pretty convinced they don't need the help. After all, part of the fun of programming is the challenge of overcoming obstacles. (Admit it, it's pretty cool when something that's been blocking you suddenly becomes clear and you code it up, write the tests, watch them all pass, and deploy it into production without a hitch. Fist pump, yeah! Obstacle overcome!) If that's the fun part, why would anyone hand that part off to somebody else? Would you?

That's not the only issue at play here. For many new programmers, the first job is the first chance to prove that they “have what it takes” (whatever that is) to succeed. Some are still a touch angry at all the interviews they did with companies that didn't hire them, so they're doubly-motivated to prove to whomever is watching (mostly themselves) that all of those other companies made a mistake by not hiring them. And some are looking simply to impress the company that did hire them, as a way of “rewarding” the company's “faith” in them. (Heck, that sometimes goes for senior developers, too.)

All of which brings us to derive Rule #1 of mentoring: “Mentor only those who want to be mentored.” Although it can be frustrating to watch somebody make mistakes that could be avoided with just a little bit of well-placed wisdom or advice, remember that sometimes the best lessons learned are those learned the hard way, so long as the consequences are not too severe. Trying to be helpful to someone who doesn't want to be helped often has the opposite effect: It comes across as pushy, arrogant, and entirely intrusive.

(If this starts to sound a little like parenting advice, that shouldn't be too surprising, since many of the young twenty-somethings aren't all that far removed from being teenagers, and frankly still have some vestiges of childhood to shake off. In fact, a few recent psychological journal articles have suggested that one's twenties are the new teenage years in terms of “coming of age” and preparing to assume adulthood.)

Some companies take an active role in this, mandating a mentorship relationship when somebody is first hired. This is most often a positive step, particularly because it can be a bit tricky for new hires (of any skill level) to understand the new company's culture or processes or to navigate who-is-the-right-person-to-call-when. However, the would-be mentor still has to tread a little carefully until the receptiveness of the mentee is clear - keep the door open, so to speak, but don't insist on anything beyond the occasional get-together (formal or informal) to check in and see how things are going.

Sometimes, the mentee is ready. In fact, sometimes, they're desperate. They know there's so much they don't know and they're counting on you to show them all of it. They're turning to you with eager eyes. What now?

Mentoring 101: Rule #2

“Active listening” is absolutely critical here, but not the way that it might seem off-hand. In the initial stages of the mentoring relationship, it's not the mentee who needs to be the active listener; the mentor first needs to understand what the mentee is looking for. Seed the opening conversation with questions about the mentee's goals, directions, questions, anything. What are his principal questions? What does he feel comfortable with? Does he have specific concerns, or is it more that he just wants to have somebody to use as a safety net in case things get overwhelming?

Rule #2, stated simply, is “Ask, then listen.” Ask questions of an open-ended nature, designed to draw out the mentee's current state of mind. Then, engage the active listening: Lean forward, focus on the answers, and echo back what you hear them saying for clarification or correction. Minimize potential distractions. They need to know that you are engaged with them, and that you are hearing them. This conversation is about them. Offer no solutions yet; that will come later. For now, listen to their concerns and their issues, and listen for where they want to go with this.

In case it wasn't already apparent, what comes out of this conversation is goals and directions. Although some mentoring relationships can remain entirely open-ended and without any sort of structure, more often than not, it's helpful (and, sometimes, necessary) to both sides to lay out some kind of list of goals or objectives. Better yet, work out a high-level plan of attack: who will do what and when, and what each person is responsible to bring to the relationship.

In some respects, having goals serves the purpose of knowing when the mentoring relationship is finished. Not so much because it needs to end, but so that there can be recognition that now the pair are more peers and colleagues instead of mentor and mentee. (Or, perhaps, the pair will then choose a new set of goals to work toward; it depends on the pair and how comfortable they've grown with each other.) Ceremonies are important to human beings - having a clear point at which “graduation” occurs is important if for no other reason than to have a well-defined goal.

Summary

Certainly, much more can be said about mentoring. Whole books have been written on the subject; in fact, it's fair to say that entire sections of your local bookstore are slavishly devoted to the topic, particularly if we include the ubiquitous “self-help” section as a form of mentorship between author and reader. However, what I've written so far can seem a little abstract, so I'll offer up a personal mentoring story from my recent past as an exemplar.

When I was CTO at a consulting company, I learned that a friend's adult daughter was re-tooling her career to become a programmer. She was finishing up her enrollment at a local programmer trade school, and was about to start looking for her first professional job as a newly-minted MongoDB/NodeJS/Angular developer. My company had absolutely zero need for one of those - we were a.NET and Java shop, with much heavier emphasis on the .NET side at the time. However, we did have a need to build out a new website (the old one was a pretty boring static HTML page), and I wanted it to have some blog-like capabilities, which was obviously something that a MEAN (Mongo/Express/Angular/Node) stack could easily deliver. (Plus, I had long-term plans to develop out a MEAN-centric expertise, but that didn't pan out before I left.)

I approached my business partners and my friend's daughter with a plan: We would hire her at a pretty minimal rate to work 20 to 25 hours a week on our website (using the MEAN tools with which she was familiar), according to requirements that I and my CFO described. That was half of her job; for the other half, we'd provide her a company perk in the form of a subscription to an online training service. She'd spend another 10 to 15 hours a week going through online courses that I selected, and we'd meet once a week to go over the material. I'd provide homework assignments, in the form of code that I wanted her to write; these assignments would be essentially the framework through which she'd test her learning, provide a way for me to judge her progress, and give us both a common framework in which to ask and answer questions. We started out doing a little of both Java and .NET, until the company's fortunes made it clear that the firm would be needing a junior .NET developer before long, at which time we switched her over to studying nothing but C#, ASP.NET, and related parts of the .NET stack.

Within three months, she was slinging C# pretty proficiently, enough so that we moved her over to a client team. That was about a year ago; when last I spoke with her team lead (just prior to my departure from the consulting company), he told me in no uncertain terms that if I were thinking about moving her over to a different team, he was going to inflict physical harm in my general direction, because she was the best developer he had on the team. (She's since gotten promoted twice within the company, and actually gave a talk at a local CodeCamp about her experiences, both as catharsis and as an inspiration to others at the CodeCamp who were in the same situation as she not too long before.)

Both rules were clearly in force: She was “all in” on the mentoring approach and she never once missed one of our weekly get-togethers. Once we laid out a general direction in which to go, she took to it eagerly, and we together laid out our steps to her proficiency, guided by some of her own desires. She had little desire to learn more about databases, preferring instead to focus on C# and domain-object modeling and ASP.NET, because “that's the interesting stuff,” as she put it. We spent some time on some other topics, as well, but the main emphasis was C# and ASP.NET, and she reveled in it. And once she got there, we shook hands, parted ways, and she was off. Someday, perhaps, we'll pick back up again on something else, but for now, she's on her way.

And for the mentor, that feeling - watching your charge leave the figurative nest and make her way forward without you - that's what it's all about. You rub at one eye that's suspiciously wet, mutter a “Good luck, kid,” and go back to being the grizzled battle-scarred veteran.

Until the next one comes along, of course.