As with all of my professional work, I'd like to start by setting the right expectation for what’s about to happen. I am a human being, I work in code and currently find most of my day working remotely with very little in the way of interaction with any other beings other than my caring wife, children and two loyal dogs. Yet, not since I left the mad over corporate world of big organisations have I felt more alive, more human and more open to idea of arranged social interaction. Maybe my mood is sweetened by actually sharing my time with those I like to, not an endless blur of anonymous faces on tubes and trains that god forbid you should ever attempt to initiate a conversation with.
Scaling down into an organisation of Appnovation's size over the two years plus I have worked here has been an interesting journey, one that allows me to have become human again; I have an influence and shape my own future. Yet, I have tried to keep the best and more efficient methods I have observed, practiced and adopted into my work from previous roles. One such concept that is yet to get real traction in smaller setups though is the practice of pair programming. Barriers like geographical distances and time zones of course have an influence, but the benefits of working in direct collaboration with a peer has significant effects not just for project success, but for business development, sharing of skills, learnings and experiences from within our own localized development teams. Such knowledge and evolution is absolutely golden in my opinion.
However, as a human I am a little grumpy at times, sometimes dare I say even difficult to be around when immersed in my daily work, so the concept of spending time around other potentially grumpy and introverted individuals may seem a little crazy, perhaps even counter intuitive, but now 12 years into my professional career I am acutely aware of several principles that make such concerns seem a little insignificant. I'll go through them in turn from a development prospective.
We are what we do, therefore excellence is not an act but a habit.
We’ve all heard the saying: “Practice makes perfect.” There’s not much more to add to this other than that.
Everyone and anybody has something to teach somebody else.
This is quite an interesting point to kick off with; there is of course obvious logic here. There are tips, tricks around coding, working habits, specifics of languages and applications that you can learn from anybody, regardless of their experience, CV (resume) history or face value qualities. It's also prevalent that life knowledge and how an individual may face up to a particular challenge, in whatever form that challenge surfaces may highlight new ways of thinking, working and ultimately delivering.
Working with different people or groups can definitely help, tackling challenges or tasks from different angles from how you may have done so before. It can add a new perspective to your way of working, something you may only have even possible read about before or heard of from various other sources such as coding meet ups and so on, but without being exposed to it, without being part of it you can never truly adopt or dismiss such an approach, it makes you evolve, you learn, you adapt, it doesn’tt have to mean you mirror exactly what the individual does, but there might be a golden nugget of information that you take away and make your own.
Competing rather than collaborating will create a negative result.
In my spare time I'm a keen football coach (soccer coach to my north American friends), this statement is easier to explain in that environment. During a game of football, I'm constantly evaluating the opposition against my own team, looking at their strengths and weaknesses and how they weigh up to mine, is there something I can exploit in order to get the right result at the end of the game. This principle works for competitive games, but during training and more importantly during my coaching capability experience, such approach is a little false. In the scenarios where I work with other coaches, whether that be from within my own coaching team, or out at workshops working, talking and interacting with other coaches from other teams has a greater bearing on my own teams performances. I learn much more from people in the same position as me, that face the same challenges in competitive games that I do, but approach them in different ways to get the same result is valuable exposure to aid my in my development. If I take those learnings back into my competitive games I find the path to the result looks a little different to what my own initial version would have been, more times than not adding some margin of improvement on what is already a very polished setup.
Take that same concept into a development environment. As we are all working to deliver great projects, to make our clients really excited about the work we do and how we do it, and move the industry and its capabilities forward, then the sharing, pairing and collaboration approach becomes an obvious concept.
Part of this learning is accepting criticism, accepting defeat is part of that, and that’s a lesson found most applicable to pairing. Joining any kind of working group is not always easy for humans, we seemingly prize individuality, but becoming a real team player as a known quantity, who is open to communication (note: that doesn’t have to be a positive track record on delivery successes, the most interesting and knowledgably people I have worked with have all at some point been involved with the failed project of sorts and come out with some great insights from it). Learn this collaboration skill, and you will be that rarest of developers: one that people want to pair and strive to work with.
Dwelling on mistakes kills productivity.
Now, just to be clear. The difference between dwelling on errors and focusing on improvement through removing them can be defined as the difference between two attitudes. One says, “Next time, I will…” The other says, “If only I had…”
This is something that carries over not only to pair programming, but also to your own individual coding – it's in pairing where it's real benefit is experienced, because it's in pairing that the temptations to focus on an individuals mistakes, to make excuses for your own past code, to reinterpret your thinking processes through rose-tinted glasses, and generally to present yourself in a more flattering light, are multiplied and magnified. But if we remember that mistakes cannot be changed, they can only be learned from, we can let go of the need to do any of those things, accept that they are in the past, and move on with what we can accomplish today.
If you can’t explain something in multiple ways, you don’t really understand it.
One my earliest memories of any other developer coaching me, and one that sticks the most in my mind after all these years was a saying he kept throwing consistantly at me: “try explaining it to a child”. Now consider the everyday tasks we do and the various individuals or groups we face off with, a misconception would be that explaining something to a fellow geek is the easiest of all, most of us will fail as we fall into the competition vs. collaboration approach, if I can outsmart you therefore I am greater than you. But then try explaining again to your PM, then the BA, then the QA, all have very different core skills and therefore different levels of technical understanding, you may and will need to explain a challenge or solution to multiple parties that all need to understand whatever it is your explaining in different ways, if you can't explain so that all parties take away an improved knowledge base, than pair programming is not for you.
However, it is clear from many disciplines that one way to gain increased understanding is to attempt to articulate understanding in response to prompts, questions and situations where collaborating with a colleague or client (of varying levels). For many, it is this very articulation, the requirement to put your understanding into words so that others can comprehend that deepens your own understanding further.
The more you try to do this, the better you will get at it. Additionally, the more differences in a group of people you teach, the more different ways of learning and modes of skills acquisition you encounter. Your own gains thereby become a facility for understanding the mental models underlying the direction a colleague’s questions might be coming from, and you can address yourself to the mental model in addition to answering the question.
Remember that one aim as pair programmers is to improve both how we code and how we pair effectively, so try working with different roles not just the more comfortable immediate colleague.
Recognizing that different people learn in different ways will become instinctive with repetition and exposure and we can tailor how we engage with people to pair with them most effectively. The more you pair, and the more different people with whom you pair, the more broad your experience for effective pairing will become as you explore different options for engaging with the challenge faced.
Talking is not a replacement for doing.
Let's take any example of a challenge you face today, think, and talk through approaches, always with a view to how those thoughts will ultimately be implemented. When it comes to action, the carrying out of our chosen course needs to refer back to what we agreed. Should a new approach become apparent, we do not plunge forward with it, but we consider the implications of progressing down the newly revealed path. This consideration may only take a few minutes, but it needs to happen.
Following from the point about repetition, above, if all we do is talk, all we’ll get good at is talking. We need to do in order to get better at doing. And therefore, to get better at pairing, we need to pair. We need to pair effectively, and inspect and adapt how we pair so that next time it’s an even better experience.
Calm is not the same as slow.
You will, I am sure, have heard of the state known as being “in the zone” as a desirable position to be to achieve high productivity. But this can be easily broken by distractions in your immediate surrounding environment: interruptions from colleagues; loud music; alerts popping up on your screen; family calling at inopportune moments; lunchtimes; and numerous others. Techniques for not breaking the flow state once it has been achieved are vast, but most of them require the elimination of these potential distractions, which could provide inherently difficult.
It's worth noting at this point that being in the zone is therefore a hard state to achieve and when attempting to achieve such a state it can be frustrating when a distraction occurs. The same logic applies to pair programming, in fact it is example one, an interruption from a colleague that is the very essence of pair programming. Let it happen, stay calm, assist as necessary. You may think the interruption may make you feel like you have an anchor holding your work back, but by recalling all the other observations made you will soon learn that slowness is only a perception from yourself, you never know, the interruption may be just what you need to help achieve a goal.
To close.
We generally know when we are at our most effective, but often ignore other aspects of what makes any particular working session productive or otherwise. Once in a while, it can be useful to step back and look at your process, inspect it and see if there are any improvements that we can find to make. Looking into the circle of our colleagues and peers for input into that can help enormously.
Share this Blog with colleagues
