What an incredible privilege to live near a city where volunteers give up their Saturdays to help others improve their skills!
On Saturday, 8 June, I participated in the Cape Town Software Developers’ Code Retreat. I had no idea what to expect there, but looking at the questions and responses on their Meetup page, I noticed that the organisers - specifically Nigel Basel - were very friendly and tolerant of newcomers to the community. In the week leading up to the Code Retreat, I thought about what I would like to learn, and came to the conclusion that I haven’t spent anytime on testing yet but have had it on my to-do list for some time now. It would be great to learn some testing…
The event took place at Kelvin Corner in Woodstock, Cape Town, and we were received enthusiastically by co-owner Rob Weidner. Kelvin Corner is a new co-working space with a lovely setup. There are private offices, meeting spaces, a wonderful patio with a full view of Table Mountain, wifi, and great coffee and food.
This event is— John(y) Mupetami (@Johnmupetami) June 4, 2019
Facilitated by Alain & Nigel
Hosted by :David Campey & John Mupetami
Hosted at: Kelvin Corner
Organised by Coder:LevelUp
Sponsored by Investec https://t.co/Xjxx2FMlQV
There were between 30 - 40 developers from various career stages, backgrounds, and most importantly programming preferences.
We were introduced to Conway’s Game of Life. A fantastic problem with a few simple rules which we had to program.
Alain and Nigel introduced us to the plan for the day after our 8am coffee. We also got to introduce ourselves briefly.
Low and behold! I was going to learn about testing. The whole day was about Test Driven Design! We kicked off with an introduction to test driven design and pair programming. The hosts explained what the benefits of test driven design are and how we were going to work in pairs to start building a product. We would try to find a pairing partner who were interested in the same programming language or wanted to work on a similar aspect of the problem even if two people were used to working in different programming languages. Most of all we were supposed to get a feeling for the rhythm of test driven development rather than getting a product out at the end of the day.
At every round we were introduced to new constraints for the coding session. In one round for example, one person had to write the test, and the second person had to write the code that would pass the test. Through this the hosts made sure everyone got a chance to put their hands on the keyboards. This is also known as ‘ping-pong’ pair programming.
After every coding session we would head outside to the patio overlooking Table Mountain, and talk about what we learned, what we found surprising or hard, and how far we came. It was incredibly insightful to hear how highly experienced developers were comfortable to talk about what they didn’t expect, how they were making assumptions about the problem that was tripping them up, how they learned from their pairing buddies, and more. It was also great that new developors could contribute and participate equally.
I learned so much from everyone there!
At the end we had a Closing Circle session where everyone could report back on their experiences:
I was surprised about how kind the developers were to each other throughout the day, while they were coding, during the retro and during informal conversation over lunch or breaks. I’ve been exposed to some rather harsh developer environments in the past few years, but what I found here was respectful people excited to learn from each other and grow.
Most of all I learned where to start with writing unit tests in Python. I absolutely loved the processs of test driven design as it was presented to us and as we practiced it during the day.
I have read a bit about including tests in Jupyter Notebooks (in which my most recent script was written) and have decided to start the whole process of test driven design in the a next contribution to the Metabolism of Cities project for which I recently became a data contributer. I’ll write about that script and the experience of employing test driven design in a next blog post.