If some programmers really are 10x more productive, how come that the 1x programmers get hired and manage to keep the jobs?
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 is 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 employeed 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 matters for a programmer’s career.
- While a rock star company has all of a great product concept, marketing and technical competence two is enough.
- 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(s), great marketing and great technical competence. To be merely successful that is not required. 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 technically great web publishing system, but we had a hard time making our voice heard. The company next to us had nice suits, were good at talking and had a product that my colleagues laughed at as “something we did in the image processing lab at university, although their stuff is more simple”. That image processing system company is now a major player within mobile imaging software. My old company is still a small one.
Layman 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 that the user interface design was really great. The relation between how software looks (user interface) and the code quality is really, really weak. Compare that to e.g. construction (as Troy does) where most layman can see building quality if they look closely to it. 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 Maintenance
All 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 it will be evident which programs was designed by a master designer and realized with supreme code quality, because the bad program won’t survive for so long. Unfortunately the bad programmers probably have written quite a lot more 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 (which probably was a shiny UI on top of spaghetti code copy-pasted from the Internet).