Code of Conduct

There is no doubt that Robert C. Martin is an experienced programmer who gives the community of programmers a framework to write clean code. Robert published a lot of articles about principles to improve software quality which flows in his book “Clean Code: A Handbook of Agile Software Craftsmanship”. This book is rather technique centric, viewing code smells, guidelines how to refactor smells, explaining best practices for writing clean code and testing. The mission of the book is to sharpen programmer skills and learn how to reflect the daily written code using the boy scout rule for continuous improvements.

In Germany, Ralf Westphal and Stefan Lieser founded the clean code developer community launching a website which summarizes the principles and practices of clean code. In technical discussion the community understands the principles of clean code knowing that there must be more than technical terms. Proposals were made to missing principles, new ideas came up and the constructive critique boosted the understanding of clean code principles. Discussions about object-oriented principles, testing, agile models, programming language specifics followed along with the discussions in the clean code community. Code katas, to show how to write clean code, were used to view the benefits of clean code for discussion in the community. There is still some critique regarding code bloat, doubts about some principles in detail and how to handle the development lifecycle (e.g. TDD "yes or no" or how and when to do the design for modeling the software).

The Clean Coder

One fact was completely missing: The attitude of a professional programmer. First, I was doubtful about the new book of Robert which defines a code of conduct for professional programmers describing the attitude of a professional in detail. Personally, I don’t like books which advice behavior, how to handle schedules, conflicts and pressure. On the other hand, I like Robert’s style of writing books, explaining daily work scenarios and true experience of his craftsmanship career. The introduction of the book includes the excerpt: "I’ am a programmer, too. I’ve been a programmer for 42 years (don’t panic); and in that time - let me tell you – I’ve seen it all…". Robert has definitively a strong voice which is based on his experience leading to his brilliant reputation. But no one is born which such a voice, it’s still hard work to get every day a little bit better following the principles of clean code.

His message is to work clean (QA should find nothing), to have a work ethic, to know your field and domain, to learn continuously, to practice frequently, to collaborate with colleagues and to mentor junior developers as well as identification with your company and customers to mention the primarily subjects. Diving deeper into the subjects explains when to say “yes” or “no”, how to say it and what it really means. Some subjects are already known in the agile community like the “definition of done” (Scrum) and the commitment (the contract for agreement) to deliver features.

The book is easy to read and full of real life experience of a programmer with brilliant reputation. I have also experience working in different teams using different models and programming languages (mainly C/C++ and Java) for software development. I found a lot of experience written in this book which I have also made in my career. Leading to the simple principle to work clean, to avoid high pressure, conflicts and overtime. In Robert's words the best technical programmer could be fired when he has no professional attitude and his work is like a mess. We all know that pressure, conflicts and overtime could lead to bad code quality. But all this reasons are not acceptable as an excuse for bad code quality. Therefore, avoid pressure by clear communication and commitments which are reachable. Work clean to avoid overtime, and if overtime is necessary, the overtime should happen only in a defined time frame. Resolve conflicts like a professional and when this is not possible resolve it with a sense of humor (laugh may help). It’s also natural to have a wall in front of you, sitting on the keyboard and nothing happens. You may solve this situation by asking for a pair partner or simply accept the situation trying to resolve by going to the window to get some fresh air.

Interesting for me is Robert's opinion according the Flow Zone. For an experienced programmer the Zone is usually like a vacuum, working in a closed room with high speed producing large pieces of source code. I compare the Zone with a mountain bike trail having the power to cycle without hurts forgetting all sorrows in a perfect manner. It’s a nice feeling which could on the other hand be exhausting, if you cycle too far away from your home, it could be a problem to get back. Robert has the same opinion. Avoid the Zone although you write more code with higher speed. But the danger is to lose the big picture not getting the way back home. His advice is to enter the Zone only during practicing a training kata.

I could write even more about the book: “The Clean Coder – A Code of Conduct for Professional Programmers" but I might leave it up to you to participate in a valuable publication which completes the craftsmanship series with useful hints to work clean in the software development lifecycle with the appropriate attitude and responsibility to get things done.