Tag Archives: pair programming

Why should you facilitate Code Retreat?

Less than a week ago was another Global Day of Code Retreat. Few thousand people in few hundred cities spend a whole day working on improving their skills. That part doesn’t seem strange anymore, devs are doing such things all the time.

But during after party one of the participants asked me why am I doing it? Why spend a lot of time and effort on something nobody pays you to do? Participants have obvious benefit – they get better developers, they learn. Some openly admit that they treat it as a free training. But what about organizers and facilitators?

That question caught me off guard. I just wanted to organize this Code Reatreat for a while, even since I moved to New Zealand. But why?

1. Teaching (or facilitating) is a great learning tool

Some people think that teacher or trainer or even random CR facilitator has to be an expert and surely knows more than people who are “just” attending the event. That might be true, but more often it is not.

There is a good reason why it is said that if you want to truely learn something you should teach it to somebody else. Facilitators learn a lot during the day. Maybe sometimes even more than participants, because they have more time to observe and analyze approaches of multiple pairs. They see various approaches, compare them, think about them, try to come up with good questions.

We know there is more than one good way to solve a problem, but unless we have a big group of people working on the same task, we don’t realize how different ideas people have. Then we can discuss and compare multiple solutions, see their strenghts and weaknesses. This does not happen often at work, because we don’t give the same tasks to multiple groups.

Being a good facilitator is not easy, you have to practice asking smart questions – those kind of questions that guide, but don’t give away the answer. Also by trying to help people you have to organize your knowledge better. You are deepening your understanding of familiar concepts. You see them in a completely new contexts. You have to explain the same thing over and over, in various ways and by doing so, you discover what really matters, you get to the essence. In short – you deepen and distill your knowledge.

Apart from technical aspects, facilitators also have to learn basics of teaching, such as “crowd control” (make sure one person does not dominate the whole retro, try to encourage shy attendants to speak up), clearly explaining new concepts (might seem trivial unless you actually give it a try), providing encouragement, helping to get “unstuck” when somebody just sits there and stares at the screen, finding the middle ground between people “just doing it” and giving the answers away (also called proper guidance).

2. Moving the industry forward

Contrary to what is told, still too many developers seem to finish their education when they leave university. Some need to keep up to date with newest frameworks and buzzwords, but it still amazes me how many people in our industry never encoutered the basics such as proper testing or working in pairs. This is something we are not taught at the uni and not all companies pracitce it.

At every CR there are some people who never wrote tests or don’t feel comfortable with them (yet). It is really amazing that after just 5-6 sessions they say that it was easier than they expected. They discover the benefit of having more confidence in the implementation and are keen to introduce those concepts at work (or just practice it more diligently).

For some this is the first opportunity to try pair programming. Those people are very excited about the collaborative approach, they feel inspired by seeing in how many ways the same problem might be approached by different people, they discover that when they cooperate, the end result is way better.

Many participants commit to promote those two practices at their workplaces.

3. Bringing companies and communities together

In some cities companies are not eager to cooperate. Sometimes they say that if we work with X, they do not want to have anything to do with us. On the other hand, there are some companies that never got involved in community events, but if you ask them they are very keen to participate. Maybe nobody ever asked them, maybe they simply never thought about it. In such a case that might be the way to get them more involved in other activities as well.

For example one of our current sponsors insisted on booking few spots for people from their company. Now they are very keen to organize similar events. Since a few of their employees attended, they are in a very good position to make it happen.

The other thing I really like about Code Retreats is that they are technology agnostic. You meet people using C#, Java, Ruby, Clojure, Python, Haskell, JavaScript… Sometimes that means you just have a quick exposure to different paradigms and make a few interesting observations, but sometimes it inspires you to learn a completely new thing or become a member of another community group. It definitely broadens your horizons.

4. Spreading hunger

A while ago Steven Jobs gave a really great graduation speech. In it he encouraged people to “stay hungry, stay foolish”. I think this is a great state to live in. Always on the lookout to learn a few new things, to get better, to make world a better place. People do not always are lucky enough to be in a job where they have great role models, but they are very likely to meet fantastic people at event like CR.

Sometimes attending such an event opens up a completely new world for somebody. It turns out to be a first step in a very long journey towards mastery. It might be this tiny event that “awakes a hidden software craftsman within”.

Some time ago somebody inspired me and helped me to make that step. I never looked back. Now I want to give it back and share this experience with as many people as possible. I believe organizing CRs is one of the ways to make it happen.

P.S. If you’re thinking about organizing or facilitating the CR, but don’t know where to start, feel free to ask in comments or on Twitter. I’d be more than happy to help!

Pair programming – is it worth it?

I was recently tasked with creating a “quality improvement” strategy for one of our projects. One of the controversial propositions turned out to be pair programming. How are we going to justify this cost to the client? That question caught me off guard. I didn’t even think that might be an issue. I didn’t even think about mentioning it to the client, too. For me it’s just a natural part of my work, like using CVS. I never had to justify doing that to anybody. In fact, it used to be quite the opposite.

Stage 1: I hate it

