Programming with your CEO
Business is why we build software. If it weren't for ideas that bring value to other people, then software wouldn't exist. Programming has a lot of jargon, a language not accessible to non-specialists, that is not easily understood by all. But if we were to work with non-specialists, they should understand what we are doing as well, as long as they know the business. So, in this section, we are going to discuss some aspects of improving our interactions with our peers.
Social programming
We may want to improve the social interactions inside the team, and pair programming is a good practice for that. While working on our computers, we must remember that we work for and with other human beings. Quite often, and unfortunately not always, the code we write will be used in a direct or indirect form by many people. So, it's important to also remember the social aspect of programming.
At the same time, our team, our product team, and our organization are made up of people who can learn and teach many interesting things. Because of this, we can take advantage of this and use pair programming as a way to learn faster from our peers.
Social programming means that we want to learn, share, and work with other people, explaining what we know while being humble and learning from others with openness and curiosity. Pair programming enables all these, as we can take the opportunity to learn and share. This mindset is extremely beneficial for all the team members, as it fosters continuous overall advancement in all areas.
Pair programming is a tool that's very appropriate for social programming, as you're trying to improve the social interactions of a team. Often, people think about pair programming as a tool to code together, to minimize defects, and that's it. But almost half of the activities I do as a technical coach with teams have to do with soft skills, social skills, or human interactions.
It's important to know how to talk to your colleagues, give and receive feedback, and communicate with other roles or managers from the rest of the organization. I always ask programmers: how would you explain this code if you were to pair program with your CEO? This situation might sound funny or absurd, but if you can clearly explain to a CEO, without the whole technical jargon, what that code is doing, it means that you know what you are doing really well. And it also means that you have excellent communication skills.
As a side note, during a community event that I was facilitating, while the programmers were pairing, a CEO appeared. He heard about this event and he was curious what was going on. Nobody had any idea about his role, and he joined, paired, and discussed just like any other attendee. Only after the event did I find out that he wasn't really a programmer. Imagine if you behaved the same if you knew that your CEO was joining you during a pair programming session. This is a good example of social programming, even without programmers being involved.
The rubber duckling effect
One particularly interesting way of using our cognitive structure is by utilizing the rubber duckling effect, or teddy bear pair programming. A debugging study that was performed with students in 2012 showed that when we have a problem, the best solution is to verbalize it. When explaining our problem in detail, our brain works in such a way that we start finding the solution for the problem at hand ourselves. Apparently, we don't need to talk with someone to give us advice; rather, we just need to talk, even alone, and in most situations, we'll find the solution ourselves:
Pair programming takes advantage of this quirk. A good practice is, even before we start coding, to explain to our partner what we want to do. If there are gray areas where we don't have an answer, we will find an answer just while talking. And for the majority of the areas where we really don't have an answer, our partner will help us. Typically, during a pair programming session, we either solve all the problems in the beginning, or while they appear, or we have a blockage and we need to talk to our colleagues. The first situation occurs far more often, but there are situations where we'll need to have a break or have a discussion with other colleagues.
Of course, we can use the rubber duckling effect even without having a person in front of us. I personally use a teddy bear and I explain what bothers me. I know that it may sound weird, but you need to try it for yourself without a lot of judgment. You will see how much it helps.
Yes, it sounds silly to talk to a rubber duck, a teddy bear, or your favorite toy animal, but it works. And hey, reach out for your inner child and think about playing a bit. Being playful is a lot more useful for our imagination than being serious. Often, good solutions come when you start playing and open the imagination door.
Next, we will learn how to use pair programming within our respective jobs.
