It has been a shorter work week due to the Spring Bank Holiday and Platinum Jubilee holiday giving Brits a four day weekend. We have tried to cram 4-5 days work into 3 days but for me it has been quite a lot of friction collaborating on a particular feature.
This was my first encounter with peer programming and not a task I excel out. Peer programming can provide great benefits for all those involved, both workers can learn from the experience as they look to come up with a coded solution together. The process could help reduce procrastination and mitigate lone-worker ethic: both are common when working independently for those at the start of their careers. If things turn out well, it looks good on technical management as the peers build confidence in themselves and diverts attention away from seniors freeing them for the usual meetings and more complex development tasks.
Unfortunately, I am not seeing these benefits just yet as the issue extends into its fourth week (second sprint). To be honest, we should have broken down the ticket into separate smaller steps to make the problem more manageable to solve and delegated the responsibilities formally. The background reading required to perform some of the tasks although comprehensive, is time-consuming and it is difficult to find that balance between just enough information to do the job or at least extrapolate use cases, and too much information that is not all applicable to the problem at hand. We didn't have a clear plan on who is responsible for what tasks as both workers were researching for ways to resolve the issue. This led to time spent chasing the 'rabbit-down-the-hole' without much meaningful progress. Moreover, the drip-feed support from seniors was done to steer the course to completion but not give all the answers to the peer programmers. Seniors found themselves repeating their explanations and this was likely due to lack of communication from the junior staff. Ultimately, two separate branches for the same feature have been created effectively double handling the work (admittedly one branch has progressed significantly and now it is this branch that is being committed to frequently for the ticket).
Reflecting on the journey, I think it would be beneficial to peer program with one junior and one more competent developer. The more experienced developer can set the pace of the ticket by delegating out tasks appropriate by complexity, duration and what each peer stands to gain from that task: if the more competent developer knows the process and does not gain anything meaningful from that task then it could be a good idea to pass this on to the junior. Currently, I am collaborating with another colleague at the same level of knowledge and competence which makes it difficult to find solutions because we are both lacking in experience and context around managing a CMS and its intricacies. We will both attempt a trial and error approach which when unsuccessful, can be frustrating and demotivating very quickly. It feels like the blind leading the blind at times. It's not long until the progress grinds to a halt and the mental bandwidth is exhausted for the day!
What I think this boils down to is clear, frequent communication channels and managing ego / being humble. Regarding communication, this is important as it is so easy to break off on your own path and try to resolve things yourself and your focus is pulled away from the tasks that you agreed to do from the start. It's important to remind yourself that the completion of the ticket is a benefit to both and there will be some of the process that you missed out on as a learning opportunity. But this shouldn't be an issue if there is good documentation as an informative MR or even just discuss the steps that you weren't involved with, as a way of filling in the gaps for your learning journey.
Dealing with workers personalities and getting them to work fluidly towards a common goal is the hardest thing for management, but also for the workers to come to terms with and realise when they need a change of attitude. You could expect someone with traits like being humble, proactive approach, sociable and diplomatic in nature, clear communication would then come naturally. Unfortunately, I don't have the magic answer for managing arrogance / being humble. Something about working close to the machine, you begin to develop an attitude of answering short but coldly to others. When you adhere to the arduous, systematic nature of the program because you have been stung many times before, yet impatient others skip some of the steps and you are left answering the question: "Why does it not work on mine, but it works for you?" (or vice-versa). This blunt, literal fashion can come off as dismissive, unhelpful or condescending.
All I can say is that we were all beginners at some time in our journey, and we probably have been on both sides of the conversation during peer programming. When you feel the communication is breaking down, it may help to remember to stay humble and open-minded.