So far, the one word I would use to describe our experience and our learning at Makers Academy is 'Agile'. The previous cohort had two structured hour-long lessons every day with time inbetween to do the exercises and practice implementing the code and processes they were introduced to. Things would be different for us.

 1 require 'bike'
 2 describe Bike do
 3   it { is_expected.to respond_to :broken? }
 4   context 'when created' do
 5     it { is_expected.to_not be_broken }
 6   end
 7   it 'can break' do
 8     subject.break
 9     expect(subject).to be_broken
10   end
11   it 'can be fixed' do
12     subject.break
13     subject.fix
14     expect(subject).not_to be_broken
15   end
16 end

Instead of a formal lecture for the entire cohort, which consists of roughly 20'ish people, we would have 'stand-ups' followed by 'breakouts' and were split into smaller bytes of 6 to 8 people. Initially in the morning stand-up our coach asks us about:

1. What we had done.
2. What was blocking us.
3. What we intended to do.

From that our coach would identify topics that needed to be covered to get our byte in tip-top shape until the next stand-up which is in the afternoon. And we would spend half an hour to an hour discussing these issues, getting some tips on mentality and best practice in coding. So far, so good.

Our weekly challenge is called Boris Bikes. For those who are not native to London, Boris is our mayor and Boris Bikes is the nickname given to the system of hiring and using commonly shared bikes in Central London. Unfortunately I'm far too unfit to bike, I just about make it up the three flights of stairs to the Academy, but friends of mine who do use the system seem to like it.

So our exercises were to implement a system to monitor the docking and maintenance of these bikes, building on very simple code that has minimal scope up to a fully fledged framework.

Everything we do here is pair-programming, working with another person to take turns solving the challenge and offering bigger-picture guidance, defined as driver and navigator.

The aim was not to complete anything, rather to learn best practice when approaching these issues using test-driven development (TDD) and behaviour-driven development (BDD). The code is written in Ruby of course and we use Rspec to execute our tests and Rubocop to assess syntax.

We are told that TDD is very important right now and empirical evidence suggests that that's for good reason, it makes better code. It also happens to be quite fun and intuitive to write, it's just the learning how to write good tests that we need to grasp.

You write the tests before the code itself, so your tests aren't unduly influenced by your execution, with very few exceptions. Going forward we would be asked to employ an 'athletic' workflow, that is that we restart the exercise from scratch each day to reinforce what we have learned and see if we can do it without looking at the notes.