Supportive pair programming

So its been sometime since I posted anything ,as I usually do it after compiling lots of related concepts . And yeah ,this blog is for sharing my new experiences and its updates. I've written a previous post with regards to the pair programming method were there is definitely an advantage for the overall work flow. But now that I tried it in a different setting,I think I've came up with a more detailed explanation of how this can be managed in a professional work environment. See, not all developers are friends ,even if they work on the same problem ,there can definitely be an incompatability in the way of thinking , when one developer comes up with a new idea ,if the mindset of the other is cooperative and his interest lies in resolving the problem then it would be supportive but if its a confrontational or self interested attitude of who finds the better solution,then it can be a disempowering and toxic relationship . It is understandable, not everyone is conditioned the same, thus I think pair programming needs to have some rules that guide it well . 

 1- the developer who is assigned the ticket should eventually decide what the action will be , this is in order to prevent unecessary long time in disagreements.

 2- the secondary developer should be supportive and not instructive in telling the one working to do this or that but be inqusitive of what the main developer is trying to do , and sharing the result of this inquiry in real time , he can be recommendative only if asked by the main developer. 

So a sample conversation would go like this :

Main dev : I am trying to implement x .

Second dev : oh so you want to do y here and z there in order to implement this part of x .

Main dev : yeah , thats probably what Iam going to do but I'll need to take care of z first.

Second dev : I see you are trying to create an a in z first to prevent b from occuring .

Main dev: yeah exactly this is what I want to do , then I will connect them all to k .

 

The main concern of the secondary developer should be to understand what the main one is trying to do , thus developing a mindmap of what the developer's thread of thinking is going to create , instead of trying to solve the problem himself .this helps in the merging of interests ,when both devs are interested in the same line of thinking then its supportive to both , the main dev becomes more motivated and gets to explain what he is trying to do which will give not only the secondary developer but also himself a better perspective of what is happening.  

 

A bad sample conversation would go like this :

 

Main dev : I am trying to implement x .

Second dev : this isn't the best approach , you should do y first 

Main dev : I know but it won't work right away unless I start with z

Second dev : I already know that , thats basic programming knowledge and isn't going to work if k scenario happens.

Main dev: okay , oh ! , am not sure , now I have to deal with so much . (frustration)

 

Here the Main dev's line of thinking is not getting supported , and thus he can't take his ideas as far as he would like because of the constant interruption of his line of thinking by giving him a new approach ,and even if the new approach is better , he isn't totally convinced as he still coudn't take his line of thinking to its end .

Of course there are cases where 2 developers have to negotiate on the best practice during lets say pull requests , now one developer knows what he has done as well as the problem well and the other may or may not , thus the requester should similarly concentrate on understanding the reviewer's point of view and vis-versa before adding the comment or explain his position , there has to be a convergence of approach in the end before a merge with release.

In the first time it happened with me ,it was natural, both of us were interested in the same issue and were naturally compatible in the ways of thinking , but as I dealt with different developers I encountered this divergence of interest problem ,were one developer (me or the other) for example wants to show off his knowledge to the other or is interested that he is the one who comes up with the solution and when anybody else does it, it becomes threatening . So supportive pair programming starts off as shadowing were one developer is trying to know what the other is doing , empowering both and thus helping their interests converge on one thread of thinking .