‘Twas the week before Makers
And all through Google campus
The creatures were pairing
And… engaging their… hippocampus.
Hippocampuses? Hippocampi? I really don’t know – I have already wasted too much time on ‘spitting sick flowz’ to Google the answer. But I challenge you to find a better rhyme. Yes, I could have changed ‘campus’ for a snappier ending, but I thrive on the thrill of factual accuracy. I mean, who doesn’t? #amiright
(And please don’t suggest ‘Grampus’ – the genus that includes Risso’s Dolphin as its only species. That is just so… obvious.)
Anyway. Week four of the pre-course turned out to be a little different from the previous three in that we had to interact, face-to-face with other human beings, to become a pair of human doings.
The brief was simple enough – recreate the game FizzBuzz:
- When passed a multiple of 3, the program returns ‘Fizz’
- When passed a multiple of 5, the programs returns ‘Buzz’
- When passed a multiple of both 3 and 5, return ‘FizzBuzz’
- And if passed a number that is neither a multiple of 3 nor 5, return the number itself
Reading the above, a quick solution consisting of a couple of ‘if’ statements jumps out straight away. In fact, given five minutes, a cup of tea and the inclination, you could probably think of a multitude of simple ways to structure the problem. But wait, holster your keyboard pistols (aka palm sausages aka fingers) – there are bigger beasts to behold.
The two concepts this seemingly simple exercise was designed to expose us to were pair programming and Test Driven Development (TDD). These are both big buzz words in the tech community and are practices we’ll be using every day during our time at Makers Academy.
For those of you who don’t know, and because I have a penchant for posts with subheadings, here is a brief description of each of them:
Does what it says on the tin. You work in a pair. You do programming. But you also do a whole load of other important things that contribute to making code accurate, concise and readable.
In your pairs, one person takes the role of ‘driver’ whilst the other is the ‘navigator’. The driver is usually in control of the keyboard and churns out that sweet, sweet code nectar. The navigator’s job is to provide input on general strategy and also to research syntax, methods and nearby tasty lunch options.
In all honesty, I had my reservations about how productive the pair programming session would be, but in fact it was a really (ahem) fruitful experience. Taking it in turns being the driver and the navigator brought different perspectives and experience to the task, and we both picked up a couple of tips and tricks from each other to improve our coding efficiency in general.
Plus one for pair programming.
Test Driven Development
Whilst pair programming felt surprisingly natural, Test Driven Development, or TDD, was a whole different ball game. The theory behind TDD is rather detailed but in essence it’s test-first philosophy in practice.
The first step in TDD is to write a test that describes the simplest thing you want your program to do and run this test. Unsurprisingly, this test will fail. YOU AIN’T GOT NO PROGRAM YET DUMMY. But this test failure is in fact your first TDD success. Go you.
The second step is to write the easiest code possible to pass your currently failing test. What you write at this point will almost certainly be utterly wrong in the grand scheme of things, but all it needs to do is pass that first test.
Then: iterate! Choose the next thing you want your code to achieve and write another test. Watch it fail gloriously and revel in the fact that this works precisely as expected.
Failing never felt so fabulous. Especially as it’s now time to swap out of ‘driver’ role…
Deal with it, partner.