Day 2 — Pairing
So Day 2 was kind of like the first ‘real’ day of Makers, in that it was the first opportunity that we got to get stuck into the weekly challenge and our first full day of pairing with someone.
The weekly challenge was called Boris Bikes, which, as the title suggests, revolved around building a program that simulates everything to do with Boris Bikes, from docking bikes, checking if bikes are available to hire, to see if bikes are working etc…
We had our pairs assigned to us before we arrived, we also got a message saying there were no workshops scheduled, which was kind of a relief after the first day, in order to give us sometime to get used to pairing. I had obviously read that there were a few different methods on pairing, and was not really sure what the best or ‘right’ way to do it was, so we discussed that one of us would ‘drive’ and the other would ‘navigate.’ So basically one would type and one would talk what to type, and kind of talk through the problem in plain English and I thought it worked really well. We broke problems down together and took turns to write the code and push it to git hub. Although one mistake we made was, instead of pushing from both of our profiles, we only pushed from mine, so it looked like my partner had made no contributions to the code as it was all being committed in my name. So after a message from our coach, we quickly rectified this and started pushing to github from both of our computers.
It was a great day for learning to pair, learning to work through problems and also I learnt quite a lot more of code, but I also came across quite a few more problems, mainly RSpec.
TDD and RSpec
So one of the big things about Makers and their curriculum is TDD (test-driven-development), the idea of allowing testing to drive the code. They drill it in from day one that no code should be written before a test, every time we want to write code, we write a test before. The idea is we write a test, watch it fail, and implement the simplest code to make that test work. We then repeat this for the next function, the cycle goes RED, GREEN, REFACTOR, and on each cycle we commit our changes to github.
I got the idea behind it, and it makes sense, but the syntax confused me (and still does) and I think I’m still getting my head around how to write more complex tests for a method. However, the more we work through it and the more examples we see, the more it makes sense and the more I’m able to get to grips with the syntax.
Overall, it was a great day, I learnt a lot and felt quite positive at the end of the day and was looking forward to what the rest of the week, and course, had in store.