Good idea!

How often does someone in your team say that?  If the answer is “never” or “rarely”, then you may have a problem.  It sounds trivial, but it can point to an underlying dysfunction within the team.

If a person never acknowledges a good idea by someone else on the team, that means an idea could shrivel and die.  Ideas after all, can be a fragile thing:

“A new idea is delicate. It can be killed by a sneer or a yawn; it can be stabbed to death by a quip and worried to death by a frown on the right man’s brow.” – Ovid

Also, it probably points to something about the person who doesn’t want to acknowledge other’s contributions, or who wants their ideas to be the ones that are taken forward.  Working with someone who thinks their ideas are always the best can be tiring and unproductive.  “My way or the highway” does not make for an effective team.

Of course, not every idea is going to be a great one.  It can be useful to have an “ideation” phase of a meeting, when you generate ideas, then a “refining / prioritisation” phase, where you group similar ideas, and vote on the best.

Ideas being the rebellious scamps they are though, don’t always pop up neatly in meetings.  If someone has an idea, and you don’t think it’s a good one, then it’s possible that you may have misunderstood the intention of the speaker.  Instead of immediately shooting down the speaker’s notion, try saying something like “That’s interesting, I hadn’t thought of that approach.  Could you give me an example of that?”.

That acknowledges the idea, and shows your interest in the concept.  If you can think of a scenario where that idea might not work, instead of saying “No, that won’t work.  In case X, piece of code Y would would fail.”, say something like “What would happen in case X?”.  It asks the proposer to tease out their idea, and they may actually have a solution to that  in mind.  If not, then the proposer will realise, but they will still feel that their ideas are worth discussing, and are valued within the team.

Habits for Successful Pair Programming

Pair Programming.  Most of us have heard of it, some of us have done it, at least at some point.  Although this technique has been around for a while, it’s taken some time to start to gain mass adoption, it seems.  Sometimes you hear anecdotal stories of people saying “I tried it once, but I didn’t like it”, or words to that effect.

Pair Programming can be challenging.  It can be more enjoyable and more productive, but also more tiring than just developing code by yourself.  You can’t do it all day, every day.

After reading some of the literature around Pair Programming, I devised a (Google docs) “Seven Habits of Successful Pair Programmers“presentation for my team, for what I thought worked for us.  When some new people joined the team, I revised it again, in the light of two years experience of pairing.

There’s nothing too surprising in the presentation.  You’ll probably have encountered most of these things before.  As ever though, the practice of these things is the key.

For example, the “Take a break every hour” advice.  It’s not always easy to persuade a developer, who’s excited about their latest idea for the feature, to stop what they’re doing, and disconnect for a while.  Ultimately though, if you don’t take enough breaks, you’ll get tired, work will become less enjoyable, and you’ll probably start making mistakes.

See what works for you.

What this is for

Hello everyone.  I’m going to put some thoughts on software, Agile, the nature of group working in teams, and human interaction here.

The focus won’t be so much on amazing coding.  As someone (Was it Robert C Martin?) said “I’m not a great coder, I’ve just got great habits”. So, this will be more on where I feel the challenges lie.  Namely, the human side!

After all, we’re meant to value

Individuals and interactions over processes and tools

but I’m not sure how often we manage to achieve that.