A Retrospective: Apprenticeship

Last Friday I had my first retrospective. Retrospectives are an opportunity to take a step back and reflect on the experience as a whole: what is going well and what needs improvement. By voicing my perspective to my mentor, and in turn hearing his take on things, growth and improvement can be accelerated. What follows is a reflection on my experience thus far.

Pairing sessions are extremely valuable. They provide a high rate of knowledge transfer and allow me to make the most progress in my coding projects. This includes both work I have paired on with other apprentices as well as the pairing that I have done with my mentor. In light of this realization my mentor and I will be pairing on a regular basis for about an hour once a week.

Directly related to pairing is the help I receive from others. I have written about this topic before, but I find it worth mentioning again. By increasing the frequency with which I ask for help I am tightening the feedback loop; I can learn more often. Not only does this communicative approach help me, but it contributes to the culture within our community. In addition to my own asking for help, I have noticed others reaching out amongst themselves too. Once in a while even I am asked to take a look at things when a second pair of eyes is needed and my help can be of use.

One area I have struggled in is when iteration requirements seem less than concrete. I have a tendency to make assumptions, when clarifying the “client’s” interests would be a better approach. Instead of assuming that a certain set of features needs to be implemented -- and then struggling to meet a deadline with those additional requirements -- simply clarifying the details of a story would save time and headaches. In addition, creating concrete requirements by writing them down and agreeing upon them can help to resolve this as well.

I have also struggled with my latest reading assignments. Agile Software Development: Principles, Patterns, and Practices has been an engaging read for the first 150 pages or so, but I have had trouble relating the design patterns to my tasks at hand. It is difficult to know what I should be getting from the text when I do not speak the languages in which the author makes his points. In response to this I have been assigned a different book that touches on similar topics: Design Patterns in Ruby.

Lastly, I continue to gain much from the tutelage of an excellent instructor. I know from my own experience as a high school teacher that it is easy to forget how much your students do not know. In requesting more mindfulness of my programming naïveté, I was met with an understanding nod of the head and a willingness to bear with me as I continue on my path in pursuit of software craftsmanship.