Warning Shots Across The Bow

A Ten-Step Program

As a software contractor, it would be extremely unusual to have any say in your host company's hiring. Unfortunately, this means that the people who have arguably seen the "most action" (to use a military expression) have the least input in this critical component of a successful company.

As such, we generally get introduced to new faces with no background information - how much experience do they claim to have? Are they fresh to the programming language? Software development? The country?

I find it very educational to examine a new starter's first few code checkins. Probably not the absolute first, because they will be on their best behaviour, and possibly pair-programming. About the fourth or fifth submission, ideally a brand-new source file. You can tell a hell of a lot from the quality of this, and you can be pretty objective in scoring it. A new person starts with 10 points; knock off a point for each of these mistakes:

• No comment block at the top of the code - a developer should be proud of their work and be happy to stand behind it/explain it/answer questions about it


• Unused members - every IDE on earth will warn about this. The fact that they are checking in code without paying attention to such warnings (or worse, have turned them off) is a concern


• Raw generic types - they've been in the core APIs for six years now - no-one should be writing code with "naked" Lists and Classes


• Pointless boxing - returning a Boolean from a method that just contains if statements could indicate a lack of understanding about the costs of autoboxing


• Copy/paste coding - yes, it's still out there. Any reluctance to write reusable code shows a disregard for future maintainability


• Concrete parameters and return types - returning ArrayList is a warning that the correct use of interfaces is a foreign concept to the developer. This can be a hard habit to break for some.


• if-y code - no, I don't mean code exhibiting dubious qualities! (Although it probably is) - I mean code with if statements nested more than 1-level deep. At best, it warns of a reluctance to refactor into small clean methods. At worst, it could indicate an inability to spot good targets for object-orientation.


• Failure to use standard libraries - a lack of familiarity with any in-house utility classes can be excused. But there is no excuse for reinventing methods that belong in Commons StringUtils et al


• Inefficient/awkward program flow - Are unchanging conditions being repeatedly re-evaluated? Is there an expensive calculation in the termination condition of an if statement? We may program in very-high level languages but efficient use of the CPU is always to be considered.


• Wasteful data representation - this can occur both in redundant member variables but also in the choices made when serializing data for transmission "over the wire". The latter in particular is another warning sign that low-level efficiency was not a consideration.

So what do you do when your new colleague scores a 4? I'm still formulating my thoughts about that! It's not an easy situation, that's for sure, and will be the subject of a future post.