“A man of genius makes no mistakes. His errors are volitional and are the portals to discovery.”
~Ulysses, James Joyce
Week 2 of makers proper (wk6) was tough. However, at the end of it came another revelation.
The beginning started out well; I was riding on the excitement of week 5, I’d picked up some awesome shortcuts (and was hardly using the mousepad), I was really enjoying getting to know my cohort in pair programming, even coding for the week’s challenge (an Oystercard) seemed deceptively easy until….exercise 18, Thursday.
Turns out, the exercises up to that point had been designed to lead us astray and programme a beast of a card object so that it could teach us a lesson. About extracting classes for dependency injection. All in the name of writing good code based on SOLID principles.
In short, the Oystercard was doing too many things (tapping in/out, charging fares, logging journeys). So we had to pull out (extract) different responsibilities and create Journey_log and Journey classes (and inject functionality back in).
This all sounds very sensible, reasonable even, and in all likelihood as a developer, a very real part of the job. Which is why it was distressing when my pair and I were essentially stuck for 36hrs (including sleep, and a different pair partner). If we weren’t caught in a loop for the logic of one part of the problem, it was in failing the Rspec test for another. To top it off, the free ride that were the code walkthroughs were no longer an option. There were just these sample Rspec tests which only raised more questions than they answered.
In a way, it was comforting to know that the whole cohort also got stuck at the same part. I kept hearing the word “journey”. Sometimes I wasn’t sure if it was someone saying it, if it was my own voice or even if it was out loud. The word had lost all meaning by 1pm.
Eventually, eureka moments were had, high-fives were made and we all got on with our lives.
On reflection, I am grateful I had mentally prepared myself to find parts difficult, to struggle with some concepts and made an allowance to go at a slower pace — just generally to be kinder to myself and enjoy the process. If not, this week may well have seen me experiencing the “imposter syndrome” I had been warned of.
However, the real revelation wasn’t until the Friday retrospective where we shared our challenges, victories and suggestions as a group. Someone put the misleading part of the challenge under challenges. Our coach responded that this had been done on purpose — it was a “d*** move” but it was intentional. This was a similar response from a different coach on the Student’s Directory challenge (for week 3 of the pre-course). It was meant to be hard. The point had been for us to feel the struggle.
That was when it really clicked for me and I saw coding in a new light.
In order to succeed as a developer, you have to be prepared to fail.
Fail up front. Fail a lot. Fail all the time. Look for ways to fail. Because that’s how you learn. That’s how great software is made. And then that’s how everything is made even better.
KEY TAKEAWAYS
The whole point of testing is to fail
Test Driven Development (TDD) — you start by writing tests which you expect to fail (never have I dreamed I would get frustrated at seeing tests pass).
The only way to learn is to fail
There are three certainties in life — death, taxes and bugs — somewhere, somewhen down the line, something will break. Get good at stack tracing and bug hunting.
So while the sentiment of this lesson / blog is more portals to discovery than the genius Joyce refers, I feel this sums up the whole thing nicely:
❤
