Archive

First we had a workshop in our office with two visitors from one of our offices in France. We had a lot of issues to discuss, and once again the value of face to face conversation over lengthy email discussions was evident. Though all problems are not yet solved, we have a made a plan which hopefully should get us to a solution, particularly now that we all have sat together and gotten closer to a common understanding of the project.

In addition, the last two days of this week I have attended a training course in “Advanced Presentation Skills”. We were six students in the course who all got to try ourselves as presenters on multiple occasions. The instructor taped us on video during some of our presentations, and we got feedback from the instructor and each other. It was two hectic, but very inspiring days. I learned a lot about my presenting that I hope I can use for my presentations in the future.

One of the most valuable lessons I brought with me from this training was how important the structure of the presentation is. Looking back at the presentation we did at NDC this summer, I can see several things I would have liked to improve. It wasn’t a bad presentation, but we didn’t really make our point as clear as we could.

I also got several hints about my delivery style that I want to keep improving.

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.