Coding has always been seen as lone-ranger work; witness the opening scene in The Social Network. Despite managers’ dreams of programmers as fungible units, it’s nearly universally accepted that a great developer is ten times as productive as a mediocre one, and/or that a small team of the software equivalent of the Special Forces can code rings around an army of hundreds of grunts.
Link: Pair Programming Considered Harmful? via TechCrunch
I don’t agree that pair programming is harmful, but that’s because it’s so unique to each team and the developers involved. I would imagine that every team, every pair, approaches it differently.
At work we’ve recently been moving toward doing more pair programming within our team of four. So far it’s been been very helpful and productive, and it’s slowly knocking down the silos of knowledge. Then again, I’d say we only pair about 20% of the time.
The article’s author mentioned scenarios where the team paired 100% of the time. Honestly, that would probably be very difficult for me. In fact, it sounds like pure hell. I enjoy collaborating and having teammates but having to sit side-by-side and work in tandem with someone for 8+ hours a day? The introvert in me shudders at the thought. I need space and time to gather my thoughts and basically recharge. I can’t do that if I’m constantly having to interact with someone.
I am a big proponent of Scrum, and see its benefits each day with our team and organization. However, I do have to wonder how much space there is for introverts in Scrum practice (and modern workplaces in general). Open/shared offices (our entire team shares an office, and our desks are arranged so our monitors are visible to everyone), pair programming, retrospectives, etc. all require a lot of sharing: shared space, time, tasks, and conversation.
As Susan Cain points out her book Quiet: The Power of Introverts, workplaces today are geared toward, and favor, extroverts. Sometimes, with so much emphasis on the “team” in Scrum, it feels like introversion is some kind of hurdle to overcome while adhering to “best” Scrum practice. I’m sure there are ways to balance both worlds, and as I settle in to my ScrumMaster role I hope to find out how.
