A Team of Champions

Fair warning:  I just read “Quiet: The power of introverts in a world that can’t stop talking” by Susan Cain and this blog post is heavily influenced by that.  She did some spectacular research and presented it in a manner that went down very well with me.  She even used some specific software studies as examples.

One of the rallying cries of a (somewhat) local sports team is “A champion team will always beat a team of champions”.  This clever play on words makes us feel warm inside thinking that if we’re connected to the mass, that all of us is somehow better than each of us.  We are indeed social animals.  The main point of the opening chapters is that actually, studies suggest that while we feel like we do better in a group situation, we actually do better alone.  And more worryingly, that if we’re in a group situation, we don’t just go along with the more vocal person for the social acceptance, believing deep down that we’d chose a different answer if it were up to us, but that the social pressure actually changes our perception entirely.  So I’d like to pick at my previous post a little, with this new information.

Now, I’m not totally reversing my standpoint having read the latest literature.  I still firmly believe that most software is too complex to be written by just one person (especially in a commercial environment, where marketing executives fight for shiny new features like deranged magpies)  and that collaboration is the key to a successful product.  But I think I’d like to change (or at least expand upon) how we might arrive at and go about the collaboration point.

And just before I get to the heart of the matter, I will let you know that I see myself as what Susan describes as a shy introvert.  I’ve even been diagnosed as having Social Anxiety Disorder (by medical professionals, not Dr Google).  So while I might appear to be a confident software developer – that’s my natural environment with rules I understand and can deal with.  Put me in a room with that same software peer group in a social context and I stand in the corner like a mute idiot (often squeezing my fingers as a nervous outlet for the stress I’m feeling).  Put me in a room with people not in my peer group and I’ll likely remove myself from it.  Quickly.  Oddly though, giving presentations (about software) doesn’t phase me too much. (Susan does explain this dissonance quite well, though).  This is important information, because it clearly places me as biased towards much of Susan’s material, as she was talking up the importance of introverts like myself.

The crux of the issue, according to Susan and her research, is that introverts perform better with less external stimuli than what extroverts require to function effectively (and vice versa).  So my team sport idea works only to an extent.  Many introverts (including myself) are not anti-social, we’re differently-social, in that we require less social contact and find large groups of people draining, if not terrifying, but still enjoy the presence of other human beings.  Working in a closed off office somewhere doesn’t appeal to me at all.  Though at the same time, I do like my privacy as well as the opportunity to talk to my colleagues.

This helps to neatly explain why I can concentrate better when I have headphones on, listening to music.  It reduces the external stimuli to a manageable level for me – merely having music in the background would not have the same effect (and might make the dull roar worse!).  I can effectively block out the background chatter and replace it with something I find pleasing to listen to.  Oddly though, when I’m in the throes of coding, I rarely have any idea what music I’m listening to – so long as it’s not music I don’t like.

Susan suggests that, fundamentally, creativity is a personal thing and I have previously pointed out that I believe that software is a fundamentally creative vocation so does that mean that we do our best work on our own?  I, personally, have never felt that putting together a basic design was something that has gone well in a group situation.  I’m much more interested in preparing a design on my own and then bringing it to the group for critique.  I feel almost foggy in a group situation – probably because I’m too busy trying to figure out the social cues, rather than focus on the design.

But I haven’t heard of any studies which find design is a group activity.  EXtreme programming certainly down-plays design by committee, preferring a simple design and a metaphor to ease the communication overheads and lack of efficacy vocalising a design.  Though we instinctively already knew that.  Every single meaningful design discussion I’ve had has involved a picture of some sort, or, a design pattern, where a large portion of the purpose is to communicate large quantities of information without saying very much.

Of course, eXtreme Programming has some very strong views against this solo concept.  Pair programming, which I personally think produces better code with fewer problems, because we are constantly reviewing.  Yes, very often we’re pointing out compiler errors – but that’s the programming equivalent of small talk.  Small talk often acts as social grease, giving the trust to delve into the more meaningful conversations, like  how to use that portion of the API that only one of the programmers knows or why doing a lock-read-unlock-do_stuff is often worse than simply reading a volatile value without mutex protection.  That sort of thing has a side-effect of helping us to become better software developers long-term, as well as reducing the cycle time between writing that kind of anti-pattern and the feedback, along with the bonus that it’s easier to detect there and then, than when performing an asynchronous review.

So my question is: Is it just the simple one-off tasks upon which the studies are based which are only performed better alone, and more complex ones (such as writing software) more effectively done in pairs (any more than that and you’d start losing efficiency very quickly)?  Or, are we really blinding ourselves with the ‘New Groupthink’ and programming is actually better done on our own, with the optimum level of stimuli?


About Michael Malone
30-something web dev, self-confessed Linux lover, Ruby enthusiast, and obsessed with programming. Former embedded C and desktop .NET developer.

One Response to A Team of Champions

  1. I find that mechanical programming (where you basically know what to do and just need to get it done benefits from pair programming, because mistakes are noticed, bad practices are stomped on before they can develop etc.

    However for deep problems, for design, for things that require a far amount of thinking, In a pair programming situation I feel pressured and rushed. I can’t let my normal thought process run it’s course and so end up making poor or even ill conceived decisions. Or even just blindly go along with whatever the other person says. I prefer to be able to take my work and work these thing through on my own.

    Once my thought process has run it’s natural course and I’m either still stuck or want my conclusion validated that’s when I benefit from being able to share with another developer.

Comment on this

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: