Why Bad Programmers Still Get Hired
If some programmers really are 10 times more productive, how come that the 1x programmers get hired and manage to keep the jobs?
I recently read the republished DZone article of Troy Hunt's Measuring code quality with NDepend. Before going into details on NDepend, Troy shares an interesting observation on variances in professionalism.
Something that has always struck me as a bit unique about the software industry is the huge variances we see in professionalism. Consider industries such as medicine or aviation; the lower bounds of their professionalism are comparatively high and the deviation of expertise within the practitioners is comparatively low when compared to software development. Of course there are exceptions – every now and then a doctor malpractices or a pilot crashes – but these are relatively rare occurrences compared to how often poor quality code is written.
Troy’s article made me think about the professionalism and how bad programmers get employed and manage to keep their jobs. I think that there are three main reasons why competence, productivity and professionalism are not the only things that matter to a programmer’s career.
- A rock star company uses marketing and technical competence to produce a great product.
- Laymen can’t assess code quality. Beneath a nice UI there can be a technical mess.
- True professionalism shows after 10 years of maintenance.
Product Concept, Marketing and Technical Competence
A rock star company (Apple, Google) has a great product concept, great marketing, and great technical competence. That isn't required to be merely successful. Two is enough. With a great product concept and the right marketing, it’s enough to have an “ok” technical level.
I remember being at CeBIT in the year 2000. The company I worked for had a great web publishing system on a technical level, but we had a hard time making our voice heard. The company next to us had nice suits, was good at talking, and had a good product (though my colleagues laughed at it as “something we did in the image processing lab at the university”). That image processing company is now a major player in mobile imaging software. My old company is still a small one.
Laymen can’t assess code quality
I don’t know what the image processing company’s code looked like. The laymen using their products don’t know, either, but I’m sure the design of the user interface was superb. The relation of how software looks (user interface) and the code's quality is really, really weak. Compare that to construction (as Troy does), where most laymen can see building quality if they look at it closely. Even if a layman looks at the code, it’s completely impossible to say anything about the quality without knowing programming and software design.
10 Years of MaintenanceAll a layman cares about when a program is new is whether it’s great to work with and if it looks good. True quality of the software doesn’t show until much later. After 10 years of active maintenance, programs designed masterfully that were built with supreme code quality will still be shining bright, whereas bad programs will be long gone. Unfortunately the bad programmers probably have wrote a lot of bad code during those 10 years. When enough time has passed to cast the verdict it’s now so long ago that nobody cares. They will get a new job based on the last year’s project whose shiny UI hid the spaghetti-like, copy-pasted code that came from the Internet).
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)