Mentoring and Being Mentored

It’s been said that the only true constant in this universe is change. In our day and age of ever-increasing knowledge and information, that proverb seems truer today than ever before. Everywhere we look today, change is practically inescapable; we can’t really even slow it down, let alone attempt to stop it. In fact, the only elements that never seem to change are God and Truth.

Inside the organization I work for (GPS software applications), we’ve been undergoing a great deal of change lately. (In all honesty, it’s been the better part of the last two years, but that still counts as “lately”!) The old, slow, inflexible product is going away and is being replaced by the new, spry, blazing-fast latest-and-greatest. To add to the mix, several long-time employees have left recently and/or are being replaced by new ones, and at times it seems that everything is up in the air…changing. Our priorities seem to be changing not only day-by-day at times, but hour-by-hour. Build this, fix that, oops — put out that fire; lather, rinse, repeat!

In the midst of all these changes and ever-shifting priorities occurring at my office, there are plenty of new opportunities and responsibilities. As one of the more senior members of the team, a new responsibility that’s recently been added to my plate is that of mentoring. Often it comes about in the form of training and assisting other team members about how something works, how to do this or that in our very complex system, or where to find a particular piece of code that they’re trying to hunt down and how it works. However, the other form of mentoring that requires more pragmatism and effort is in training others who are new to the system and our development processes. Generally speaking, the more complex a system is, the more training and/or mentoring that’s required to bring someone up to speed. And our system is rather complex (to say the least!).

To add to the mix, I’m fortunate enough to be sitting on both sides of the mentoring fence at the same time. While mentoring others new to things that I’m quite familiar with, I’m simultaneously being mentored in other areas that I don’t really have a clue about. It seems that specialization is both a blessing and a curse! Being mentored has been a rather humbling experience for me at times because familiarity breeds contempt — and pride. It’s only when I’m exposed to something radically different than what I’m familiar with do I realize that I’m not nearly as smart as I thought. Also, I’m more of a “git-r-dun!” guy with most development tasks instead of a “big-picture” guy who likes to step back and understand all the various pieces and how they all work together (or should work together) before jumping in with both feet. One approach is faster yet more short-term while the other is slower and more long-term.

Since we’ve practically been in fire-fighting mode for nearly the last two years, it’s not always easy to carve out time for mentoring and passing on skills to others; it’s often much easier (and faster!) to just do things yourself. However, that’s a recipe for disaster, particularly when time and resources are stretched thin enough as it is. In a growing organization, it seems the most important element is growing the leadership base and diversifying skill-sets rather than simply getting things done. Yet growing leadership and skill-sets doesn’t usually contribute to the bottom-line of producing and delivering new features faster (at least on paper). That means we’re somewhat forced to be somewhat sneaky about how we grow and diversify our skills: pair-programming.

Pair-programming is where two developers tackle a feature/task instead of simultaneously working on two (or more) separately. While it may seem inefficient at first (two developers doing the work of one), we tend to get more done faster and with higher quality than we would otherwise. Developers tend to have different skills and talents and we often end up learning from each other almost by proximity, particularly when the pressure’s on and the deadline was yesterday (or last week!). We also often pair up when one developer needs to come up to speed with a new part of the system that the other is familiar with, which naturally leads mentoring. While everyone may agree that a mentoring environment fosters creativity and ingenuity, it’s still often an uphill battle to create that type of environment and then maintain it over time.

As I’m learning to mentor others, I’m finding that I look to my own mentors and consider their approach and then try to emulate them as best I can. Our tech-lead who’s been the go-to guy for the last couple years is probably the one I look up to the most in this area. He often pushes and prods us into doing the right thing — even though it may take much longer — when often we just want it to be over with so we can get back to doing the next task on the board. He HATES duplicated code because it’s bad design, indicative of short-cuts and sloppiness, and often makes it his mission (and therefore ours) to rip out as much of it as possible. He consistently returns to software fundamentals and principles such as Separation of Concerns, Single Responsibility, Knows-About/Least Knowledge, etc. When I observe him designing or explaining something, it’s rare that those three elements aren’t involved right from the beginning.

Not only does mentoring help those who are being mentored, it helps those doing the mentoring. In learning new technologies and patterns, mentoring helps reinforce whatever is being taught. With all the new open-source frameworks and patterns, whatever isn’t used is quickly lost. In fact, I’m finding that I retain new skills and technology longer and have a deeper, more fundamental understanding when I’m passing on that knowledge or concepts to another. Though using those skills often helps, there’s no substitute for teaching and explaining them to someone else. The “Learn, Use, Teach, Repeat” and “See one, Do one, Teach one” principles for both learning and mentoring have been a great way to make sure new skills aren’t lost soon after whatever task I’m working on is completed.

l-d-t-l-cycleIn “Learn, Do, Teach, Lead”, the “Learn” phase is where knowledge or a skill is acquired, which moves directly into the “Do” phase. Often it’s rather easy to understand the abstract concepts of something new, but until the “Do” action occurs, much of it’s still quite conceptual rather than practical. The “Do” phase is where the rubber meets the road and where the “Learn” phase is reinforced and retained. Once the “Do” phase occurs, it’s best to then move into the “Teach” phase to reinforce both the “Learn” phase and the “Do” phase. At the intersection of all three phases is “Lead” — and the more often the cycle is repeated, the stronger the “Lead” intersection of the diagram grows.

However, this cycle shouldn’t just happen once, but frequently repeated, with new skills and concepts continually being acquired, put to practical use, and then taught and retaught. In apprenticeship/journeymen roles and also parenting, this cycle comes naturally, particularly with older children who often teach anything (and everything!) to their younger siblings. Curiously, modern classrooms tend to leave out the “Teach” phase, which causes information to not be retained for very long and also contributes to a lack of leadership skills. In my opinion, our shortage of leaders and teachers is directly correlated to the lack of the “Teach” step in many of our educational institutions.

The responsibility of both mentoring and being mentored is also a biblical principle, especially in the New Testament. For just over three years, Jesus mentored His disciples, eating, drinking, living, walking, teaching, and ministering with them. After He reappeared to them after His resurrection, He told them to go and do likewise, making disciples just as He had done with them. The Great Commission isn’t one of merely preaching and proclaiming, but of teaching and mentoring — investing in others and training them in the ways of the God’s kingdom and how we should be loving and treating others here on earth.

Throughout the New Testament, we are admonished to not only teach our children and lead our families, but pass on our knowledge of the Scriptures and God’s love to those around us. Who can we mentor today? Who can we be mentored by today? Who do we know that needs to hear of God’s love, grace, and mercy?

“Give instruction to a wise man and he will be still wiser, Teach a righteous man and he will increase his learning.” — Proverbs 9:9

Advertisements

About Chris Hambleton

Chris resides in Denver, Colorado, where he is employed as a software developer and consultant. He has authored more than a dozen books, as well as developed several websites, software applications, and written software-related articles. His other interests include traveling, hiking, running, studying the Bible, reading American history and politics, and literally devouring good fiction books. Recently, he has been learning to enjoy classical music, playing the piano, and learning Hebrew.
This entry was posted in Character, New Beginnings, Personal, Refactoring, Software, Work and tagged , , , , , , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s