Hello World!

While driving to work one morning last spring I was listening to a political program on the radio. There was a debate about a report the government has presented to Stortinget, the parlament. Two politicians where in studio, one from one of the governing parties, and one from the opposition, from the concervative party. What struck me was how unwilling the person from the side of the government was to listening to critisism.

Naturally I wrote it off as her being a politician, not willing to see the other side of the matter. But somehow it sounded like there was a bit more to it.

After a while it struck me – she had probably been involved in the work to create the report, and the other side was picking it apart, saying that the handcraft of the work was not very good. On some level she must have been reading the attack on the report as an attack on herself, probably unconciously. So she became very defensive, and would try to attack the opposition instead of answering the critizism or admitting that they could do some things better.

This made me think about how we work in software development. A healthy development process should always encourage team work using tools like peer reviews and formal tecnical reviews, and maybe even doing the coding together in pairs or teams.

The idea behind this is that more minds are better than one. Even if I am very good in one domain, I might not always have the best idea. Having someone looking over what I design or code, could trigger an idea in their mind, an idea that I never would have thought of.

But when these tools haven’t been in use regularly, you risk ending up in a situation where people have very strong feelings about their own code. They would object if someone else suggested any changes or wanted to remove their code – not because the change or removal is wrong, but because it makes them feel bad.

It’s not hard to understand those feelings. I know that when I have worked hard on something, it don’t feel good to learn that there is no longer any need for it. But that is the reality. We have to be agile and allow for change when making software, that also includes living with the discovery that something we’ve coded no longer is needed.

What’s important is to not let ourself or our self worth be defined by what we code. If someone is criticizing something I’ve coded, I should listen to it and allow them to come with their thoughts about it – not take it as a criticism of me as a person.

How can we get to a state where this is natural? I believe that having regular code reviews and shared ownership of the code would help getting people out of their silos. If we can get in the habit that all code is something we can improve on, and direct our pride against the wellness of the complete code base and the great working end product instead of the “brilliant” pieces of code that I wrote, I think the end result will be much improved.

Basically I think it comes down to having a strong team feeling.