Apart from thinking ahead and finding collaborators for coaching and facilitation sessions early next year, this week has been mostly hands on coding.
I realise I miss weeks like this. There is something really satisfying in adding small features or fixing bugs and taking the opportunity to clean things up as I go along. Cleaning up can mean:
- Checking base image versions in docker files
- Bumping the package management version (e.g. bundler for ruby world)
- Curating dependency chains
- Getting the project ready for dependabot or renovate to help with dependancies
- Considering a rename or split for a method that does more than it used to
- DRY-ing up code where we now repeat ourselves more than twice
- Adding a couple of tests for edge cases
It’s important to think about a few things when you decide how much to do at once. It is possible to creep all the scope and get into an update that should be its own story.
- Do you have an automated test suite? what about build and integration pipelines?
- How far are dependancies behind? Will we cross into breaking changes territory?
- Is the project in sunset i.e. deprecated and mostly replaced
Doing some clean up as “small changes and often” really helps stay up to date. The longer we leave it, the more it piles up and the harder it is to face, and to tackle.
I first heard about “Code Scout Rules” or “Boy Scout Rules” in a talk given back in 2015 by Matt Cockayne and it’s still just as important as ever to leave the codebase better than you found it.
This week I had the pleasure of facilitating an ensemble programming session for a quartet. It was their first time working in this way but they’d heard it might be worth trying. The knowledge gaps between the participants could not have been larger: highly experienced through to apprentice.
On Tuesday, in the first 30 mins they learned
- the roles: typist, navigator, support (and facilitator)
- the timing: 5 minute rotations and a break every full cycle
- patience to talk to each other and really listen to each other
- slowing down to the slowest speed was good to share knowledge
After that they wanted to try it for a full morning.
After the morning session they said they could see the real value of using ensemble working to bring everyone up to speed quicker: apprentices, new starters and late joiners to projects already in flight.
They spotted and fixed a number of bugs that had been missed before; scouts rules we naturally brought into play.
The apprentice had asked more questions, and had been able to play as navigator for the first time; this was a massive confidence boost.
On Thursday, the team retro was full of positive comments about the experience.
On Friday, one of the quartet asked me for the link to the tool I’d been using to keep track of rotations and timing. They want to run more sessions like this themselves, not all the time, but at least several a week. I couldn’t be happier.
This week I was asked a flattering question by a colleague during a mutual buddy chat. He asked:
when you work with junior (sic) developers in a workshop and report back a positive learning to the group, are you genuinely finding value or just supporting the learning setting?
In thinking about this I realised how much has changed in the last 3 years.
I can now admit I am rubbish at dissembling.
I can also find huge value in working with all levels via an “again for the first time” approach, an approach I use every day. It’s refreshing to meet today-colleague as a new person and today-challenge as new too.
Is this a new topic for some?