I’m 4 weeks and 3 days into Dev Bootcamp’s Phase 0 virtual prep program (halfway), and I must say, “wow!” The purpose of Phase 0 is to springboard the learning experience and to provide a foundation for programming. Since this phase of the program is remote, I was worried that I would be doing this all by myself, that I would have nowhere to go when I have questions, and that I would feel out of the loop and fall behind. I’ve taken online classes before and the experiences were mediocre at best. It was mostly self-learning and group discussions were not very interactive.
To my surprise, even though DBC’s Phase 0 is remote, not once did I feel alone in this process. Dev Bootcamp created an immersive virtual environment that spans across several platforms. There are fellow classmates almost instantaneously answering the questions I post on Google+, giving feedback on my blogs via Twitter, reviewing my code and submitting issues on GitHub, pair programming with me via Hangout and Skype, and giving me actionable feedback on Socrates (an internal anonymous feedback system). So far, this virtual phase feels more immersive than most of the classes I took when I was in college. I am truly impressed.
One of the core features of Phase 0 is pair programming. Pair programming is an agile software development technique in which two programmers working together on one workstation. The driver writes code while the navigator guides and review. DBC requires us to pair program at least 2-3 times a week. In these 4 and a half weeks, I have learned how to share my thought process and work effectively with a peer, as both a driver and a navigator.
It was definitely a new experience to pair program. I’ve taken introduction classes to Java, Python, and other programming languages before, and for the most part, I just worked on the challenges on my own. Pair programming forced me to communicate with my peer. I had to adjust the way I work at first. It helped me learn how to express my thought process (which makes sure I know what I’m talking about myself), as well as listen to other methods and ways to solve the problem.
This has been really rewarding. There are times when I over engineer a solution to the problem, but my peer knows of a better and more efficient way to solve it. There are times when I am stuck and don’t understand why something is happening, but my peer does and is there to walk me through it. Of course, there are also times when my peer is not on the same page as me and I would need to explain what is going on, which can make the pairing session a little difficult. It was frustrating at first, but I learned that by teaching, I am also learning and reinforcing my knowledge on the topic as well. Just seeing how others think and different ways to accomplish the same goal is already amazing on its own.
With all these pair programming sessions also comes a lot of feedback, which was overwhelming at first. After each session, we submit anonymous feedback to each other through DBC’s Feedbackinator. Each piece of feedback goes through a peer rating system and doesn’t show up on your dashboard until enough peers agree that it is specific, actionable, and kind (A.S.K.). It is important to note that kind does not mean nice. If you’re saying something just to be nice, but it is not true, it is not kind.
Reading through my feedback, there were a lot of positive feedback, as well as some constructive ones. At first, I was taken aback when I saw these constructive ones. I read them as negative feedback and felt as if I was being attacked. But after reading through them again, I can see it from their point-of-view and realized that they were only being specific, actionable, and most importantly, kind. It is okay to feel vulnerable. They are being truthful in what they observed when working with me, and I can learn from it and better myself. I learned that I am very focused, but sometimes I can get too wrapped up and make the pairing session feel too professional and uptight. I will be more conscious of my pairing style and spend some extra time in the beginning of the session checking in and getting to know the person on a personal level.
Writing feedback to others was harder than I thought. It required me to actively think and make sure it is specific and actionable. The more feedback I give, the easier it becomes. Overall, I think Dev Bootcamp’s use of pairing and feedback to guide our learning is right on the money.
If you have 30 minutes to spare (which is hard to come by these days) and want to learn more on how to give and receive great feedback, take a look at this DBC video:
This blog has been initially published on tonymai.github.io.