Test-Driven Development, Boris Bikes and Debugging
Another week successfully completed and the pace is well and truly starting to ramp up. This week focused on test-driven development, the idea of writing the tests for a code before writing the code itself. Seems a bit backwards but as the week went on, turns out it’s quite a useful strategy.
We started the week with a kick-off session explaining the concept and seeing a demo of the process in action. We were then left to our own devices to do some self-directed learning for the rest of the morning before beginning our first pair programming challenge in the afternoon.
The pair programming challenge would continue throughout the week, every afternoon, paired with someone different to work our way through creating a program. The program aimed to mimic the London Boris Bike system allowing users to get a bike from a docking station, dock a bike, check if bikes are working and check if docking stations are full. Sounds simple enough on the surface, not so much when it came to actually creating it.
Day one of the challenge started well enough, my pair and I worked through the first few steps with ease. Admittedly, we basically just set up our program, got our files sorted and made sure everything would work ready for creating some tests.. We wrote the first few feature and unit tests, had expected errors and corrected them by writing the appropriate code to pass; the red, green, refactor cycle worked perfectly. Up till this point we had pretty much been able to come up with this ourselves and used the walkthrough as a sanity check to assess wherever we were on the right track. A positive start that left us feeling confident about the week ahead
The Tuesday morning was free time for self-directed learning and I continued the confidence from Monday by working my way through a practice activity that had previously defeated me. Aware of my tendency to dwell on a problem alone for too long, I reached out early for some help from my coach. A progress point for me in reaching out for help, and an even bigger confidence boost as it turned out I had done it correctly to begin with and was in fact trying to implement something more complex that unfortunately wasn’t possible with the shortcut I had tried. Good to know, I actually had some idea what I was doing and in fact I was thinking ahead of the game. Things are making sense, it’s looking good. Or maybe not…
Returning to good old Boris and his pesky bikes and I experienced the first low of the week. My partner and I felt lost, we had tried to implement the TDD process, carefully reading user stories and trying to turn them into code and a useful test to progress the task but we were struggling. We found ourselves turning to the walkthrough for support earlier and earlier. We attempted to follow the guidance and understand each step but at times couldn’t quite grasp why a certain section of code had been implemented or had been removed. There seemed to be assumptions made that we couldn’t fathom. Whilst I’m sure battling through and trying to fully understand what was happening where would be super useful, to be honest, I was done with staring at code for the day.
A whole group debrief at the end of the day went some way to making me feel better inasmuch as misery enjoys company. As it turned out, everyone had struggled that afternoon and we weren’t alone in feeling a bit out of our depth. Overall, the Tuesday afternoon was a harsh reminder of just how early we still are in this learning journey. I guess it’s good to remember that it’s okay to still be using the support and scaffolding in place, that’s what it’s there for.
Wednesday was a new day and an engaging debugging workshop in the morning helped to perk me up again. Currently my debugging process consists of; see it doesn’t work, try find the problem, try a bunch of random things and hope for the best. Not exactly the most scientific of methods. It was certainly useful to see other, more methodical approaches and how to help pinpoint the issue and see what exactly is going wrong. Whilst it might take me some time to shake away my bad habits I will endeavour to use a more scientific process than fingers crossed and hope for the best in future, I promise.
After the challenges of yesterdays Boris Biking, I was reluctant to pair program this afternoon but in hindsight, I’m glad I did. My pair for the day was a bit behind me in terms of progress so I had the pleasure of trying to explain what I had done the previous day. Given that yesterday I could barely follow my own logic I thought this would be a somewhat pointless task. However, it turns out that a good night’s sleep, a few google searches and a bit more reading went a long way to help my understanding. Whilst there were still parts of the rspec tests and code I wasn’t 100% sure about, I certainly understood the logic more than yesterday and I was able to guide my partner to the same stage as me. From here, things got even better, the next few stages of the challenge made much more sense, I felt able to suggest tests to write, knowing what errors I would expect and how I would go about writing code to fix them. I felt more on my game and able to bounce ideas around with my partner and feel that I actually had some idea about what I was talking about. Confidence somewhat restored.
The final day of the biking with Boris saw us progress even further, becoming more and more independent from the walkthroughs and implementing new features using the TDD cycle throughout. We did hit a road block, but once again, reaching out for help, saw us able to progress forward and as it turned out, our logic was there, a fresh perspective was just needed. Overall by Thursday afternoon I felt in a good position to go into Friday and tackle the big challenge of the week; do it all again, but this time alone.
Friday saw me begin the airport challenge, a similar concept to Boris bikes but this time involving aeroplanes landing and taking off from airports. I started with a positive mind, take it step by step and follow the process, what could go wrong? I surprised myself in that, not much went wrong, actually it was a fairly smooth process, slow but steady. Granted I didn’t fully complete the challenge but I felt confident in the steps I had completed and more importantly, I had consistently followed the process throughout. Yay me!
I felt a bit disheartened that I hadn’t completed the challenge, but following a group retrospective and reflecting on the overall goals for the week I was prepared to give myself a break. Looking back on the week, I had achieved the goals despite not finishing the tasks. Usually one to always finish what I start, I realise I need to come to terms with being okay with a different definition of finished. Going forward, I need to accept, I am not expected to finish all the challenges and content. If I can finish the module having an understanding of the key learning outcomes and feel that I know more than I did last week, I’ve made progress and that’s all that matters.
