Why would I choose to write about mentoring?
I guess it’s a topic that I’ve pondered over the years, ever since my first job out of university. During the couple of years I worked at TNT I didn’t benefit from any formal mentoring. However, when I think of who had a big impact on my learning on the job, there were certainly a couple of people who immediately come to mind.
But it was when I arrived at IBM that I was struck by the fact that everyone in the team was allocated an adviser. So I knew that, if I ever had any questions about anything, I could approach Rod, my adviser. I knew he had a wealth of experience and found his help invaluable. What impressed me even more was the fact that the company considered mentoring important enough to implement such a scheme.
That was back in 1986. Fast forward to 2018 and I’m in a very different situation, keenly aware of the need for young programmers with whom I work to have good mentoring.
So, several weeks ago, at RubyConf AU, when Alaina Kafkes challenged those in the audience of her talk about Tackling Technical Writing to publicly commit to writing about a particular topic, my response was:
And given that Sean was generous enough to say that he’d read what I had to say on this topic, it’s only fair that I put words to the screen and share my thoughts.
Before I dive into my thoughts about mentoring others, I think it pays to pause and consider the meaning of the word mentor. The dictionary on my Mac defines a mentor as:
An experienced and trusted adviser.
Now that we have that definition out of the way, let’s consider what it takes, in my experience, to be a good experienced and trusted adviser.
One thing that I consider to be vital when mentoring is to be aware of the right time to offer advice. As a parent I’ve come to learn that one has to be patient and wait for the right moment. Or, to borrow from another context, I love the quote from Jack Gibson, the Rugby League coach, who said:
“A good coach thinks twice and says nothing.”
In other words, try to cultivate a sense of recognising moments when your colleague is ready for advice. It’s important to allow them the time and space to try to figure things out for themselves. You’ll usually know when they’re ready for your advice. They’ll ask you a question!
On the other hand, there will be times when your colleague could use some advice but doesn’t ask for it. So make it clear that he or she is welcome to ask questions about anything.
And then wait.
It’s one thing to encourage your mentee to ask questions. However, to provide them with the basis to ask good questions that will help them learn, a framework will help.
What do I mean by a framework?
To begin with, something that provides structured learning. To be fair to your colleague, they’ll need training to help them be most effective at their work. Appropriate training will help the developer feel that they have ascended to a new level and give them confidence. That confidence should translate into a greater preparedness to attempt new tasks and, importantly, spark questions that will further improve understanding.
Also, it’s likely that different members of the team will have different strengths. Part of my envisioned framework is a skills matrix. For each skill there will be specialist mentors as well as a set of training resources.
In the early stages of implementing a mentoring program for a team, there may be a few gaps and imbalances in this matrix. For example, a skill that is important to the team may be Ruby Performance Optimisation. However, there may be nobody in the team that has sufficient strength in that skill to mentor others in the team. A next step to start filling that gap may be to identify some training resources, allocate one developer to complete that training and then become the mentor for that skill.
Continuing in this way, the skills matrix should start to take better shape. The aim should be to manage its evolution so that there is an even spread of mentors across the skills that are important to the team.
Naturally we all differ. We gravitate towards different skills. We think differently. We have different needs.
So, in my perfect mentoring world, the needs of every individual should be provided for by a mentoring program that is fine-tuned and continuously adapted for that person. In practice this may not always be possible to the ideal degree. However, I think it is worth striving for.
Perhaps this point is obvious.
However, I think it’s worth stating explicitly. Whether it’s during the process of creating and maintaining a mentoring framework, or in the act of mentoring, it pays to put oneself in the shoes of the other.
What are they keen to learn? What do they think they need to learn in order to do their job better? What do you think they need to learn in order to do their job better?
It pays to explore these questions in an open manner.
Working as a pair, where one developer is a mentor and the other is more focussed on learning, can be an effective way of enabling a junior developer to grow. Whilst in general a more typical pair programming approach would involve two developers who are on a more or less even footing, switching the driver and navigator roles, a mentor/mentee pair offers an effective learning experience.
Having said that, there is a caveat. When there is a marked difference in skill levels, pair programming can be intensive and tiring, especially for the mentor. So it is important to be aware of this and provide sufficient breaks between pairing sessions. Ideally, as Ryan Bigg emphasised in his talk about hiring juniors at the recent RubyConf AU, a task that can be completed within two to three days is a good choice for this style of pairing.
As I alluded to previously, it’s important to consider the point of view of the person you are teaching. It’s not going to be surprising for them to feel self-conscious, even overwhelmed at times. So, as a caring mentor, ensure that there will be regular opportunities to catch up with your colleague in a one-on-one context.
I’m reminded about a coaching context again. When you’re coaching a team or a group, it pays to offer praise in public. It makes the recipient feel good. A little bit of an ego boost goes a long way.
On the other hand, if there’s a need for some constructive criticism, this is obviously best given in private. Nobody likes to be given negative feedback in front of their peers.
When you’re a younger worker, learning your craft, it shouldn’t be difficult to identify trusted advisers. However, as one grows older, mentors aren’t as easy to identify. I know that from experience.
And I have to admit that in recent years I have struggled to find a single person who I can look to for advice as my professional advisor. When I consider my experience over the last decade or so, it leads me to reflect on the various needs I have for advice.
Perhaps, in my case, as an older, experienced IT professional working within a small group of developers, I need to be more flexible in the way I seek advice.
My need for advice may stem from different sources.
In a more general, career sense, given that I’m closer to 60 years of age than 50, it’s likely that I need to look broadly to find someone who can give me appropriate career advice. Or, perhaps, I need to consider my own counsel. However, having said that, I think that’s probably a lazy response. Even though it will take more effort, I think it’s worth my while to keep searching for someone who I feel I can trust to give me good advice about how to approach the closing decade of my career as a software developer. Such an advisor will most likely outside my usual circle of professional colleagues.
Then again, my need for advice in a professional context may result from other sources. Perhaps I will need specific technical advice?
So I guess, in essence, I think I should be prepared to seek and accept advice from different mentors for different topics.
At any stage in one’s career I think it makes sense to be flexible about seeking specific advice. Obviously some people are going to have greater expertise in particular topics than others.
In my own case, I think it definitely makes sense to think of seeking advice in specific terms. Who has the best advice to offer about specific skills?
So, when I’m looking to be mentored, it probably makes sense to consider the same matrix that I proposed earlier.
One of the things I love about working as a software developer is the opportunity for learning and teaching.
It’s pretty rare to go through a career in software development without working as part of a development team. Every member of a team needs mentoring and most will be in a position to also help others in their team. Even if you spend much of your career as a freelance developer you will benefit from and be in a position to provide mentoring.
I hope this post has stimulated your thinking in some way about mentoring.
After all, when you think about it, it’s a two-way street. There are obviously going to be times when you need advice. So, it seems only fair that you be prepared to offer advice as well!
It is with a sense of poignancy that I begin this post.
Why do I find it poignant?
It is almost a year since a work colleague at Blake eLearning succumbed to depression. Rob was one of a kind. Loud, extroverted, a man who loved living life to the full. A born enthusiast and entertainer. I cannot imagine another member of a development team who managed to participate in a daily stand-up whilst riding his bicycle to work! But that was Rob. He was much loved by the team, but vulnerable.
Personally, I only really knew Rob through our work. Life gets busy. In retrospect, maybe I should have seen the warning signs and acted. But it’s easy to say that in hindsight. There is only so much each individual can do.
Rob’s passing struck a raw chord with me. After all, I had battled the scourge of mental illness since I was 17. I had known the depths of depression from which there seems no escape. Fortunately for me, I managed to emerge and am still here to tell the tale.
Maths was my pet subject at school. There were times when I topped the year with full marks. And that was in a selective high school, so I think I had some justification for feeling a modicum of pride.
However, in 1978, my life took an abrupt turn for the worse.
With the passing of time, there are things about this troubled period of my life about which I have a hazy memory. Doubtless, there are some aspects I have suppressed. But I have a very clear memory of an event which must have provoked my self-awareness. I distinctly recall sitting in a trial HSC Maths exam without the faintest idea of how to answer a single question. Me, hopelessly scoring zero in a Maths test. Clearly something was badly out of balance!
In retrospect, this was probably one of my earliest experiences of being aware that something was very wrong with the way my brain was behaving. I came to realise that during the previous few months I had been on a bizarre high. I was about to plunge into prolonged depression.
The year that was meant to be my final year at high school was an academic write-off.
Fortunately, I was able to muster enough resilience to fight through the mental trough and eventually finish high school the next year. Then I completed a Science degree which paved the way for my career as a software developer.
However, throughout the years since, I have had a number of relapses. Some have been more severe than others, obviously with serious potential undesirable consequences. Luckily I have had wonderful personal and professional support to help me back to normal life.
Depression obviously sucks, especially when it’s affecting you. There is an up-side though. Maybe sometimes it is an effort to think about experiences with depression in a “glass half-full” fashion, but it can help.
Reflecting on my experiences of Bipolar Disorder, I think I have gradually learned more about the nature of how mental illness affects me and how I can learn to be more aware of stressors that can potentially trigger episodes that I would prefer not to experience!
The relationship between software development and stress is something that, in the light of my own experience, I have been pondering. I know that many stressors can play a part in triggering an unwelcome episode of mental illness. The life of software development can contribute.
Of course, everyone has a different experience.
In my case, I have always had a penchant for patterns and for solving problems. And, by solving problems, I mean the sort that have a definitive answer. In high school and at university, essay writing was never my strong point. I much preferred the challenge of finding the answer to a Maths puzzle or solving a problem with a computer program.
More recently I have become aware that my bias towards solving problems may have an unhealthy aspect. Naturally, not all life’s challenges are best approached with a view to solving them as problems. Especially within a given period of time! But that is the nature of what much of my work has been for the last three decades. Solving problems within expected time-frames! Even in these more enlightened days of Agile software development, I find that I too often set myself unrealistic expectations to finish particular tasks before self-imposed deadlines. Old habits obviously die hard.
And that is just for software development tasks in my work.
I have realised that I am prone to subconsciously treat people problems as ones to be resolved within a certain timeframe. Maybe it also has to do with what I now see as the trap of the Getting Things Done approach.
Sure it helps us in life to get things done if they absolutely need to be done by a certain time. However, that’s not what matters most in life.
Building meaningful, trusting relationships with other people is more important to me, as is being healthy and, simply, having fun.
Does anyone still use Gantt Charts in software development projects? Probably.
Stress is commonly caused by unrealistic expectations. Anyone who has worked in software development for long knows how unpredictable an activity it is. So, what better way to subject developers to stress than set deadlines?
Personally, I find it much healthier to remind myself of one of my favourite Douglas Adams quotes:
I love deadlines. I like the whooshing sound they make as they fly by.
But appreciating the whooshing is something I need to work at.
Last year, in a post about happiness and programming, I alluded to something the Australian cartoonist Michael Leunig said about creative work:
Disillusionment precedes creativity.
That’s so true in programming. Anyone who has struggled for hours to try to solve a programming problem will understand this. Jamie Forrest’s expression of this aspect of the life of a software developer certainly struck a chord with others!
I guess the aim of this post has been to point out a few aspects of software development that I see as stress-related and consequently relevant to mental health. Undoubtedly I have just scratched the surface.
Whilst some of these factors are unavoidable, I am certain that others can be better managed and that, at the very least, better awareness of the risks inherent in software development can help produce better mental health outcomes.
As an example, let me cite the otherwise excellent book, The Healthy Programmer. Whilst this book focusses on exercise, posture, diet, caring for your eyes and many other important aspects of health as a programmer, any mention of mental health is conspicuously absent.
Thankfully, willingness to be open about mental health issues has come a long way since 1978. However, it is my belief that we still have a long way to go, especially in the IT industry.
Disclaimer: This article is based on my own life as a software developer who has experienced mental illness. Whilst I do hold a Bachelor of Science, I have no qualifications in psychology or medicine.