Archive
Clean Code
“A Handbook of Software Craftsmanship” – this was the intriguing subtitle of Robert C. Martin’s book “Clean Code” that I picked up at the JAOO conference in Århus, Denmark, last October.
The book really served as an eyeopener for me, and it made me think about how I can improve in my craft as a software developer, and how I can help the people around me improve.
There are a lot of problems that can arise in your code if you are not careful when writing it. The book brings many different heuristics for how to make your code better, and I recommend it for anyone writing or reading software.
So how can we become better at writing clean code ourselves?
I think the first step is to become aware of the problems, and to see examples of both bad an good code. A book like this can of course help with that, but I think it is very important to have a forum where you can discuss coding techniques and issues with others. In our office, we’re trying to get this by having a software craftsmanship study group where we, about once a month, get together and discuss topics about our craft. We’ve started by going through the chapters of Martin’s book, and it has been creating some very good discussions so far.
I’ve noticed that since I’ve started to think more about clean code, I’ve changed my view of coding. Code that I used to find quite good doesn’t look so good any longer now that I’ve learned how much better it could be. I really appreciate code that is readable and maintainable, and I find that these factors usually are more important than other quality attributes like performance. This is of course not always true, but a great deal of our code is not run in critical inner loops, and I would much more have it well readable and maintainable than super fast.
I Am Not What I Code
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.
Hello World! 