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 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, 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.)
Comments
Mike Dzone replied on Thu, 2012/08/09 - 7:16am
Leo Prince replied on Thu, 2012/08/09 - 9:43am
Nice Lesson to Learn :)... Truly a good programmer is un-noticed!
Dean Schulze replied on Thu, 2012/08/09 - 10:46am
There are no standards in the software industry, whereas aviation and medicine have very high standards.
Airline pilots have to earn an Airline Transport Rating from the FAA which requires a minimum of 2000 hours of flight time and passing several written and flight exams. (That may have changed from when I was flying over 20 years ago.)
Medicine has very high standards just to get into medical school. There is a well established course of study with challenging exams and close supervision by experienced doctors.
I think it would be good to establish some relevant standards in the software industry for developers to pass.
One reason mediocre programmers get hired is because there are so many poor managers running software development programs.
Mitch Pronschinske replied on Thu, 2012/08/09 - 11:33am
in response to:
Dean Schulze
Caesar Ralf Fra... replied on Thu, 2012/08/09 - 12:02pm
"To the final user, the interface is the program."
Sadly, that's true.
Mark Unknown replied on Fri, 2012/08/10 - 1:32pm
Having standards in the software industry would mean the elimination of things like Excel, Word and Access - because they are, effectively, software systems.
Hmmm.
Chris Treber replied on Fri, 2012/08/10 - 4:52pm
Jose Maria Arranz replied on Mon, 2012/08/13 - 2:41am
in response to:
Chris Treber
Most of the time when I was interviewed I tell interviewers "I have tons of source code in several open source projects of my own out there, take a look if you want", in most cases they don't care, they just want "2-years Spring IoC guy" the kind of thinking of a Mc Donalds franchise.
Recently I was involved in recruiting this time as a recruiter, I would like recruiting saying something like: "I've seen your code, I know your past, in spite of you don't have a clue of X I'm confident you'll be managing it in a relatively short time" (this was the way I was recruited for Android) unfortunately there are very few developers with this kind of "feeling" mostly because "developer" is an undervalued profession in some countries and many talented people leave this profession every day, finally when you ask "show me some code" most of answers are "there is no code", and you end trying to figure out the "complexity management" skill level just reading "X years of experience with API X" and stuff like that.
In my opinion there is two kind of developers:
1) Those able to use the framework X
2) Those able to DEVELOP the framework X with the same quality or better
That is, is not interesting how much you know Spring, is more interesting whether you're able to develop Spring. In my opinion this should be the main worry in recruiting, software is not just "knowing an API" is building projects, building new things.