ThoughtWorks University: A refactoring dojo
I facilitated a refactoring session today at ThoughtWorks University where we spent the morning refactoring our way through one of the problems the grads had to work on as part of the pre coursework.
The previous version of this session has been more structured, whereby one of the trainers worked solo at the keyboard and took suggestions from the group about which refactoring to cover next.
There are a certain number of refactorings that the session aims to introduce and the trainer would have practiced beforehand so they could make these fairly flawlessly.
I’m not really a fan of that style of session so we refactored code which the grads were quite familiar with and I was unfamiliar with.
We ended up doing 3x45 minute stints in the style of a randori coding dojo and we had one person keeping a list of the potential refactorings on the whiteboard.
The 3 stints went like this:
-
Me always at the keyboard, people pairing with me and Frankie facilitating/controlling the whiteboard.
-
Two grads pairing and me facilitating the session
-
Two grads pairing and one grad facilitating the session.
We’re slowly trying to encourage the idea of the grads owning the way they learn so this was a step on the way to that.
These were some of the learnings from covering a topic in this way:
-
Frankie noticed that I was dominating the keyboard in round 1 so we decided that the grads could pair with each other for the remainder. We’d already gone through a lot of the main refactorings in that 1st round so it made sense to make this change.
-
We switched the order of people before the 3rd round after some feedback so that people would have the opportunity to pair with different people than they had in the 2nd round.
-
In the first round I was a bit too focused on teaching keyboard shortcuts to the people I was pairing with. Frankie pointed out that it’s more useful to learn the refactoring first and then once you have that concept then teach the shortcuts. By the 3rd round the grads were teaching each other the shortcuts which I thought was pretty cool.
-
We didn’t get to cover as many different refactorings as we would have in a more structured session but we’ll get to those in the next few weeks when we’re coding on the project so I don’t think it’ll be too much of a problem.
-
Since this was a problem everyone had worked on previously several of the people had already done some of the refactorings in their own solution. Therefore parts of the session weren’t a big learning experience for those people. That’s been a bit of a theme so far - working out how to cater for all skill/experience levels seems a difficult problem to solve!
Overall I was quite impressed with how much we managed to refactor the code in the amount of time we coded for.
The only thing I’m a bit unsure about with the randori style is that it leaves a lot of people observing for big chunks of time.
The Kake/UberDojo format is one that might be more suitable but that would mean splitting up the group which wasn’t something we’d considered.
About the author
I'm currently working on short form content at ClickHouse. I publish short 5 minute videos showing how to solve data problems on YouTube @LearnDataWithMark. I previously worked on graph analytics at Neo4j, where I also co-authored the O'Reilly Graph Algorithms Book with Amy Hodler.