Here’s a quick recap from last week:
The most important things I learnt, were being clear and open in communicating with your pair partner. It makes a huge difference and the pairing experience with them a lot better. Otherwise, it’s 8 hours of ego battling, which isn’t why I’m doing this course.
On the technical side, is probably dependency inversion, which seemed hard to grasp at first, as our projects are so small, and I could easily just use the actual class. However, I’ve learnt it’s about maintainability and writing scalable code.
I’ve also started reading Sandi Metz’s Practical Object-Oriented Design in Ruby, which seems very helpful so far.
I’ve probably struggled most with getting my head around mocking in rspec, when to do it, when not to do it. It can feel like I’m just cheating my way through my rspec….
For this week, I want to give more feedback to my partners. I’ve noticed some pairs have been giving each other feedback during the day (just before lunch), so I might start doing that as well. Just to see how my partner is feeling and tell them how I feel / am getting on.
It seems this whole week the pairing is the most intense aspect of the course. As we pair with a new partner everyday, there are two code bases to choose from everyday, and we always use the code base that is behind. This helps a) the person to not miss anything and b) requires the partner who’s ahead to explain and redo some of the exercises and think about it again.
Today’s difficulty was, that we weren’t starting with my code base. This was the first time in the past two weeks. So far, I always had my code which I’ve been working on for a few days, I’d know what it does, where and why. However, looking at someone else’s code is a whole new story.
So I had already done some of the exercises we were doing and so I knew the answers to some of the problems, but me telling my partner my previous solution isn’t going to help anybody… So this clearly showed me, the knowledge gaps I have to fill. (RSpec as usual…)
The most I took from this day was probably the pairing experience. My partner was already ahead of me and so we had to come to an agreement on the pace with which we both were happy with.
That’s the difficult part with pair programming, you have to move at the slowest partner’s paste. Or else, it’s really only one person writing the programme.
I have made the mistake to not speak up, when it’s going to quickly, because I’m busy trying to understand how it works. So I might just say yes, to not have to talk to the person and get another minute or so to think about the issue. This, I’ve learnt today, is not really helpful. Neither for my partner not for myself.
Today, my pair partner and I got to the harder parts of the Oystercard challenge. It took pretty much all day, a ping pong session, a hula hoop session and many biscuits but we got there in the end and it felt really good!
Part of the challenge was extracting a new class out of an existing one. So far we only had a class for our oystercard and for the station, and our oystercard was storing all of our journeys, doing the fares-pretty much everything. So to follow the single responsibility principle, we extracted the journeys to have its own class. Previously we had stored the start and the journey in a hash and pushed the hash in an array. Now we had our new shiney journey class and could store the info for each journey in an object.
It’s funny how, once you’ve done it, you think “oh yeah that makes sense, why did I even bother with an hash at all?”. Hindsight, huh?
The challenge on Wednesday for me were two things:
- Pairing with a new partner, who was more experience than me and therefore had a better and quicker grasp of the concepts we’ve been introduced to.
- Realising how I rushed through RSPEC/documentation the day before and not actually understanding it.
So most of the day I felt like even though we were pairing, and changing who was typing, I didn’t do as much thinking of my own as I would have liked. I probably should have stopped my partner more and just take the time to re-read the documentation, have a few more examples etc. That being said, he was very good as making his thoughts clear and explaining the processes, which was definitely very valuable.
I still felt a bit unsatisfied as I felt way behind my pair (not gonna lie: not an amazing feeling).
So Wednesday evening, after a quick half pint in the Maker’s local and a cheeky Japanese at home, I sat down and started re-reading rspec documentation.
RSPEC I WILL GET YOU!