For me personally, pair programming was very challenging. It was the least favourite part of my work. I am a perfectionist (luckily, recovering one) and ever since I can remeber, I hated people looking over my shoulder when I was working on something. Even when I was in primary school and my mum wanted to check how my essay is progressing, I got aggressive. That’s the main reason why I always insisted on not having anybody sit behind my back. I hated the idea of somebody staring at my screen. What if they saw me doing something very dumb?

Over time, I got pretty good at using various avoidance techniques, altering aggression with jokes and plain refusal. Of course, I could got away with this behavior at home, but it wasn’t professional to say the least. Pair programming was not only allowed, but strongly encouraged by my team-lead when I worked at VSoft. I’ve also heard a lot about its benefits. Like it or not, since everybody around me was doing it from time to time (and I couldn’t really say no, every time they wanted to pair on some task), over time I simply got used to it.

Stage 2: I learn a lot

My first “real” pair programming experience was slightly over two years ago and I can’t believe how much has changed. I don’t mind other people looking at my code. I love it. Getting feedback is awesome. I like getting new ideas to improve my code during reviews. I got comfortable with criticism, use it to learn about different approaches and coding preferences. At the same time, I learned to defend my point of view, discuss the motivation behind the decisions I made and be ok with changing my mind, when reviewer points flaws in my thinking.

I can’t recall specific words, I don’t remember all of those small and big ideas I learned through pairing with other people. Some of them applied only to the situation at hand. But there were a few that I benefit from today, such as testing untestable code (thank you Lukasz for being such a pain in the neck about it, now it’s second nature:)), getting familiar with all the crazy shortcuts, learning about new tools, etc. I’m also much better in giving feedback to sb’s code and learned a lot by thinking hard how their code might be improved or why something “didn’t feel quite right”.

Overall, once I got over this irrational “don’t you dare look at my code” attitude, my rate of learning went up significantly. Besides, I think that my productivity was higher, when I worked in a pair, because I was fully focused on a task at had. There was no email checking or talking to colleauges. I did my best not to waste somebody else’s time. Unfortunately, I don’t have any hard data to support that claim.

Stage 3: It’s not a silver bullet

When people ask whether pair-programming is good or not, I think the only honest answer is (of course) “it depends”. There are some people I can’t pair with. When we tried working together it was simply counterproductive, because we just kept arguing and nothing got done. Working with some others was challenging, but I learned a lot. Finally, when working with some people I felt that magical synergy, we were more effective together than each of us working separately, because our working styles and our typical focus areas were complementary.

So it depends to large extent on whom we work with. It’s good to get out of our comfort zone, but I think that pushing through, just for the sake of activity when it’s clearly not working, doesn’t make any sense.

Then it depends on the task at hand. When the task is a no-brainer or we’re very familiar with the area of codebase we’re working on and we’ve done similar tasks before, then pairing might be a waste of time. For me it was most beneficial when I worked on something very new or especially complicated. I could have asked for a review afterwards, but pairing seemed to be more efficient way than stopping every now and then to discuss my idea with a colleague.

Stage 4: It’s hard to work otherwise

There are two situations when pairing seems to be great, irrelevant of other factors. The first is introducing a new person to the project. I can’t understand why people don’t see how wasteful it is to give a vaguely described task to the newbie and instructing them to “ask when they need anything”. Even if they are experienced developers, it takes some time to understand business requirements and be able to understand the impact of every decision on other areas. We lose opportunity to make sure early on that they follow our interal standards and practices. Not to mention the frustration they experience, when they happily announce their task is finished, only to be told that they have to re-do it because of some stupid catch they were unaware of (happened to me recently a few times, extremely frustrating experience).

The other situation is making significant changes or working on some complex piece of logic. It’s beneficial to discuss our design ideas, pay close attention to implementation, make sure we don’t make stupid mistakes, that can be avoided by using second pair of eyes.

For me the main benefits of pair programming are exchange of knowledge between the devs (both domain specific and regarding tools and skills) and avoiding painful surprises during reviews or testing (Oh, how could you miss that edge case? How could you not know about this email I sent to XYZ half a year ago? Why don’t you know about our super-secret document, where all this is described? How can you not know that some external app relies on this file being in that location?).

At this moment, I can’t think about any more efficient and sustainable practice for continuous quality improvement and spreading knowledge among team members.

Stage 5: Back to square one

So how do you justify to your client not doing it? Is there any more efficient way for achieving the goals I’ve just mentioned (improving quality, mentoring, sharing knowledge, avoiding bugs)? Is pairing something one should discuss with the client? Should client be allowed to make such decisions for us?

For me the only honest answer is that I can’t justify not doing it. The other ways for konwledge sharing and keeping high standards that I know, are not as effective (e.g. workshops, presentations). Code reviews should be enough for ordinary tasks in an experienced team, but even for them, I think the two situations mentioned in Stage 4 are still relevant. When it comes to clients I believe that it’s my job to be the best professional I can be and client shouldn’t decide on standards in our industry.

I think this is true not only for software. For example, I don’t go to the dentist and tell him he shouldn’t have an assistant, because I have to pay more for the service. I trust that they do their job well and that this is the best industry practice. I also suppose that if they worked alone, the overall cost would be much higher, they would do the same task longer with more mistakes and caused me more discomfort. Better service for less money? Even if not true in every case, I think this is more common than most people realize.