Reflections on the first week of the Makers course
According to Eóin, our coach at Makers Academy, one of the first lessons he learned about coding at university was to break a problem into steps: his professor used the example of a simple everyday task. If you could write instructions, or pseudocode, for making a cup of tea, you could learn programming. Earlier that morning I had blearily poured a sachet of vitamin powder into my tea, so I perhaps did not find the intended encouragement in this anecdote!
Anyway, last week I wondered if the first week of the Makers coding bootcamp would be like the start of a Formula One race. It actually turned out to be more of a rollercoaster ride, with some occasional lows balanced by some genuine high points, vitamin-laced tea notwithstanding. The first day involved zero coding and a whole lot of Zoom time and listening, as we were inundated with information about learning styles and wellbeing from Eóin and Dana (Makers’ Chief Joy Officer). The day also included plenty of ‘getting to know each other’ sessions, which confirmed my first impressions from the pre-course: our cohort at Makers is full of great people, from a wide range of backgrounds. It felt a bit like starting university all over again, except without the freshers events.
Our cohort has been divided into peer groups of four people each, and we check in every morning at 9.30 to see how we’re doing and to think about our goals for the day ahead. My peer group is really nice, and we’d already had some contact between ourselves, so we gelled pretty quickly. After our first check in on Tuesday, it was straight into a debugging workshop: this was hard! In the group activity, I felt guilty because (a) I leapt right in, sharing my screen and dominating the discussion, when I should have waited for the rest of the group to get onto the same page (b) I inadvertently made us tackle the hardest of three exercises — we didn’t solve it in the time given (and it took me some time in the evening until I worked out the precise nature of the bug). In any case, I took it as a lesson learned about channeling my enthusiasm. During this session, a package arrived in the post from Makers: among other things it contained a Makers rubber duck, an essential debugging tool in itself.
Afternoons at Makers are dedicated to pair programming, and I worked with four excellent partners this week on a challenge to replicate London’s bank-sponsored bike rental scheme. On the first day, my partner and I worked through ten chapters of the challenge — nearly half way! — though I later reflected that some of it was flying a little by the seat of our pants and we could have perhaps stopped more often to pause and get to grips with the techniques we were using. In any case, we got into a good test-driven development (TDD) workflow and remembered to take breaks: the three-hour session flew past. Dana ran a yoga session at the end of the day via Zoom: I managed half an hour, partly because I’m a total beginner and partly because my daughter and wife were staring at me with barely concealed amusement/pity.
I felt really satisfied and energised after day two: it was great to get coding, even better to get out of my comfort zone, and — for the first time on my coding journey — I felt like I was learning some genuinely professional concepts. I loved it! Of course, this was followed by my worst low of the week on Wednesday morning when I decided to undertake some solo practical work on TDD using RSpec. The Makers approach relies on self-led learning — i.e. equipping us to find solutions to problems ourselves — and I’ve always been pretty good at this. Indeed, I managed to work through a fairly simple exercise with no problems. I then picked an exercise which was probably a step too far at my current level and hit a block. I felt myself getting stressed as what seemed like ages passed and I did not seem to be making any progress in writing a single test.
I was rescued by my mentor coincidentally checking in with me via direct message on Slack. I confessed I was struggling a bit and they invited me into a Zoom chat. We soon solved my issue — after googling the error message I was receiving, we discovered my code had a space where a space shouldn’t be. A space! It was the debugging rather than the TDD that had been my downfall. My mentor then chatted with me until lunchtime — it was a good pep talk and got my spirits back up, though I still felt foolish: why didn’t I ask someone for help sooner? Why didn’t I google the error message (a basic lesson of debugging)? Of course, since Tuesday morning I have written several more tests and have not made the same error again.
Pair programming proceeded smoothly on Wednesday and Thursday. The week’s challenge required a lot more sustained focus than, say, the Codewars katas which had been my predominant prior experience of pairing — and this intensity also cast some of the flaws in my existing practice into sharp relief. In particular, I worried that I was monopolising the sessions, and that I was interrupting too much when I was the ‘navigator’. In future I want to ensure I give the ‘driver’ much more time to think about their next step, and to ask more constructive questions rather than simply saying what I’d do. Admittedly, it is early days and we’re all finding our feet and learning from each other.
At the end of Thursday I noted down that I felt ‘happier’ and that it was starting ‘to click’. We were told not to compare progress on the pairing challenge with other groups — indeed, we were changing partners every day and starting from whoever was the furthest behind so comparisons were meaningless— and I thought this was sound advice. I was certainly happy with my own progress and thinking by the end of Thursday: this was helped by a good morning workshop on TDD. Planning and writing tests no longer seemed so difficult, and my struggles on Tuesday began to fade into memory. My main issue increasingly seems to be less connected to the actual coding (which I assumed would be my biggest difficulty) and more to do with interpreting user stories and adapting them into suitable feature and unit tests. I decided to capture some of what I’d learned about TDD in a blog post, which has received some nice feedback from my peers.
Friday was a great day, which ended in lots of laughter at the cohort social. In the morning I was back on the solo work — this was much more productive than Tuesday and I chose more appropriate materials to work through. On day one, we were told to ‘trust the process’ — I felt I wast at least starting to get a handle on the process. In the afternoon I paired with somebody who was ahead of me: this led to a good experience as they guided me through some of my blocks. I noted that my partner had a great attitude and clear process in their coding, which I was inspired by.
I won’t say too much about the first weekend challenge — the Airport Challenge — except that it was both reassuring and occasionally stressful (in other words, a microcosm of the whole week). Flying solo, I felt pleased that I remembered and applied lots of what I’d learned during the week, and I also picked up new skills like doubles and stubs in RSpec. The stress can hopefully be mitigated in future weekend challenges: I made the mistake of not taking regular breaks, and this led to me becoming stuck on Saturday afternoon. Sometimes stepping away from the screen is the best way to reset, and I typically come back to find the problem isn’t as difficult as I’d first imagined. I also need to be more patient in consulting resources and docs to help me figure out answers. I finished the bulk of the challenge on Saturday, before tidying up some things on Sunday night.
So, week one was definitely a rollercoaster, albeit I’m glad that I took the ride. It wasn’t a perfect week, but it contained some minor personal triumphs among the frustrations. I have learned a lot about what I do well, but even more about what I need to improve as I move through the course. The most important thing is that I’m absolutely loving it, and finding Makers to be an even better learning experience than I’d hoped to imagine.
