Fixes The Build: When You’re a Professional Programmer


Author: Graeme Love, Engineering Specialist

For my inaugural post I wanted to talk about a book that I came across a few years ago which I found thought provoking and has helped clarify how I think a professional developer should be defined. The book in question is The Clean Coder: A Code of Conduct for Professional Programmers by Robert C. Martin.

In this post I’m going to choose some sections of the book and discuss my thoughts on them. I would recommend that you read book for yourself and form your own opinions on the material. The author takes a pretty absolutist stance on what it means to be a professional, and if you’re not doing everything that he says then in his opinion you’re not. In lots of places throughout the book the author displays quite an arrogant tone, and if it was written by someone less experienced then I would be less disposed to listen to his point of view. To help him get his point across he uses illustrative anecdotes and war stories from his past experiences, both good and bad. These stories help offset the otherwise sometimes arrogant tone he makes when presenting his conclusions. Personally I think that life isn’t quite so black and white, so I see these as things that we should aspire to. If we were all able to get there then the world would truly be a wonderful place.

What Does Being a Professional Mean?

In order for all of us to be working here the company has recognized our talents and wants to pay us to use them in their endeavors. While this might be the literal definition of professionalism, it is different from the standards discussed in the book. Instead the book makes the requirements for being professional more a question of always taking responsibility for the work that we do.

Professionalism is a loaded term. Certainly it is a badge of honor and pride, but it is also a marker of responsibility and accountability. The two go hand in hand, of course, You can’t take pride and honor in something that you can’t be held accountable for.

It’s a lot easier to be a nonprofessional. Nonprofessionals don’t have to take responsibility for the job they do – they leave that to their employers. If a nonprofessional makes an error, the employer cleans up the mess. But when a professional makes a mistake, he cleans up the mess.

How do we take responsibility? The book offers some guidelines:

 First, Do No Harm

Drawing from the Hippocratic oath may seem arrogant, but what better source is there? And, indeed, doesn’t it make sense that the first responsibility, and first goal, of an aspiring professional is to use his or her powers for good?

As developers we obviously want the software we write to work. Not only that, our customers and employers want it to work as well. The way that we cause harm to the software is by letting bugs get in there. Therefore to be professional we must not create bugs.

“But wait!” I hear you say. “That’s not reasonable. Software is too complex to create without bugs.

Of course you are right. Software is too complex to create without bugs. Unfortunately that doesn’t let you off the hook. The human body is too complex to understand in its entirety, but doctors still take an oath to do no harm. If they don’t take themselves off a hook like that, how can we?

“Are you telling us we must be perfect?” Do I hear you object?

No, I’m telling you that you must be responsible for your imperfections.

How can we achieve this goal of perfection? The book promotes the use of writing tests that can be run every time we make a change to the code that will verify its correctness. These tests should be run every time a developer commits a change using continuous integration. Robert C. Martin also pushes strongly for Test Driven Development (TDD) and dedicates an entire chapter of the book to it. He states that the TDD discipline forces the developer to think about good design and structuring the code to make it test-friendly, and then goes on to propose that it is actually unprofessional not to use TDD. The usage and reliance on code tests is something that VV has done for a long while. In the Alchemy code base this was done using itest which contained tests for each sub-system in Alchemy that could be run on all platforms. Being able to run these tests after I made a change in Alchemy always made me more confident that I hadn’t have broken anything fundamental. On our game projects we have testing for content creators as well using NovaTest / SubmitTest, and we ran longer verification tests on our build servers to ensure that our content loaded on the target platform. Even with all of these tests we were still far from the 100% code coverage that is demanded by the author in order to be deemed professional. Is this achievable in game development? I’m sure that we’ll each have our own opinion on that matter but certainly we could probably do better than we currently do.

Of course just getting our software to work is no good if it’s done at the expense of the structure. Good software should be structured in a way that allows it to be flexible. If the structure is compromised, so is the future.

Work Ethic

According to Robert C. Martin, you should spend time caring for your profession. Like any other profession, practice improves performance, skill, and experience.

Your career is your responsibility. It is not your employer’s responsibility to make sure you are marketable. It is not your employer’s responsibility to train you, or to send you to conferences, or to buy you books. These things are your responsibility. Woe to the software developer who entrusts his career to his employer.

The book states that it is your own responsibility to keep training yourself by reading, practicing and learning. In fact anything that helps you keep abreast of the constant changes in the industry and helps you grow as a software developer. It goes on to say that this should be done on your own time, not your employer’s, but not to mistake this with you doing your job on your own time. This time should be dedicated for the things that you want to learn and for your enjoyment. According to the author, if you work 40 hours a week, you should spend about another 20 hours of your own time practicing your profession.

Don’t Be Afraid to Say No

We’ve all been in the situation where we’ve been asked to work on something that we think is unrealistic e.g. a deadline, a task estimation, a requirement etc. When presented with this situation a professional developer should not be afraid to say no. Not some of the time, but all the time. People are relying on you to defend your objectives as much as they defend theirs. That’s how you are get the best possible outcome for all parties. Don’t fall into the trap when someone asks if you could “try” to get things done according to an unrealistic deadline/specification. If you say OK to this then it’s very likely that the other party will walk away thinking that you said “Yes” and then make commitments to other people based on that.

All of the above seems very adversarial and it could be if you’re not willing to work with the other person to get the best possible outcome for all. They should understand why you’re saying no, but work with them to find alternatives.

Learning to Say Yes

The book dedicates a whole chapter to “Saying No”, and then follows it with a chapter entitled “Saying Yes”. It argues that while a professional is not obligated to say “yes” to everything that is asked of them, they should work hard to find creative ways to make “yes” possible. When a “yes” answer is given, professionals should view that as a commitment and be prepared to state it as such. If you’ve given a commitment then you should do everything possible to ensure that you deliver on it. There is a lot of discussion in the book about a “language of commitment” and the various words that indicate both a lack of commitment and how to state it so that there is no doubt on what has been promised.

Of course, sometimes life throws a spanner in the works that can prevent us meeting those commitments. When this happens you need to change those expectations as soon as possible. Raise a red flag as soon as possible to whoever you committed to. The earlier that you raise the red flag, the more likely you are to be able to work with the team to assess what can be done.

An Exercise for the Reader

I’ve only covered a small bit of the subjects that the book covers in this post. The book has chapters on other aspects of software development such as coding best practices, TDD, time management and there’s an especially good chapter on estimation that I might write about in the future. I’d encourage you once again to go and take a look for yourselves.  I’m sure that many of you will disagree with many of the author’s conclusions, and I’d be very interested to hear about them from you.

leave a comment