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.
I agree with all your points except the last one about working 60 hours/week. A developer also has a responsibility to their spouse and loved ones, and to themselves, to live a healthy, loving, engaged life, and that’s damn near impossible to do while working 60 hours/week.
I think professional development should be limited to at most an hour in the evening and maybe a couple of hours on the weekend.
I understand your concerns. Here are some suggestions how to cut out the 20 hours for your career.
If you are like most developers, you give your employer 45-50 hours per weeks, although only 40 of them are paid. Cut it down to 40 hours and you save 5-10 hours.
If you commute by train or bus, this easily gives you 1-2 hours per day, say, for reading books. That’s another 5-10 hours.
You could also have a work lunch once or twice a week, where you read something or have a good technical discussions with your colleagues. That’s 2 hours per week.
Then, you could cut down on watching TV. This easily adds another 1-2 hours per day, 7-14 hours a week.
This easily sums up to 20 hours and not a single hour taken from your family time. It’s important to understand that the additional 20 hours are not work. They should be fun. You do the little projects or try the new programming languages you always wanted to do. You do what you are passionate about – software development.
And even if you can only cut out 10 hours, you would be doing much more than most of the developers.
i can’t agree more! Can i translate this post to Portuguese?
Yes, of course. Please link to my article and don’t forget to mention the reference to Robert Martin’s book “The Clean Coder”. Thanks, Burkhard
I’ve been linked to this blog by @MeetingC++
Sadly I can’t read the font in any browser I own. Can you fix the font to be less slim and have a contrasting color?
Thanks for the hint. I changed the text colour to black, which is picked up nicely by Safari but not by Chrome. Give me a day or two to fix this for all browsers.
Fixed and tested for Safari, Chrome and Firefox. Should be OK for Internet Explorer as well – as it is just a CSS change. Don’t forget to clear your browser cache to see the changes.