CodeRetreat at SEEK: Clean Code vs Comfort Zone
It’s Monday morning. This is not a typical developer-friendly time to kick yourself straight out of your coding comfort zone and head into eXtreme Learning for a whole day.
Yet, this is what 20 courageous Software Engineers at SEEK and 3 guest coders from the #DevOpsGirls community signed up for on 16th April 2018. They had no idea what they were getting themselves into. Agile & growth mindsets for the win!
“Practice and improve your craft.”
A codeRetreat is a repeatable, day-long event that is focused on practicing the fundamentals of software development, using some of the XP (eXtreme Programming) practices, such as Test Driven Development (TDD), Pair Programming and Simple Design. The goal is to keep getting better at reducing the cost of change and to write code that is openly accepting of change.
While the goal for developers every day is to finish the next deliverable, the focus for developers at a code retreat is to practice and learn — not to finish.
After we reminded ourselves of these fundamentals of clean and adaptable code, we jumped straight into the coding sessions.
The adventure awaiting the team was tackling Conway’s Game of Life in 4 sessions, each time starting over, each time swapping pairing partner, each time with different fun challenges (aka constraints). We wanted to kick our Engineers out of their coding comfort zone for eXtreme Learning after all!
Let’s Get Started!
Every session runs for 45 minutes. After each session the teams delete their code. Often this is when the swearing begins. The purpose of deleting their code is to keep a strong focus on learning. The short timeframe makes it next to impossible for the participants to finish Conway’s Game of Life. Given everyone is deleting their code after each session, it doesn’t matter if the code is really terrible or really good. This leads to a lot of freedom to experiment with trying different approaches to coding and TDD.
Session #1: Warm Up
Getting familiar with the problem, TDD & pairing.
warmup()
{
timeRemaining = timer(45, time.minutes)
while(timeRemaining)
{
workInPairs()
codeSolution()
}
deleteAllCode()
}Session #2: Ping Pong Pairing
Taking turns to write failing test or implementation.
pingPongPairing()
{
timeRemaining = timer(45, time.minutes)
while(timeRemaining)
{
driver.writeFailingTest()
swapDriver()
driver.makeTestPass()
driver.refactor()
}
deleteAllCode()
}
Session #3: Mute Pairing
No talking during the session (exception: unknowns in the language/IDE).
mutePairing()
{
personA.canTalk = false
personB.canTalk = false
pingPongPairing()
}Session #4: Baby Steps
Coding time — boxes of 4 mins for writing and committing passing tests.
babySteps()
{
timeRemaining = timer(45, time.minutes)
while(timeRemaining)
{
stepTimer = timer(4, time.minutes)
try{
writeFailingTest()
makeTestPass()
gitCommit()
}
catch(timeOut)
{
gitRevert()
}
}
deleteAllCode()
}
Iterative Learning on 3 Levels
A codeRetreat aims to maximise learning by exposing the pairs to a complex problem whilst throwing in constraints as challenging session formats.
CodeRetreat has improved my skills and my career more than any other activity that I’ve ever done. Even as a facilitator I’ve learned so much. (Jim Hurne, US-based Software Engineer & seasoned codeRetreat facilitator)
We anchored people’s learnings by taking time to reflect and share them as a group: Iterative Learning = Session + Retro.
The 3 levels of learning throughout the day were on pairing, TDD, and iterating over the same problem:
- Pairing with different people throughout the day lead to multi-faceted learnings from different approaches to the same problem — conceptually and programmatically (programming languages, software design, IDEs, tools, research, communication style).
- By coding the same problem over and over again the team realised that there is no one way of starting to design, code and test a solution. The initial decision to start outside-in (designing the environment first) or inside-out (designing the rules of the game first) determined the team’s TDD approach and how much they would get done and how quickly they would learn about and validate their design.
- Through the Test Driven Development (TDD) focus of the sessions, the teams were challenged to think really small. There were lots of “aha” moments about the difficulties of this discipline, and more importantly, about the benefits of following this approach, as TDD helps guide the design of the solution, without over-engineering the solution.
In Agile and Lean we work with teams to focus on reducing waste for the whole Product Delivery life-cycle. We break down problems into smaller chunks and focus on delivering the most valuable items to the customer to increase the speed and value of learning.
TDD enables the reduction of waste in Software Engineering by a relentless focus on only building what’s relevant and valuable. All whilst leading to cleaner and more adaptable code. This is an important lesson for Software Engineers in a world where speed, adaptability and customer value make or break the success of individuals, teams and businesses.
What did our Software Engineers say?
Ping Pong Pairing: Finding holes
It was valuable to watch someone else write code just to pass my unit tests, as without the assumptions about and context baked into their solution, it showed holes in my tests that I may have not noticed working solo. (J. J.)
Silent Pairing: Expressive Code for Future Self
From session 3 where we couldn’t talk to our partners — This is very relative to having to write self-expressive code as our future self or someone else would be similar to our silent partner who just had to make sense from what the code means. (A.K.)
TDD: Doing it Wrong
The session did make us think/rethink the way we are doing TDD. We were working on a case study about TDD and we had designed all our test scenarios upfront, I was always wondering why we didn’t have any tangible output (code) even after so many days of work. Now I have the answer, we did TDD wrong. It’s not tests first, we have now refactored it and started to write a single test implement it and then go forward. (P.S.)
Facilitation Lessons Learned
There were also learnings for us as facilitators.
TDD Readiness
One of the bigger challenges of our teams was the initial setup of their TDD environment. We asked people to come prepared with their laptop, setup with an IDE of their choice, TDD ready and git installed. However it wasn’t explicit enough. Some teams didn’t even manage to participate in an exercise as they took the whole time setting up their environment.
Next time we will offer more support to our teams upfront. Especially for an internal codeRetreat. For an external codeRetreat we would be more explicit about what a TDD-ready environment means and how they can test it to be codeRetreat ready :)
Randomising Pairing
An idea that was floated to us after the day was to find games to randomise the pairing. Naturally people tend to pair with people around them or people they are used to working with, so finding fun ways to counteract this, is beneficial.
Diversity & #DevOpsGirls
We had a diverse group of people attending the event. From our most junior Associate Software Developers, to our most Senior Principal Developers (also known as Tech Leads in other companies). We had a great ratio of women in tech present with 8 out of the 20 participants. This is much higher than the usual <10% ratio in any team.
We were delighted to support the Melbourne #DevOpsGirls community by opening up our internal training to 3 external Software Engineers. We enjoyed having them contribute their design and engineering skills and for our pairs to learn together with their experience and feedback.
There was an amazing vibe in the room and some fantastic conversations as everyone tried to solve the same problem whilst being challenged by the same constraints.
Conclusion
By the end of the day everyone was exhausted as they reflected on their challenges and experiences. We also hope our codeRetreat helped us deliver on SEEK’s purpose, by helping our Software Engineers live more fulfilling and productive working lives and helping our own organisation succeed.
Interested in codeRetreats — here’s more!
www.coderetreat.org
Learn more about codeRetreats, their history, how to host or facilitate one and where to find the next event near you.
The next Global Day of CodeRetreat #gdcr is scheduled for November 17th 2018. Save the date, checkout if there’ll be a #gdcr event in your area and follow @coderetreat on twitter or join the software crafters slack team.
To read up on another internal CodeRetreat run at REA checkout this blog post: http://rea.tech/tdd-in-bash-aka-our-1st-internal-code-retreat-rea/
Special thanks to Michelle Gleeson for co-hosting the day with me and the pairing fun on the sessions’ pseudo-code. Also to Jo Piechota for championing the event internally. Also thanks to SEEK — Tim Smart & Craig Penfold for sponsoring the event for our Software Engineers. And last but not least thanks to Theresa Neate for helping us to support #DevOpsGirls by inviting 3 external #DevOpsGirls’ Software Engineers.
