Robert Martin’s book Clean Code (Amazon Link here ) is one of the most important books I have read on the craft of software development. It is a language / platform agnostic book on how to write good, maintainable, and readable (i.e. the “Clean”) code. But, when deadlines start slipping and things start falling apart, it is all too easy to cut a few corners and accrue some technical debt which will come due later. It looks like Robert Martin has written a follow-up to Clean Code. The title is The Clean Coder: A Code of Conduct for Professional Programmers (Amazon Link here ). It is on my “to-read” list, but Christoffer has written an excellent summary here. He lists 9 points that he took away from the book. For me the most important point was this:
A Professional Programmer Takes Responsibility
It is very easy to blame the BA (Business Analyst) for not writing a clear specification or a clear test plan. It is easy to blame the user for not doing a thorough UAT, and it is easy to blame the QA team for not doing integration testing properly. If there is a bug in the code, it is the programmer’s responsibility. Once a system reaches a certain complexity, there will always be bugs or edge cases that somehow slipped through into production. Once a bug has been identified, it is the programmers responsibility to explain it, to fix it and to ensure that similar mistakes don’t happen again.
I have been (and routinely am) in positions where a bug in code I have written has lead to a significant outage or a measurable, significant, monetary loss. The first instinct is to always look for problems somewhere else. Maybe something went wrong in the operating system, maybe the deployment team did not release the packages correctly.. It may be the case, but as a Professional my first responsibility is to check my own code. What did I change? What could have gone wrong? How can I reproduce this error in the test environment? How do I fix it? And finally.. how do I make sure this does not happen again?
In my experience, a policy of complete transparency is the best policy for a Professional Programmer. If the management team knows they can trust you, they will generally be more understanding when things fall apart in production!