Learning about Learning through Feedback on Feedback

DBC Is So Meta

Posted by 'Tine Zekis on May 10, 2015 · 7 mins read

Assignment: Cultural Blog | Feedback

A major focus of learning at Dev Bootcamp (DBC) is introspection. As students, we are asked to learn about our learning styles and to try to grow beyond our comfort zones. Every time we work together on a challenge (pair programming), we must provide anonymous feedback that is Actionable, Specific, and Kind (ASK). Before that feedback reaches our partners, other students rate how well the feedback meets these three requirements. If it does not meet the ASK standards, then the feedback is not delivered to the intended recipient. In order to make this process work, we are also required to rate 7 pieces of anonymous feedback each week. Through this process, we get to see how others provide feedback and think about the extent to which it satisfies the ASK framework. And if that wasn’t enough, we actually receive the feedback on our own feedback. This meta-feedback shows us whether our fellow boots thought that the feedback we gave to our partners was Actionable, Specific and Kind. So in a give week, I will write feedback for three of my cohort-mates, read feedback from up to three cohort-mates on what it was like to pair with me, read and rate seven pieces of anonymous feedback intended for others, AND receive meta-feedback on those three messages that I sent. Aren’t you exhausted just thinking about all that feedback?

Before I get into what it’s like to experience all of that feedback, let’s back it up for a moment and talk about what we’re giving and receiving feedback about: pair programming. Pair programming is when two people work together to write one set of code. This means that at any given time, either person can be typing and/or controlling the mouse. In order to avoid chaos, we try to have each person fulfilling one of two roles: driver and navigator. Of course, these roles mean different things to different people, but the general idea is that the driver is typing in the code, and the navigator is working on talking through proper syntax, looking up information from outside resources, and generally guiding the driver. As you can imagine, pairing can be quite difficult unless communication is very clear and direct. It is important for pairing partners to be open and honest with one another about their working styles and how they like to approach a problem. Perhaps this is why DBC asked us to focus so much on learning how we learn. It’s all so meta!

I am still working on figuring out how I like to pair with others, which I suppose will also vary depending on my partner. But in general, I tend to be a planner. I like to talk out the problem, strategize aloud, and then set up a step-by-step plan for getting to a solution. I was surprised to find that I like working with people who like to dive in and try things out. This isn’t my style at all when I’m working alone, but for some reason, I was able to navigate well with a “jump right in” kind of driver. It was definitely rewarding to solve a problem with someone who thinks so differently from the way that I do. On the other side of things, I have found it frustrating my partner is as indecisive as I am. For instance, I still have not developed a preference for driving vs. navigating at the beginning or the end of a challenge. While I do like the idea of switching halfway through, I still haven’t found a pair who cares which one to start with. We often dance around it for a while until one of us picks something, but I’m so bad at being that person! I guess I’ll have to get over that at some point. But once we decide on who’s doing what, things usually end up going relatively smoothly.

So after the pairing session comes feedback time. I find it a little bit stressful to write feedback, especially because I have no more expertise than my partner in any of this stuff. I often find it difficult to reach the Actionable requirement on my feedback. It is hard to be constructive when I think my pair was awesome, and I just can’t think of what he or she should do differently. And then, of course, comes reading the feedback. This has sometimes been hard, but I know that my cohort-mates are trying to help me to be better at helping them. I have received a couple of pieces of similar feedback, which I absolutely take to heart (if two different people see me making the same mistakes, that seems like it must be a thing). For example, I am working on slowing down when I type to avoid typos. I usually catch them right away, but it is jarring to my pairs to see things moving so quickly, and then get deleted and replaced right away. If I slow down a bit, I can try to avoid the typos in the first place, and be more intentional about what ends up on the screen.

Overall, I think that the pairing and feedback system are incredibly helpful in this process. I am a big believer in vulnerability as a tool for both personal growth and strengthening relationships. I think that when my cohort-mates and I are vulnerable to one another, we learn how to ask for help when we need it. We also get the benefit of our partner’s knowledge while working through a challenge. I don’t think I’ve gone through a single pairing session without learning something from my partner. In addition, I think that by the time we are on-site for Phase 1, 2, and 3, we will already be a tight-knit community. We are creating a safe environment for learning, exposing mistakes, asking questions, and building ourselves up together. This is what I always worked to accomplish for my students as a teacher, and I couldn’t ask for a better learning environment. I’m looking forward to seeing more of what a group so focused on improvement through feedback has to offer, and I can’t wait to meet my cohort face to face!