MAD RESPECT FOR rspec
- Winnie Au
- Jul 23, 2015
- 5 min read
We are nearing the end of week 1 and there's already a ton to report. Every day between 2 and 3 times per day we hold standups, which are essentially meetings with the Rōnin cohort where we discuss things like what the objectives for the day are, how the remainder of the previous day went and if we are stuck on anything in particular. On the second day of the course we were assigned our first partner(s) for pair programming.
Ah! This was an adventure. Even though I had done some occasional pairing during the precourse, I did not feel confident with the precedure at all. That day, unfortunately, I was more or less absent from the pair as I basically just did what I was told -- not because I didn't want to participate, but rather that I didn't know what I was doing at all beyond the first few set of challenges. This was somewhat frustrating, but I held on and tried to keep my spirits up since I expected it to be difficult. My partner was great, but at that point he knew more than I did and I didn't know how to voice what was confusing me. I felt bad about asking questions over and over and despite what they told us at the beginning of the course about reviewing things with our partner I just hoped it would work out and I would just understand. But that day never got easier for me and at night I went to sleep feeling uneasy.
The next day, however, everything seemed to change. We not only rotated to a new partner, which in itself is a challenge (more on this later), but also were told we had to start everything we had done the day before from scratch, but to try and do it all without referring to the answers or resources. I have to say, almost everything I was confused about the day before was clarified. Having seen the material previously was a definite help, but I think the biggest difference between the first day and the second day of pairing, was how I changed my perception of pairing.
From the beginning, my partner and I took turns being the "driver" of the project. I really love this term that our coach gave us to describe effective pairing. In essence, he explained that in effective pairing, at least at this stage of the program, there is typically one "driver" and another who steers. This is how I think of it: Imagine two friends on a road trip some time before the GPS. Neither happens to have a complete map, and all they have is a location of where they want to go, and perhaps the knowledge of some basic landmarks. The two must work together, trusting each other, but also not being afraid to ask questions to each other and to anyone on the way, but some trial and error is also necessary. This is better than one person doing everything while the other watches idly, or alternatively both people on a road trip leaving at separate times, driving in separate cars and not coordinating but somehow expecting to get to the right place around the same time.
Once we started alternating roles and really taking the time to understand everything together, both individuals in the pair were able to solidify most of what they had taken in the day before with a different person.
In terms of the content of the course material, we have mostly been learning and researching how to use rspec to test our code for functionality, using both feature tests and unit tests. This allows us to see whether the program is working in general but also get more specific errors. This access to a wide range of the errors can tell us a lot about our code, such as location of the error, when a method is undefined or whether there is a syntax problem (just to name a few). On top of the course material, during our standups, our coach recently asked for someone to volunteer without knowing what the task was and seeing as I couldn't really imagine there being a legitimate disadvantage to taking on this mysterious task, I volunteered. And yes, it was totally like this:
Anyway...the task ended up just being that I was to look up 3 new methods (I chose 2 array methods and a string method) to present to the rest of our cohort. This is so hopefully by the end of the course we know lots and lots of methods(yay!!). Then today at our first standup we had to get together with our partner for the day and look into the meaning of "duck typing." I can't say I have the best grasp on this concept just yet, but here is an excerpt from the Wikipedia on duck typing which I found most helpful:
"In duck typing, a programmer is only concerned with ensuring that objects behave as demanded of them in a given context, rather than ensuring that they are of a specific type."
Also understood less formally as "When I see a bird that walks like a duck and swims like a duck and quacks like a duck, I call that bird a duck.[1]"
From what I gathered, duck typing can be really useful in the hands of someone who knows what they're doing but also potentially catastrophic for someone who doesn't. So this, I'm guessing, is one of the reasons why we are doing so much practice with rspec this first week of the course - because we will need to make a habit out of testing our code regularly to understand all the nuances in order to avoid producing results that fail to reflect our (and our future clients') intentions.
It's funny, but the things I've learned have already managed to seep into my daily life. Just yesterday as I was sitting in the car with some friends waiting for a pizza we had ordered, we started talking about the Makers program which led to some tangent which then led to a conversation on Codewars. My fiance endearingly made fun of me for my struggles on Codewars and how the "best solution" usually ends up being some concise bit of code when my own solutions are typically much longer. But looking back to our introduction to Codewars when I was face-palming regularly at all the short yet sometimes super complicated "best solutions" I now realize through the words of my mentor and everything I've gone through that the shortest answers aren't always the best (at least for a developer). The best answers tend to be the most readable with lots of potential for future change if necessary.
Apologies, if this particular post seems a bit like chaos in the form of word vomit, but that chaos is definitely an accurate representation of how these first few days have been with pair programming. To all my fellow Makers -- cheers to another successful day of personal growth. Never have I learned so much, so fast, from failing.
A Small Note on Pairing Dynamics:
At Makers, we often switch pair programming partners. As a result, we are being trained to handle a larger variety of personalities and working/learning types which does a pretty good job of simulating a developer's work environment. A developer cannot assume that the person who he or she works with will learn or process things the same way. Additionally, in Rōnin, everyone in the cohort is working online so they are trained to become accustomed to remote pair programming which is becoming more and more relevant in today's world.
Comments