How to Succeed with Technical Coaching
Software Developers are constantly shifting between activities. It might all be ‘coding’ but when you look more closely there are hundreds of distinct activities and decisions being taken about what to do next. The picture above is of ‘bricks in the wall’ – I’ve put named practices, tools and heuristics on each brick.
These are ‘microskills’ – most are rather small and applicable only in a limited range of circumstances. It takes skill to execute them well and good judgement to decide when each one is applicable. If you watch someone doing software development they will be using many of these practices on a daily or hourly basis, switching between them according to the situation they find themselves in – the state of the code and the current goal. If the developer is weak in any one of these skills then it might not matter, unless they face a particular set of circumstances where they would have needed it. Then they get stuck or just do something badly.
I picked the microskills in the wall above as representative of ones you use while you’re doing Test-Driven Development. The full list would be a lot longer. I recently looked through the contents pages of four classic books by well known authors – Kent Beck, Martin Fowler, Michael Feathers and Steve Freeman. I was able to compile a list of about 200 named microskills just by looking through the chapter and section headings. (I decided not to include the full list in this post. I’m currently working with a video editor to make an animation of it for an upcoming video for the Modern Software Engineering channel, I’ll update the post with a link to it when it comes out.)
Looking at a list of 200 microskills can feel pretty overwhelming. How will anyone ever learn TDD? Reading all 4 books and studying them enough to learn every one of these skills would be a huge effort and most programmers don’t read any books! Luckily, not all microskills are equally important. That’s why some of the bricks in the picture above are coloured orange – what I wanted to draw is something more like a series of arches (but my artistic ability wasn’t up to it!).
In an arch like the one in this picture, the ‘keystone’ is the one in the center at the top, without which the whole arch would collapse.
Some of the microskills are like that keystone brick. If an individual developer lacks skill with those specifically, they will struggle to succeed with a whole aspect of programming. In the context of Test-Driven Development, one important behaviour is being able to write the unit test before the implementation exists. That’s one of the arches in the programming skill wall. The specific microskill that corresponds to the keystone in the arch is ‘clarify intent’. (The ability to express succinctly in words, one small slice of the desired behaviour of the code, before that code exists.) If you can learn that microskill, then other related skills are easier to identify and adopt, and eventually the whole arch will come together.
You don’t need to feel overwhelmed then by the sheer number of microskills that are needed for programming and TDD in particular. If we focus on learning keystone behaviours then we won’t necessarily need to be taught every brick in the wall of programming skill. As a technical coach, that is great news. I can focus on teaching the keystones and supporting developers as they acquire the surrounding bricks.
This idea of ‘keystone behaviours’ comes from the psychology of behaviour and habits. This podcast interviews Professor Ben Gardner, a professor of psychology at the University of Surry: “How to build a better breakfast habit“. It is about using breakfast as a keystone behaviour for gaining healthier eating habits overall. The idea is to use a small change in behaviour (different choices at breakfast) to enable ripple effects through the day and healthier choices at other times.
The parallel for software development is that if you learn the keystone behaviour ‘clarify intent’ then you become able to modify other behaviours too – listen to the design feedback from writing the test and make your overall design more testable. That should lead to higher quality code and better test coverage.
Marian Hartman‘s Green Path model is an approach for teaching practical skills, like programming. This picture shows a high level outline of the method. Learners move through the green blocks in a predictable sequence and each transition has particular characteristics and challenges. Each time you move further to the right, you increase your proficiency or fluency when executing the behaviour. Each time you move up, you gain theoretical understanding and increased ability to analyze the behaviour and in what situations to use it.
The six labels from ‘Familiarity’ to ‘Unconscious Competence’ are the names for distinct skill levels. I made this video “Why Some Developers Advance Faster – How Coding Skill Acquisition Happens” describing them. The Green path adds another dimension and points out that you can’t go on increasing practical skills indefinitely purely by practicing them – higher levels won’t be accessible to you until you have gained some theoretical understanding too. It also points out that theoretical understanding must be preceded by a lot of concrete practice. You can’t learn to code only by reading books.
The Green Path model works particularly well for programming skills according to the reports of Arlo Belshee, an experienced technical coach and also life parter of Marian Hartman. Belshee has been a technical coach for many years and I’ve admired his work for some time, in particular his ‘Naming as a Process‘ for legacy code improvement
Belshee has recently begun using the Green Path model to inform his work helping teams to adopt practices like TDD and handle legacy code. He says it has been working extremely well, and I don’t think he’s just saying that to support his partner Marian 🙂
I would like to be able to replicate some of Belshee’s successes and have started to study the Green Path. I have been applying this model in my work as a technical coach for a few months now and so far I have found it really helpful. It gives me a way to focus in on the keystone skills that will have the most impact, and to structure my teaching and coaching to enable teams to adopt these skills more easily.
The microskills theory of programming describes how we work and partly why bad code exists. It’s a skill issue. Identifying keystone behaviours lets us focus our efforts and build whole new areas of competence more effectively. The Green Path model helps technical coaches to focus on those keystones and tailor their approach to the level their learners are at. The whole picture together looks like more effective ways to teach programming, speed adoption of TDD, and raise code quality.
I have high hopes of incorporating these three concepts explicitly into the next iteration of the Samman method. It will be the focus of my work with the Samman Society for the next few months at least, probably longer. Together with the trusted and expert coaches in the society I expect we will be able to update and improve the materials and advice coming out of the society so that more coaches and developers can benefit. Happy Coding!
If you’d like to stay in touch with our work through this period and beyond, I suggest signing up for our newsletter.
