My coding journey: pairing, mobbing and 12 lines of Ruby!
It’s only week two, but this one was a significant challenge! A fantastically (yes, fantastically) terrifying moment of “can I really do this?!” which lasted the best part of Thursday’s work day. The temptation to give up lingered, getting stronger and stronger with each minute of confusion that passed. I stared at my screen trying to understand WHY my latest test was failing, and figured I was just never going to make my code work…
…what happened next…? Let me walk you back to the start of the week…
Having published my first ever blogpost early Monday morning, I settled into looking at what new concepts the week would introduce. Following an intro from our mentors, we began learning about Test Driven Development. The idea of TDD is to break a problem down using simple smaller steps, testing along the way, and then to incrementally increase complexity. Without presumptions about how the program should work overall, the focus instead is to get it to work for each test stage.
To get started, we paired on the Fizzbuzz code kata. The aim was to build a program which would return ‘fizz’ for any number which is a multiple of 3, ‘buzz’ for a multiple of 5, and ‘fizzbuzz’ for a multiple of both 3 and 5 (e.g. 15). The first step in TDD is always to start with a test which you expect to fail. With each test, you describe what you want to achieve next and improve your code to get that test to pass green.
Our next challenge was to build ‘coinchanger’, a program which would produce the minimal amount of loose change for a given amount, using pence as the unit of currency. For example, 67p would become ‘50, 10, 5, and 2’.
We started out by deciding together where to start. Our first test was only two lines of code. (We later discovered that this is called mobbing — the term for “pair” programming with more than one other individual at the same time). Having experienced it, I’d say that mobbing can fall somewhere between strength in numbers and too many cooks. It’s probably best used when brainstorming ideas at the start of a program, followed by coding either alone or in literal pairs.
The coinchanger challenge took a total of 3 days to achieve, and personally it took a lot to get to comfortable with approaching simple small steps. I have a tendency to evaluate the needs of the whole task, and come up with ideas for how to achieve that end, so the challenge to let go of that and focus solely on the step at hand required a re-learning of thinking. It was refreshing to let go of the attachment to the solution. Who said coding couldn’t provide important life lessons?!
As each test built on top of the other and passed successfully, the program required more functionality. After the first few tests, I introduced an array to store the list of coins which were available. A few tests later, I began to define new methods outside of the coinchanger method, to handle some of the required math for specific tests. My file got longer, and the logic knottier with each test added but continued to pass successfully.
On Thursday morning (where the story of this post began) I began the day just one or two tests away from “finishing” the exercise, 74 lines of code in! My latest test failed and I then spent the majority of my day staring at “11 examples, 1 failure” trying to figure how to fix my broken code which kept getting caught in the second step of my while loop.
I attempted a multitude of alternatives, even considering introducing classes, and spent a couple of hours thinking through the logic required to get my code to work using classes. With each attempt I found my number of failures increasing, moving further away from the desired 0 failures. Eventually I stepped back from delving into classes and tried to think through a solution using the methods I had. Key tip for when you get stuck — pair, pair, pair, and if all else fails, scrap everything you have and start again (well not really, but start a blank new file).
Starting again opened up space for new thoughts (thanks Laurent!), and with the support of my fellow mobbers, at around 4pm on Thursday afternoon I got my while loop to work and finally saw 11 green passes! Euphoria!
The final step was to clean up my code, reduce the number of methods, and strip out any duplication. My 74 lines quickly went down to one single method, containing only 12 lines of code, yet still achieving everything that my 74 lines had been doing previously! The final file was 83% shorter than what I had. (If of interest, feel free to visit my repo and take a walk through my commit history).
After conquering coinchanger, the last challenge of the week was Roman Numerals, a program which could convert any number to RN. By implementing the learning from coinchanger, this was a breeze in comparison.
My highlights this week:
- Pairing as often as possible, with as many of the team as possible. It emphasised that there are so many possible solutions, no matter the individual’s level of experience. Therefore, my ideas are valid too!
- Mobbing (my new favourite tech term) with my fellow apprentices. This week really strengthened the bond between us.
- Meeting more of the 8th Light team, including a visitor from the Chicago office 😃
- ‘Testing, testing, 123', and re-factoring all the way
Things coming up that I’m nervous about:
Getting a better understanding of classes and objects 😰 😅 but that’ll likely be the subject of a future blogpost!
