Over the Christmas and New Year holidays I have finished a book by Uncle Bob Martin The Clean Coder. It was a pleasure to read this book and I have finished it rather quickly. The overall feel to the book was like I’m reading a big collection of blog-posts from Uncle Bob.

Entire book is filled with advice for software developers. But I found that a lot of this advice is aimed at junior developers. Myself being in a senior role for a while now and doing project management as well, I did not find a lot of new stuff. There was a few interesting points of view on some things, like “being in The Zone is counter-productive”. I did not agree with this point at first, but then thinking about it when I was coding, I do get some of the arguments against being in The Zone.

Another thing I did not quite agree was that “QA Should Find Nothing”, meaning when you send your system for testing, there should be no bugs. Yes, you should not let a buggy software escape your desk. But testing it over and over again – I find this counter-productive. If you release a feature, most likely you have been looking on that piece of project for a few days or even weeks. And it works because you tested it. But I would not rely on your testing because you know how it works and you know what input is expected. If somebody else looks on the system and feeds unexpected input, in a lot of times it will be different point of view on the feature. In my view purpose of QA testing is exploratory testing: what happens if I type rubbish input into this field, double click on Save button and close the browser immediately instead of waiting for the transaction to complete? Or something like that. Because all the other testing can (and should) be automated.

Also 100% code coverage by unit tests? Please don’t do it – that’s a waste of time. All critical business logic should be tested. But there is are tons of boilerplate code that have no point in testing. I.e. Controller Actions in MVC, when using CQRS architecture. OK, OK. I will not go there – there have been numerous debates about purpose of 100% code coverage. I have tried 100% coverage once on a smallish-project and that was a waste of effort that business did not appreciate.

I very much agree with continuous learning – this applicable to all developers however senior. I actually think all professionals, not just software developers, should do it. Software technology moves so fast now – you need to learn new stuff before you go out of fashion.

Though not all advice was for novice – conflict management and “Saying No” was right to the point. I’m pretty good with saying “no” but my diplomacy skills are lacking, so these chapters were very useful.

Overall this was a good read with some interesting points and insights, but if you have been following the industry last few years you already know quite a lot from this book.