On 12th November last year I received an email via PaperCall with the following words which grabbed my attention:
Congratulations Keith Pitty!
We are really excited to let you know that your talk, “What were they thinking?”, has been selected for RubyConf AU 2019.
Can you please confirm that you will be able to bring yourself and your talk by visiting the link below?
I immediately felt a mixture of excitement and panic. Having submitted a proposal at the last minute I was now faced with the prospect of converting my abstract into a 20 minute talk that did it justice and provided value to the audience.
I accepted the challenge and earlier this month presented at RubyConf AU in Melbourne!
The genesis of my talk was many years of thinking about experiences I have had with codebases. Legacy code that hasn’t been loved can result in painful experiences for future developers, frustration for users not to mention expensive consequences for owners.
Thanks to John Carney for this photo of me presenting.
Software is liable to decay over time unless it is nurtured. Such nurturing should include such things as refactoring to improve internal design, which implies automated testing, sufficient up-front design to increase the likelihood of a successful outcome, healthy peer review, a well documented git history and load testing.
All of this requires discipline. Sometimes it also requires negotiation with stakeholders.
An aspect that can involve both discipline and negotiation with stakeholders is planning and carrying out maintenance such as installing security patches and keeping software on which your applications depend up to date.
Whilst attention to the detail of planned maintenance is something that many developers can do well, negotiating with business owners to give it sufficient priority is a different challenge altogether.
Before delving into the challenges to communicate better, I touched on a couple of more philosophical topics which I considered relevant to the topic. Firstly I referred to what is sometimes described as “continuous flow”. I then suggested that it was time to reflect on how a mature consideration of the Agile approach could better serve us.
In my experience it can be difficult to persuade some business owners of the vital importance of the sort of activities that are essential to keep legacy codebase in a healthy state so that it survives in a form that enables it to support evolving needs.
The challenge to practice becoming more persuasive comprised a large part of the second half of my talk.
Once I had given my talk I was delighted at the positive feedback I received in person, whether it was from other speakers, former colleagues or new Ruby acquaintances. By the way, there were many inspiring talks at the conference so if you weren’t there I encourage you to watch them.
When I looked at Twitter I was humbled to see lovely feedback such as the following from Mel.
I’m keen to hear further reactions, especially from those who weren’t able to be in Melbourne for the conference. We were so lucky that the organisers engaged Next Day Video who in fact made the videos of the talks available on the same day!
So, if you’d like to get in touch and give me your take on my talk, please feel free to do so either via this site or Twitter.
Finally, a big thank you to all who made my experience at RubyConf AU 2019 so rewarding: those who selected the talk, my family for listening to me practice, the organisers, the lovely MCs, the audience and especially those who were kind and thoughtful enough to discuss my talk with me afterwards.
I’ve been thinking about Jerry Weinberg’s writing over the last few days, since his passing moved many including myself to words in his honour.
His words inspired me.
I know that I’ve dipped into the pages of The Secrets of Consulting many times over the years. I should probably, in the near future, take time to refresh my memory of the excellent advice that I know that tome contains. And I know there are many other books of Jerry’s that are worth reading or re-reading.
However, of all Jerry’s writing, there is one book that stands out to me. I was moved to write about it back in 2007 in a now defunct blog. Fortunately I have an extract of the text.
I introduced my post with a a reference to a picture of a beautiful stone wall in my back yard. Whilst I’ve lost the original photo, here is a fresh one of the same wall:
And here’s what I wrote:
What a beautiful stone wall! My family is now lucky enough to have this wall in our back yard. The bloke who built it is obviously a master of his craft.
What does our wall have to do with writing? The answer is to be found in Weinberg on Writing, a thought-provoking book about how to write using the metaphor of building a fieldstone wall.
Jerry Weinberg addresses the problem of writer’s block by showing how metaphorical stones can be continually collected. Each stone may or may not end up as part of a published work. The process of collecting stones typically contributes to ongoing work on a number of potential finished books, articles, reports or even blog entries. The trick is to always be ready to write. Carry a pen and notebook everywhere so that ideas can be readily captured. Later on the stones can be organised, perhaps eventually being crafted together in a finished wall to be admired. Or perhaps not. Stones may be thrown away during the editing process.
I think the Fieldstone Method employs a useful metaphor that keeps the writer productive. Of the many lessons in this book worth heeding my favourite is Jerry’s first: “Never attempt to write something you don’t care about”. After all, a fine stone wall is built by a master craftsman with passion. Writing should be similar.
Although I never met Jerry, that’s the lasting impression I have of him. Passion poured from the pages he wrote.
The software development community is very fortunate that Jerry has left such a wonderful written legacy. If you have a thirst for learning from a pioneer of a people-oriented approach to programming about topics ranging from consulting, becoming a technical leader, systems thinking, testing, exploring requirements and, of course, writing, amongst many others, I thoroughly recommend reading his books.
Jerry may be gone but his words will live on.
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!
For the cast of thousands who hang off every word that I write on this site I am delighted to announce that I will be commencing a new role in the new year!
In January I will be starting work as a Senior Software Developer with Birdsnest, an online retailing company based in Cooma, NSW.
Whilst I will be based at my home office on the NSW Central Coast, I will be making regular visits to Cooma to work with staff on-site, especially the software development team.
Birdsnest is an inspiring company that offers a unique online shopping experience.
I look forward to working with the development team to help them build upon their successes to date.
The new year promises to bring new challenges.
Yes, having contributed to The Conversation’s development team as a contractor since June 2015, I will be moving on in late January, or earlier if I am able to provide fair notice.
I’ve very much enjoyed the opportunity to work with The Conversation over the last two and a half years and will have fond memories of collaborating with development colleagues as well as editors of the various editions around the globe.