Refactoring is one of the most impactful skills I teach in my work as a Samman Technical Coach. I do a lot of Learning Hour training sessions to teach particular refactorings. Sometimes these sessions go better than others, and until now I was improving them only through trial and error. Recently I learned about the Green Path from Marian Hartman which is really helping me to do better. In this article I’d like to examine the structure and purpose of learning hour sessions and explain how I am using the Green Path to improve learning experiences for the people I coach.
Learning Hour format
Learning Hours on Refactoring have a predictable format. I begin with a code review, showing an example with a particular design problem. Once everyone has understood the problem, I demonstrate a series of refactoring steps that addresses it, showing tool-supported shortcuts and safe manual steps that lead to a better design. Then I split the group into pairs and give them the same code example, asking them to improve the design in the same way as I demonstrated. At the end of the session we re-group and I usually ask people to note down some conclusions – what shortcuts they used, or what design problems they should watch out for that would prompt this refactoring.
Parrot Refactoring Kata
I have many exercises or code katas I use in my trainings. One favourite is Parrot. The basic idea is the code has a Repeated Switches code smell and you need to address it with a Conditional to Polymorphism refactoring. Before you do that though, it helps to do a Replace Constructor with Factory Function so you don’t break the tests when you introduce the subclasses.
I’ve noticed over some years of training sessions using Parrot that participant solutions vary a lot. In some cases people speed through the exercise and seem non-plussed. Was that it? They find it rather simple. In other cases people enthusiastically change the code but don’t seem to grasp the idea of using refactoring tools. They will hack their way towards the new design, breaking the compilation and/or tests in the meantime. Mostly though it’s somewhere in between. People try to use the tools the same way I did, but often forget some steps or get stuck and break the tests without realizing. I can go around and help to try to get people back on track but it’s hard, particularly if the group is larger and many pairs are struggling. As a trainer I have always felt I should be able to do better.
Recently, learning about Marian Hartman’s Green Path model has really helped me to understand what is going on and in particular how I can adapt my materials to the needs of the people I’m coaching. The Green Path is a model to explain the learning journey you go through as you acquire a practical skill like refactoring. The rest of this post is me sharing my current understanding of how I can get better results from the time I spend teaching and coaching.
Self-assessment
First though, as an experiment, I encourage you to go and watch one of the Parrot demo videos I’ve made, either Python, Java, or C#. After you watched it, judge which of these responses best matches your thoughts when I ask you to go and do the same thing yourself:
- Yes, I’ll do it. How do I find the refactoring menu?
- Give me a list of the refactorings and I think I can do that.
- Thanks for showing me a clear target design, I will work out the exact refactoring steps myself.
- This isn’t an interesting exercise. There is only one solution and you already showed it to me.
Each of these responses maps to a level of proficiency on the Green Path. Self-assessment is notoriously difficult, probably because you don’t know what you don’t know, but I’m expecting most of my readers to be technical coaches and fairly advanced with refactoring skills already. If you’re coaching a team, these are the kinds of responses you can look out for to make a quick assessment.
If I can work out where my learners are on the Green Path then I can adapt the session to meet their current learning needs. In one learning hour I can focus on one microskill within the broader Refactoring skillset, and aim to move the learners a little way along the Green Path. (I wrote a previous post about the concept of microskills in programming).
Let me paint a picture of what each step looks like and how I can deliver learning hours in a way that will help people the most.
Inspired
This is the first step on the Green Path. At and before this stage you have only the vaguest concept of what refactoring is or why you might want to learn it. The first part of the learning hour, where I get people to review a code design problem, aims to get them to the Inspired. I want people to understand the design problem and be open to trying this solution “Refactoring”. They don’t know what that is yet though. Hence the response “Yes, I’ll do it. How do I find the refactoring menu?”. They are willing but don’t know what to do.
At this point if I just send them off to do the refactoring exercise with no further instruction, they will perhaps make an attempt but it will look nothing like actual refactoring. What you need to do is channel the new-found enthusiasm to learn refactoring into something more concrete, which happens at the next stage.
Simple Robot
The refactoring demo in the next part of the learning hour should enable people to get from Inspired to Simple Robot. You give people a list of the steps, or a “recipe” as Hartman calls it, that they can follow exactly to achieve a result. You give clear instructions so they can repeat what you did in the demo. You probably can’t ask them to go on and do additional steps or another exercise variant though. As soon as the situation calls for judgement or variation of the steps, someone at Simple Robot will get stuck.
On the occasions where people in my learning hours have totally failed to do the exercise after the demo, it’s usually been because my recipe was not clear or detailed enough for them to follow, or the recipe was too long and complicated and they couldn’t remember it. People at Simple Robot need really clear instructions, hence the response above “Give me a list of the refactorings and I think I can do that”.
Another failure mode I’ve encountered is when people weren’t sufficiently Inspired before I showed the recipe. I’ve had people reject the whole notion of using refactoring tools out of hand and spend the exercise time just hacking the way they did before, ignoring the demo. If this happens I need to work harder in the next learning hour on the first part, getting them to Inspired.
Smart Robot
The upshift to Smart Robot means the learner starts to understand what refactoring actually is – it’s not just changing code or making it look prettier. The insight is that you change design safely, often using tools, without breaking the code in the meantime. It’s important to note though that this insight is not available until people have actually done some refactoring. It’s through the concrete practice working with the code and refactoring tools that people are able to grasp this. They don’t gain new practical skills in this transition – as with Simple Robot they will still get stuck if refactoring instructions are not clear enough.
In the Conclusions part of the learning hour I give people an opportunity to reflect on their experiences and my hope is that they will start to gain insight and level up to Smart Robot. It often takes several sessions though.
Solo
Once people have grasped the idea of refactoring and have seen a few different recipes, they can begin to invent their own sequences of refactoring steps. People can make the transition to Solo over a series of several learning hours with different refactoring exercises. At this stage they can also start doing refactoring in their production code, and may make progress without the coach, although they will easily get stuck if they need refactoring steps they haven’t used before.
In a learning hour, people at Solo level almost don’t need a demo at all. It should be enough to outline the target design, and perhaps point out some refactoring menu items they should try to use. To get better at refactoring, they need to practice finding their own path from A to B. In the responses above I can recognize Solo by people saying “The target design is clear, I will work out the exact refactoring steps myself”.
People at this level benefit from a much briefer learning hour demo than those at the Simple Robot stage. If I give too much detail in the sequence of steps, I remove the interesting challenge for them. However, Simple Robot people will be totally lost and likely fail the exercise if I only give a brief demo.
The secret to success in this situation is to realize you have a group of mixed levels, and take advantage of that when you allocate the pairs for the exercise. I pair up Solo people with their less experienced colleagues. Then I rely on them to come up with a recipe and teach it to their pair. This is the kind of thing I’ve seen happen spontaneously at Code Retreat and Coding Dojo events. When you have a group of mixed experience working in pairs, it can actually work really well for everyone. Being forced to explain the steps they are taking will help Solo to make the upshift to Detective. When the less experienced colleague takes the keyboard, their Solo level pair can give them 1-1 explanations and feedback as they go through the recipe.
Detective
This is another upshift in understanding. At the Detective level people start to grasp the potential of refactoring to improve design safely in the large. They can see how a larger design change can be achieved in a sequence of small, safe steps. Importantly, this understanding doesn’t happen until they have the practical experience of actually doing just that. In Solo they have become proficient at taking a design from A to B without breaking anything. The upshift to Detective is where you really grasp the significance of that and can see the new opportunities that open up.
At this stage though the proficiency is still the same as for Solo – if people can picture a new design, they can invent their own path of refactoring steps to get there safely. In a learning hour, they will still benefit from practicing on additional code katas to widen the repertoire of refactoring steps they know. However, returns are diminishing as they already know a great many.
Rigid Planner, Fluid Planner
Once people have grasped the potential of refactoring as a tactic to improve design in the large, they will try to understand the limits of what’s possible. At this stage people know many refactoring sequences, the challenge then becomes how to decide on a good target design. If they identify a good target, a Rigid Planner will be able to come up with the steps to get there safely. As Rigid Planner moves into Fluid Planner, it becomes less important to begin with a good target design in mind. A Fluid Planner will be able to adjust and re-plan as soon as they identify a better target design.
This is where it starts to get hard to hold learning hours that will actually help. Basically all the code katas I use are too small to have the variety of target designs that people need for practice at this level. Hence the response “This isn’t an interesting exercise. There is only one solution and you already showed it to me.” This is where the other part of the Samman method – Ensemble – starts to become even more important. People at the Planner level need mentoring and coaching in production code where the complexity is high and there are many possible designs to head for.
If I’m doing a learning hour with other coaches then probably all of them will be at this level or above with their refactoring skills. In that case though, the focus is on train-the-trainer – they want to see my demo so they can do something similar with the groups they are coaching. We can have a good discussion about which refactoring microskills to introduce in which order and what exercises they recommend. This is the basis of the Samman Society – we share our materials so we can all get better at teaching this stuff.
Mapper, Expert
From Rigid and Fluid Planner, the next upshift is to Mapper. At this stage you start to understand the strategic potential of refactoring to transform legacy code and make a difference across whole product lines and systems. It’s the architect’s viewpoint. Again, you don’t get to this understanding purely by reading books – it happens through actual experience refactoring in real, hairy, difficult production code and from real life successes and failures. The upshift to Mapper will happen in conversation with other technical coaches or architects, or maybe when you re-read some books you didn’t properly grasp when you first read them with a Detective or Smart Robot level of understanding.
What characterises the Expert level is you perhaps don’t think in terms of refactoring steps or plans any more, you start to see design patterns, structures and transformations. Learning hours are not going to help people at these levels – the experiences that get you to expert are to be found in genuine legacy code with real stakes and career-changing outcomes.
Where to go from here
If you’re a coach teaching Refactoring, I hope this post will help you to design better learning experiences. If on the other hand, you are not yet a Refactoring expert, perhaps this post has inspired you to want to get some formal instruction from someone who understands the Green Path. I have good news for you! I and others in the Samman Society are in the process of adopting the Green Path to improve our coaching practice, materials and training.
I have a self-paced video training course that can show you what refactoring is – reach Inspired – and provides detailed demos you can follow to get to Simple Robot. The course also comes with a discussion forum where you could interact with other learners and hopefully gain the understanding at the Smart Robot level. Alternatively you could get a colleague to do the course at the same time as you, and compare notes. Afterwards you should be equipped to tackle a wide range of additional code katas from my collection at the Solo level.
If you can persuade your whole team to get on board, I recommend hiring a technical coach using the Samman method to work with you. They will be able to tailor learning hours for your situation and mentor you refactoring in your real production code too. This is a list of Samman society members, many are available for short-term contracts. For larger organizations, I recommend starting a Technical Coaching Programme.
Happy Coding!
I would like to thank Marian Hartman and Arlo Belshee for many useful discussions about the Green Path and Refactoring skills.
