Performance Zone is brought to you in partnership with:

I'm a software developer working as a senior consultant at Kentor in Stockholm, Sweden. My core competence is as a technical specialist within development and system architecture. In my heart I am, and probably will remain, a programmer. I still think programming is tremendously fun, more than 20 years after I first tried it. That's why my blog is named Passion for Coding.  Anders is a DZone MVB and is not an employee of DZone and has posted 81 posts at DZone. You can read more from them at their website. View Full User Profile

Why Bad Programmers Still Get Hired

08.09.2012
| 21250 views |
  • submit to reddit

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).
Published at DZone with permission of Anders Abel, author and DZone MVB. (source)

(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

I blame agile methodologies for this a lot. Think about it. Short iterations means less opportunity to screw something up. Daily scrums mean you hear the screw ups quickly when they occur.  Consequence? The person messing up is usually assigned other work and someone else one the team has to go in and clean up the mess. 

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

I think that's a good idea, Dean.  We need more widely accepted, scrupulous standards.  What we don't need are any more "Certifications".  The software industry has plenty of those.  :)

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

People interviewing programmers often don't know how to interview for code quality (actually, the subject doesn't even come up, unlike a laundry list of APIs that I might as well learn on the job), and never have I been asked to show a code sample, and explain why I did this and that.

Jose Maria Arranz replied on Mon, 2012/08/13 - 2:41am in response to: Chris Treber

I agree Chris, our industry is obsessed with tools and APIs most of them relatively easy to learn in no much time for any experienced developer and forgets the most important thing: complexity management.

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.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.