Archive for February, 2008
One of the intriguing aspects of pair programming for me is that of the non driving person in the pair – what are they supposed to do?!
Obviously there are fairly well known strategies for more interactive pairing, such as Ping Pong and Ball and Board (which is where one person controls the mouse and the other the keyboard), but neither of these strategies suggest what to do when you are not driving
Obviously it is very easy to be a bad non driving part of the pair, by getting distracted by what’s going on around you and a quick fix that I’ve heard to solve this is that when you’re bored, ask for the keyboard back. This solves the immediate problem but still doesn’t make you any better at contributing when you’re not at the keyboard.
One idea that I’ve been playing with recently is keeping a list of the next task that needs to be done after the current one is done – effectively just tracking where we are on the story. We use tiny tasks for most stories as laid out by Patrick Kua. This does work although you still don’t feel that involved, and it can end up seeming like you’re dictating to the other person what to do. This is definitely an approach to be applied with some tact.
Some of the more skilled non drivers I’ve worked with have the ability to see the bit of code being worked on as part of the whole and are able to see when we have gone too far down the wrong path and should actually be making changes elsewhere. I find this a lot harder to consciously improve, and I’ve been told it’s a skill that comes with experience.
I’m sure there are other roles of non driving that can be applied, mentoring being one, although that’s for another post! Thoughts?
One of the more interesting concepts used on the NLP course that I did last year was the idea of only giving positive feedback to people.
The thinking behind the theory (which I think comes from Robert Dilts, one of the early thinkers behind NLP) is that people know what they are doing wrong and already beat themselves up about it; therefore there is no point you mentioning it as well.
I was initially sceptical about this approach as it seemed a bit too idealistic for my cynical mind. I found it extremely difficult to start with and didn’t give any feedback to anyone for quite a few sessions. Eventually though something clicked for me and by the end of the 18 day course I feel I did gain a greater respect for and recognition of the talents that other people on the course had. The need to focus only on the positive actually seems to drive the mind to see more in this area than it otherwise would.
Although noone likes it when they are criticised, I think there are some occasions when someone criticising you can prove to be extremely motivational. This basically involves them completely writing you off and you then being determined to prove them wrong. For example at school I was told that I would definitely fail the Pure Maths modules of my A Level Maths course. Completely unimpressed with this verdict I persevered with it for months eventually scoring 85%. Job done.
I think sometimes when giving critical feedback it can say more about you than it does about the person you are giving it to, and this is where it’s vital to step back and think why you are giving the feedback.
I find at least for myself the tendency is to want to point out things people do that annoy me, which in effect is me trying to make the person more like myself. Steve Pavlina suggests that the things we hate the most in other people are the things we actually hate in ourselves. Therefore his suggestion was if you find something someone else does annoying, first look at yourself and try and improve yourself in this area.
I’m not sure if I totally subscribe to why this approach would work but I definitely agree that it is way easier to change yourself than it is to change someone else.
I’ve had the opportunity to have worked with many different people pair programming wise over the last year or so, and having seen it done in several different ways thought it would be interesting to work through some of my thoughts about this Extreme Programming (XP) originated practice.
First of all it seems to me that pair programming is a technique that is used with a lot more frequency at ThoughtWorks than at any other IT organisation.
Obviously I do not know every IT organisation in the world, but based on discussions at the ALT.NET UK conference I went to last weekend; it certainly came across to me like that. The difficulty in getting clients and/or management to see the value in having two people on one machine was the main factor mentioned as proving problematic.
I have been working for ThoughtWorks for 18 months now and have been pairing for all but 3 of those months. Perhaps contrary to popular opinion, not every project is a 100% pairing one.
I’ve paired with people for 20-30 days at a time, paired with people for 1 day at a time, paired with people who have been pairing for years, paired with people who are pairing for the first time, and all in all it’s been fun.
I now find writing code far more enjoyable when working with someone else, motivated by the opportunity to bounce ideas around and come up with better solutions.
The biggest benefit for me of pairing is that you have to vocalise your ideas to your pair. This massively reduces the chance of going down a dead alley as a ‘wrong’ idea would have to somehow make sense to two people, which is much less likely to happen.
Equally, when done well, you end up thinking a lot more about why you are doing things e.g. why should that method go on this class, should we introduce a new service, why are we testing it in this way, should we be testing it another way etc.
On the flip side there are times when you just want to look up something which interests you but isn’t totally relevant to the current task and that has to be placed on the backburner for the time being. Pairing can also prove very tedious when doing fairly trivial tasks such as changing configuration files; although of course it does help if every knows how to do this so pairing on these tasks does provide some benefit.
I will cover some of my other thoughts in future posts.
I’ve always been the type of person who only gets the motivation to do something if there is some useful practical reason for doing so. It therefore probably doesn’t come as much of a surprise that I hated the majority of my mostly theoretical computer science degree.
I was talking to one of my colleagues last week and came out of the conversation convinced that the desire to know the theory behind concepts is amplified when you actually get to see it in action in a real life system.
My prime example is multi threading and concurrency. At university we had to write a program to calculate e to 500 decimal places using multi threading. In my mind this exercise was completely pointless, and I don’t think I came out of it any wiser with regards to threading.
Contrast that to the project I’m working on now where the main window of our application was freezing up due to an expensive operation being run on the UI thread. The solution of course was to execute the expensive operation on a background thread.
Although I know this is a fairly trivial example, it did provide a real life situation where threading was required. As a result of this I have become much more interested in the specifics of threading and the potential problems that can arise when doing so.
It would probably actually prove more useful to see the concepts in action in a real life system before being taught the detailed theory behind how it all fits together. For me at least when I’m learning about something I like to have a reference point and having seen the concept in action would provide this.
It seems obvious to me therefore that studying for a degree after having first done a few years in industry would probably lead to you having a much richer learning experience and a much improved understanding. Not that I expect that to catch on!