Week 3, Part 2. The Journey is the Destination.

The journey is the destination

I happened to pick up a book The Journey is the Destination this week, the title of which touches on my experience at Makers so far. It is an incredible collage-diary of a young photojournalist called Dan Eldon and his global explorations (sadly his life was cut short at 22 – but what a life!). There’s a lot of amazing photography and art, which is about all the culture I have time for right now.

Something that has become fully apparent to me only this week at MA is that the process of learning at Makers is itself the destination of learning. In other words, part of the challenge is to learn how to learn. But what does that really mean? They way I see it is that when you’re learning anything new there is a constant tension between what you understand and what you don’t yet understand. Being a good learner is about effectively managing this tension. If you go crashing into the unknown too recklessly, you’re going to get stuck in a myriad of things you don’t understand. This is dispiriting and the reason a lot of learners just give up.

The challenge as a student at MA is to carefully control how you advance in building with new and unfamiliar technology. Often what seems like a small step leads you into the thicket of non-understanding and you have to back out again to take even smaller steps and figure out exactly where it was that things didn’t go how you expected them to. The staff at MA are excellent at coaching students on this incremental journey, not giving up the answer but helping to clarify what’s at stake in each line of code. Eventually this process will be second nature.

Sometimes, however, a problem comes along that is completely beyond your experience and brings progress to a complete standstill. My pair partner and I had this on Thursday when, weirdly, our Cucumber tests of our Battleships game were going green (that’s a good thing) but when we loaded up our the website, we weren’t seeing what we expected to see. It turned out that it was to do with the program we were using to run the website, which was different to the program that the testing software uses. That this might make a difference hadn’t occurred to us and probably in a different context we would have given up. Fortunately we had an MA coach on hand :-).

Week 3, Part 2. The Journey is the Destination.

Why Makers?

A common topic of conversation amongst Makers students is, quite naturally, why are you here? What motivates you? Here I’ll list some of my reasons before focusing on one.

  • I want to work in a creative and fast-moving industry.The loop between design and realisation is very tight when coding, given that the only limit is how fast you can think/type.
  • The tech industry has some of the best business practices. This is only becoming fully apparent to me now with our exposure to various design practices, the Minimum Viable Product concept, etc.
  • A global skillset. What we are learning can be taken anywhere, because technology is everywhere.

    More idealistically however, and this is coming from my own background in education, I am interested in how tech might transform access to and quality of learning. So many students around the world cannot get the teachers and materials they need or, even for those who can, the style and structure of learning is poor. Online platforms are beginning to provide low-cost options in a form that might even be more interactive and engaging for students than the average classroom.

    At the moment though, it’s pretty restricted to the “hard-subjects”, such as maths and science, where there is an objective answer that can easily be validated by a computer. Sure there are other subjects but these usually have the form of lecture videos, reading material, etc. Basically, the traditional style of learning put online.

    In the future, though, with machine learning and so on we may be able to have computers understand, evaluate, and respond to not just user-responses restricted to a set of pre-defined options but complex, opinionated, and synthetic judgements.

    So anyway, that kind of stuff is what I want to be involved in. But first I have to understand how to encapsulate Cucumber tests >_< (more on that tomorrow).

Why Makers?

Week 3, Part 1: To the Web.

So far it’s all been about Ruby. Even RSpec, the testing framework we have been using up until now to drive the development of Week 1’s Boris Bikes project and Week 2’s Battleships is written in Ruby.


This week though we’ve stepped out of that relative comfort zone into a technology called Cucumber, which we’re using to build our Battleships Online web game. As far as I can tell, Cucumber is structured to promote a business practice whereby you begin by describing program features in plain english. This forces you to think about the rationale for having these features in the first place, before you’ve done the difficult work of coding them. Running this description then invites a kind of virtual user of your web app or site to browse through and check that it works how it is supposed to.

There are a few layers to it to get from the English description to the behaviour of this ‘virtual user’, which deviate far from the Ruby syntax we’re used to it. So today was a slow process of writing the description, correcting syntax, and then writing the HTML to satisfy the test, correcting that.


Right now I can’t imagine how the project is going to look 3 days from now, which makes this week an exciting one to be at Makers

Week 3, Part 1: To the Web.

The First Two Weeks.

My cohort of students began on December 8th (2014) but I didn’t get round to writing this till over the Christmas break. So here’s a brief overview of the first two weeks:


Ruby is a programming language that is supposed to be legible for humans. Sometimes it looks like this:

puts “What’s your name?”
gets name
puts “Hello #{name}!”

But then it can also look like this:
possible_dim_arrays = @win_conditions.select {|dim_array| dim_array.select {|loc| @loc[loc] != “X”}.length == 3}

This is a line from a noughts and crosses game I wrote, and am now a little embarrassed by. Part of what we’re learning at MA is to write code in a style that can be read by other people and easily maintained.

Pair Programming

The first week was also an introduction to pair programming. When pairing one person is the driver, i.e. has the keyboard and writes, and the other navigates, spotting problems and suggesting alternatives. Some aspects of pair programming I find easy. At the level of individual lines of code, a simple typo can break everything so it’s helpful to have another pair of eyes spotting trivial mistakes. When planning the architecture of a program it helps to have someone to bounce ideas off. Coding as a pair also wards off the tunnel vision I sometimes get while coding solo.

The hardest thing I have found about pair programming is the connecting bit between writing lines of code and discussing the abstract structure of a program. Often you can have long strategic discussions about how objects might interact, how they interact in the real world, how they really should interact, that result in some decisions on those questions but don’t really lead to much because it’s not easy to predict how such decisions are best realized in Ruby syntax.


As fellow makers who got my lecture about the Dependency Inversion Principle (comparing it to the international trade in used clothing) know, I love a good metaphor. For me, a class (which is really what we’ve been testing so far) is like a factory production line. The production line takes in instances of objects, puts various “machines” to work on them and then spits them out the other side maybe as slightly different objects. To test that the production line as a whole is doing what it should be doing wouldn’t be very helpful. Maybe your car comes out of the production line without any tyres on. But is that the fault of the tyre-fitting machine? Or is it the tyre-making machine? Or maybe the wheel-fitting machine put the wrong sized wheels on? It could be hard to tell.

RSpec, a testing environment for Ruby, is like a mechanical claw that can pick up individual machines, parts of your production line, and check that they’re doing what they should be doing. Here’s a graphic illustration of my point:


The First Two Weeks.