Effective Pair Work: Git, Project Planning and Reflective Feedback
On the second day of Makers Academy started to come thick and fast. It felt like we had already completed a week of coding although we were only on Tuesday. Our Chief Joy Officer continued to provide excellent support through the regular meditation session at 2.00 pm and also with our yoga lesson at 5.00 pm. There were lots of opportunities for tutor support which I made a mental note to take advantage of. I decided to try to meet with Dana at least once a week to keep a record of my progress during the course. I also decided to aim to look out for support from our supportive tutors if and when I had exhausted my own research avenues.
We had been given the challenge of building a docking station and bikes infrastructure with 22 separate challenges leading us towards the final product. Ed, our tutor gave us friendly but firm advice that the purpose of this exercise, as with all tasks on the Makers course, was to learn rather than just complete tasks. We were expected to find out how to effectively problem solve. There were generous walk throughs and resources to help us to learn but it was important to go through the process of getting stuck in order to improve. The Makers Academy github account also had a series of excellent course pills which provided guidance on the aspects of this Boris bikes challenge and also a huge range of other topics from Bloom’s Taxonomy to What Makes a Good Final Project.
Our morning lesson, led by the consummate and thoughtful Ed explored how to use git in order to work as a team. This provided a useful introduction to the research process. Ed made a strong argument for the advantages of pair programming by using Bloom’s taxonomy:
He showed us that it was easy to see progress as a linear process in which we worked towards a final goal. For our week challenge we had been given 22 challenges to complete in pairs however we shouldn’t think of the challenges only in a linear way. If our pair appeared more confident then we should each take advantage of gaining depth of learning from the task as opposed to the more results orientated metaphor of completion:
It was important for each learner to find the depth within the task. Ed had shown with his explanation of Bloom’s taxonomy: teaching is part of learning. This different way of looking at progress really resonated with the yoga teaching and meditation at Makers. It was not necessary to ascribe to the no-pain no-gain school of learning. We should be comfortable with our current place in life and embrace our situation while also seeking to improve. This promised provide a more model for self management.
With this in mind, Ed led the discussion regarding our experiences of using git. There were various challenges such as the difference between Http and ssh keys, initialising in the correct directory, using echo to add to the file and avoiding writing over files. We discussed these and Ed offered clear solutions for each of the issues. One particularly interesting point regarded the difference between branches and origin in the command push -u origin master. Origin is the arbitrary name set for the first upstream repository. We can set any name to a remote but origin is the normal name. Master is the branch that you want to access.
Armed with Ed’s advice we paired up and plunged into the challenges for building a Boris bikes app. The primary goal of this task was to test drive object oriented code in ruby. Could we use Test Driven Development to build a docking station from which clients could hire bikes. The advantage of TDD was that it would tie us into a tight feedback loop completing the minimum amount each time to complete the test. One important point that Ed made was that we could use spiking or playing in the Interactive Ruby Shell to work on the code. As we had seen the real challenge was to use the task in order to learn deeply. We would choose a repository from Github to work with and then clone onto each other’s repos when necessary.
The situation of being involved in a project threw up a number of interesting issues. One of the hardest aspects of the day was trying to develop a clear idea of what was needed in order to fulfil the user stories for the Boris Bikes program. It was difficult to conceptualise how each class should interact. We carried out a useful exercise in which we built a functional representation of the the uer story by extracting the objects or nouns from the user story and the verbs or messages that we wanted each part of the program to carry out. One point that we took a bit longer than perhaps we should have realised was that the person is in fact the user and so doesn’t necessarily need to be included as a class in the program. We also took quite a long time working on less integral tasks such as drawing a diagram of the interaction of classes rather than getting a fuller overview of the challenges and then perhaps pushing ourselves to write effective code.
At the end of the day, Sam introduced an excellent tool for enabling rich feedback and self reflection. The application which we would fill in each day asked us a series of questions such as: “What specific things did you do today?, What was the hardest specific thing today?, Why do you think it was hard?, What could you do tomorrow to make it easier?”. Our responses to what we found difficult would then be emailed to us at the end of the week so that we could evaluate our progress and develop.
The feedback session was helpful because it enabled my pair partner and I to examine our progress. It seemed that we were not quite getting the maximum juice from each task. In our work we had stuck rather too closely to the pomodoro system which seems to work well when you are working alone but is less effective when working in a pair as it is important to build a momentum over a longer period. In hindsight, my partner and I could have worked more effectively as a team to pass through the confusion and develop a tight feedback loop for progress. One aspect of the pair work which I needed to explore was how far to split tasks to ensure good use of time. certainly, we could have split tasks and dedicated more time to reading the materials. We were, perhaps, a bit too focussed on the presentation of the task as opposed to really engaging with the broader issues of the challenge. We ended the day with a clear sense of what we needed to do to progress both in our coding skills and also in the difficult but rewarding art of working as part of a team.