Technical coaching is all about helping developers grow by finding ways to increase their technical excellence and to work with softer skills, like the ability to be able to communicate and listen to other developers, argued Tobias Modig at GrowIT 2018. The softer part is closely connected to traditional coaching but it also comes with a tech twist.

Modig stated that by improving the ability to talk code and solutions, and by finding the answers to questions like "how do you explain a solution in a way that everyone understands?" and "at which technical abstraction level am I able to speak to the team?", we can reduce a lot of frustration and be much more efficient when working together.

His two favorite approaches are mentoring and mob programming coding dojos. He also mentioned pair programming, book circles, watching presentations, "traditional" education and brown bag lunches as other ways of doing tech coaching.

Tech coaching should be a continuous and returning process, argued Modig. "I still haven´t seen a developer that is fully trained so in the perfect world mentoring would be something all developers had the opportunity to do on a regular basis," he said.

Tobias Modig, a software development consultant at Citerus, gave a talk about technical coaching at GrowIT 2018. InfoQ spoke with Modig after his talk.

InfoQ: How do you define technical coaching?

Tobias Modig: Does "it" help developers to become awesome? Then I would call "it" technical coaching. This might be a pretty wide definition but I think we should focus on the goal here. My first goal when helping more junior developers is to make them familiar with the twelve principles of Extreme Programming and make those principles a natural part of their developer’s life. Kent Beck once stated, "I’m not a great programmer; I’m just a good programmer with great habits." And I really believe that creating those great habits is a very good place to start.

InfoQ: What makes technical coaching so important?

Modig: With our digital society where there is software everywhere, the quality and maintainability of code is actually a matter of life and death. During the years, I have consulted at more than 50 different customers in six countries and I am sorry to say that very few of those companies take technical coaching seriously enough. There is so much focus on releasing features and so little focus on developing the skills of the employees. Nevertheless, the success factor of the development teams in those companies has more or less always been strongly connected to the skill of the developers so it is a real paradox that the companies do not invest more in their technical talents. If I look at the early years of my own career, it was a mess. I had no idea about basic things like version control, design patterns or the SOLID principles. Even worse, there was no one who guided me so I kept on writing really crappy code for years and I can assure you. I do not want a 25-year-old version of myself to write the software of my upcoming pacemaker. Actually, it was not until I stumbled over the Pragmatic Programmer book that I came to the insight about how little I knew and what a bad developer I was. When I talk to people today I still hear way too many who share my own story. That is 20 years with very little progress and that makes me sad.

InfoQ: How does technical coaching look in daily work?

Modig: During the years I have had my own mentors, and what I really have appreciated is when we have worked closely together. By doing so we have constantly built trust for each other and that’s when the real magic starts to happen. So what I recommend is that the mentor works together with the mentee, for instance, one day a week over a period of time. And with work together, I mean that they should spend all the time together. If the mentee has a meeting, the mentor should join, they should have lunch together and they should, of course, pair program together as much as possible. The mentor needs to be present so instant feedback always can be provided. Remember that information exchange is vital here so it should be flowing in both directions.

InfoQ: How can we do technical coaching through mob programming?

Modig: I came across this some years ago when I met Llewellyn Falco over lunch in Helsinki. These are very much his ideas that I am following, and they usually work really well. So start by taking a traditional mob programming setup like Woody Zuill usually describes it, "all the brilliant people, working on the same thing, at the same time, in the same space, and at the same computer", combine it with the driver/navigator pattern, and add a coach who facilitates the work and focuses on the learning part instead of building things. That’s more or less all it takes. I can see a few key points when it comes to technical coaching through mob programming coding dojos, and the first one is the purpose. This differs quite a lot from traditional mob programming. The purpose here is to learn so it is totally fine to end a coaching session without creating anything and without committing any code, as long as most of the participants have learned something during the session. Initially, I also suggest using one pinpointed navigator instead of using the whole mob as navigators. This is then rotated with the same pace as the driver rotation which gives everyone in the mob the chance to practice communication at their own pace. The drawback is of course to that we miss the natural discussions that come with a mob, but I think that the benefit of giving everyone a chance to talk is greater than the drawback. We can then slowly increase the communication by adding ways for everyone to add input. For instance, raising your hand if you want to help or use some kind of "speaking token" which you need to possess before you are allowed to speak. After some sessions we can usually remove all speaking limitations and still have a good discussion climate. Setting the stage is another important key. It is hard to hear people discuss and maybe even criticize what you have created. Therefore we must really make sure that everyone who is participating understands that we are there to learn from each other. What has helped me a lot is to end each coaching session with a short mini retro. It doesn’t need to be something fancy, but just by answering a few simple questions, like "what have we learned today?", "what was good?", "what was bad?" and "what should we do differently the next time?", we can really make sure that these sessions turn in the right direction.

InfoQ: If InfoQ readers want to learn more about technical coaching, where can they go?

Modig: Well, there are more or less two parts to this. The first part is to learn about the technical skills, and here there are easy to find good sources of knowledge. There is a whole lot of good reading in books and blogs, tons of Twitter accounts to follow and dozens of videos to watch. Just google well-known developers like Kent Beck, Uncle Bob, Martin Fowler, David Thomas, and Michael Feathers and take it from there. The second part, the learning about the coaching part, is much harder. Of course, much about "traditional" coaching is applicable here as well, but not that much has been written about technical coaching. Luckily, I believe that most of us have done it in one way or another. For instance, when introducing a more junior colleague. So just by starting to talk about it, we can learn a lot from each other. If we also start with technical coaching and doing those mini retros, we will learn just by practice, experimenting and adapting.

In the InfoQ article coaching technical practices Pedro Santos shared his experiences from coaching developers to improve their technical practices.