Reflections on the tenth week of the Makers course
Week ten was a strange week: it gave me a rare chance to sit back and take stock of how much I’ve learned on the course so far, but it was also a bit lonely as we were expected to work solo on a ‘tech test’. Officially, this week is known as ‘code quality week’ and we were expected to complete our tech test by Wednesday so that the coaches could provide feedback by Friday.
The challenge was fairly simple on paper: write a command line banking app with deposit, withdraw, and print statement functionality. I decided to demonstrate the quality of my code by completing the tech test in Ruby, as this is the language I’m most comfortable with and figured this would allow me to focus on demonstrating good coding technique rather than worrying about syntax. I spent a bit of time (possibly over)thinking and planning how I’d respond to the challenge, and then had a productive afternoon of test-driven development. I only hit a few blockers, mainly related to mocking in my tests, but was generally happy. I kept my project directory tidy, and regularly updated the readme file (including a log of how I approached each step of the challenge).
The solid work continued on Tuesday: my blockers were again mainly related to testing, but I was starting to see the bigger picture emerge out of my test-driven development process. I found my code was straightforward to refactor and I wasn’t losing much time debugging. I spent some time learning about BigDecimal, as I discovered that 2.6 + 2.4 does not equal 5 in Ruby (if you don’t believe me, open irb and type that sum in)! I also explored Timecop as a way of ‘freezing’ time in Ruby and making my tests more robust in this regard. Although I felt I was making good progress, I was nonetheless quite stressed at times and really missed having a pair programming partner to bounce ideas off.
On Wednesday I had my first external review: a software developer from outside Makers watched me code a simple problem for just under an hour, before providing verbal and written feedback. I’d been really apprehensive about this, but actually enjoyed the experience while it was happening. At one point I was alarmed that my reviewer was grimacing, but this was because he was being attacked by his cat, not because of the quality of my code. I was happy that I didn’t get flustered under conditions that were similar to a tech interview, and I thought the feedback was really useful too: lots of encouragement and positives, but also pointing out several problems with my TDD process that I can seek to address in my next review. In particular, I should avoid over-planning and pre-determining the structure of my code before I start test-driving my code, and I should always seek to ‘go green’ with the simplest possible code before refactoring: at the moment, I’m tending to merge these two steps together.
I finished off the bank tech test after my review, and submitted it: I was reasonably pleased with the code, which I’d spent some time polishing up, but — as ever — had some uncertainty about whether I was testing behaviour rather than state, and if I was adhering to good object-oriented programming practices. I snuck off to my allotment for an hour or so, and then returned to embark on a second tech test: the infamous Gilded Rose kata. This looked like fun, and I decided I would give JavaScript a go so that I could improve my knowledge of JS testing frameworks.
I caught up with the rest of the cohort on Thursday morning, for a brainstorming session. This was simultaneously fun and unnerving: we were coming up with ideas for Group Engineering Project III, in other words the last thing we would do on the Makers course. I put forward my idea of creating a kind of Duolingo-Scratch mash-up app to teach children how to code. Beyond my peer group and the external code reviewer, I hadn’t spoken to many people this week about coding, so it was nice to see everyone else. I also had a good chat with one of my mentees, who is very much where I was in week two in terms of feeling uncertain about the different style of learning, the sense that not everything was sinking in and lots of concepts only felt ‘half-baked’ at this stage…
As the week came to an end, I was pleased to receive some really positive feedback on my bank tech test: the coach liked my tests, my classes, and my clear documentation. My use of BigDecimal was described (and praised) as ‘niche’. The main critique was I’d added a couple of lines of functionality that went beyond the specification: I was advised to get into the habit of not doing this, with an eye on writing code for ‘real world’ clients.
I didn’t finish the Gilded Rose kata, but I enjoyed working on it and will definitely come back to it at some point.
This week’s process workshop was on Friday, which — coupled with the busy week working on tech tests and reviews — meant I wasn’t perhaps as sharp as usual! My observer offered some kind comments though. We then had a talk from the Makers careers team: this was exciting but alarming: i.e. we were told the job hunt is a bit like taking another bootcamp after the bootcamp, and that a 5-day-a-week commitment is what is most likely to get a Makers graduate a job within 3 months. Phew! I’m taking on childcare responsibilities after the course ends, so it might take me a bit longer…
Meanwhile, we are now firmly into endgame territory with regards to the Makers course. Next up is the final engineering project where we work as a group to produce something from scratch in two weeks.
