QA finds many bugs that are very easy to catch. Builds contain warnings and runs error messages and even violated assertions. Coding guidelines and good coding practices are ignored. Unit tests are only written to drive line coverage up. Acceptance tests are missing. Code is committed although some tests are failing. Releases are prepared manually. All these symptoms are signs for unprofessional developers at work. So, what makes a developer truly professional?
It is our duty as professional developers to deliver bug-free code. QA must not find any bugs.
[Our] error rate should rapidly decrease towards the asymptote of zero. It won’t ever get to zero, but it is [our] responsibility to get as close as possible to it.
We should always keep in mind that bugs are expensive. QA spends time to find bugs and enter them into a bug tracker. Often the bug goes through a long-winded analysis and approval process, before we are allowed to fix it. This process easily takes longer than fixing the bug itself. When fixing a bug, we have to understand what we or someone else has done weeks or months before. The bug may also be buried under a lot of new code, which implies more changes to fix the bug. Fixing a bug takes multiples of the time needed to avoid it in the first place. So, we better converge quickly and very close on the zero asymptote.
Every time QA, or worse a user, finds a problem, [we] should be surprised, chagrined, and determined to prevent it from happening again.
The only way to make sure that our code is bug-free is to test it, to test it again and to test it yet again! And, here it comes:
Am I suggesting 100% code coverage? No, I am not suggesting it. I am demanding it. Every single line of code that [we] write should be tested. Period.
If we don’t have 100% coverage, we will not know whether our code really works. All our tests should be automated and run very fast. Before we commit any changes to the source code repository, we must run all tests and make sure that they all pass. If a test fails, we must fix it.
At the beginning of a project, we can add new features to our code base very fast. After a few weeks, this becomes slower and soon it seems that we are hardly moving. The reason is simple: The structure of our code has deteriorated. It becomes harder and harder to add new features and we spend more and more time on debugging and bug fixing. The cure is also simple:
If [we] want [our] software to be flexible, [we] have to flex it! The only way to prove that [our] software is easy to change is to make easy changes to it. And when [we] find that the changes aren’t as easy as [we] thought, [we] refine the design so that the next change is easier. [We do this] all the time! Every time [we] look at a module [we] make small, leightweight changes to it to improve its structure.
We never look away when we see problems in the code. We always fix them. Obviously, we can only do this “merciless refactoring” of our code, if we have a complete suite of tests that we can run in no time. Otherwise, we would hesitate to touch code that we don’t know. We leave the code always a bit cleaner than we found it.
Writing bug-free code with a flexible structure is an extremely ambitious goal. Who is responsible for developing the skills to reach this goal?
[Our] career is [our] responsibility. It is not [our] employer’s responsibility to make sure that [we] are marketable […] to train [us], or to send [us] to conferences, or to buy [us] books. These things are [our] responsibility.
This certainly comes as a surprise to many developers. On my projects, I often hear statements like “But my company hasn’t given me a training on this!” My answer typically is: “I never had a training on C++, Scrum, test-driven-development, design patterns or Qt. I read many books, discussed with other people and even paid trainings and conferences myself.” This normally ends the discussion, but only very few do something about it. They truly care about their career.
So, how much time should we spend on advancing our careers?
[We] should plan on working 60 hours per week. The first 40 are for [our] employer. The remaining 20 are for [us]. During this remaining 20 hours [we] should be reading, practicing, learning, and otherwise enhancing [our] career.
If we don’t heed this advice, we’ll find ourselves in the situation, where we are stuck in a boring, routine job and where we have difficulties to find another job. A professional developer won’t have these problems.
Reference. This blog post is based on Chapter 1, “Professionalism” of Robert C. Martin’s book “The Clean Coder”. The quotes above are from this book. This book is a must-read for every aspiring professional developer.