From user needs to functioning programmes

Week 1 at Makers

After what felt like a lifetime of waiting for my course at Makers Academy to begin, I blinked and suddenly the first week was over and done with. I’m pretty sure that I’ll blink again and it’ll be the end of week 12 since 12 weeks really is no time at all, 12 weeks is…a season of Doctor Who. With such a short period of time to turn our 18-strong cohort into confident developers, I hadn’t expected a slow introduction — and we certainly didn’t receive one.

This week, our focus was on Test Driven Development (TDD) and Object Oriented Programming (OOP). Pair programming with a different member of the cohort each day, we built a Boris Bikes (or Santander Cycles) programme that described a system of docking stations and bikes the users could check in and check out. Over the course for the week we were introduced to, and reintroduced to a few concepts that that will stay with us throughout the course.

User Stories and the Domain Model

A user story outlines what a human requires from a programme and how they would like to use it. From this user story, a Domain model can be created. This is essentially a translation of the user story into a model that outlines how different aspects of the system interact with each other. In an object oriented language like Ruby, this system consists of objects and messages.

The process of devising a domain model was informed how our Boris Bikes programme would come together as it essentially defined our initial methods.

The domain model for our Boris Bikes programme

Test on tests on tests

My introduction to testing came a few months ago when I saw a Roman numeral generator come together utilising TDD. I also had the briefest of introductions to Rspec at the same time. This week I realised just how the code as it developed could be driven by the tests. We started with feature tests — in which we ran our programme in the Ruby environment — essentially using the program as we would want it work until an error arose. This helped guide the the methods that needed to be created.

However, before the method is actually created, the spec test needs the be written. On more than one occasion, writing the spec test was much harder than writing the method. And more than once, we plowed ahead with writing the method only to find ourselves unable to write a test that passed.

Putting appropriate tests together sparked some much needed discussions about what a successful result would actually look like and the kind of return values different methods produce.


In a past job, we were often operating in crisis mode, continuously putting materials out with little thought about the body of work were producing our or approach to our work. In retrospect, some things were of lower quality than they could have been, didn’t match our objects as well as they could and time was wasted. Reflection was viewed as a luxury, much to our detriment.

From daily stand-ups reflecting on the previous day to weekly confidence surveys reviewing knowledge of the concepts course there are a lot of points for reflection built into the course at Makers. Through looking back, we can see what worked and what didn’t, and any areas we need to focus on. In a session on Tuesday, Coach Kay spoke about the importance of reflection and the potential benefits of journaling.


I have to admit, the prospect of pairing every day initially made me a bit worried. What if my pair partner knew loads more than me? What if we didn’t get on? What if I had nothing to offer? It turned out that the prospect of pairing was much scarier than the reality. With all of my pairs, we approached the challenge with different levels of knowledge and understanding, as well as different solutions. Even if my pair partner knew things I didn’t know, it wasn’t the end of the world, it was an opportunity to learn and for them the articulate something that they understood — something good for all parties involved. Also, everyone on the course is nice.

Things I’ve learnt

  • The domain model
  • Some good approaches to pairing
  • The basics of feature and unit testing

Things to revisit:

  • ‘Let’ methods in Rspec
  • Doubles in Rspec

In a departure from all this code-talk (a Pride week special🌈)

Some treat for the ears):

And for the eyes:

Show your support

Clapping shows how much you appreciated Sapphire Mason-Brown’s story.