Tuesday, January 06, 2009

The Cost of Net Negative Producing Programmers

It's common to compare ourselves to doctors, lawyers, and other highly-paid professionals. Unfortunately, almost every comparison breaks down dramatically, very quickly.

When doctors screw up (massively) they get sued. When (permanently employed) programmers screw up they get let-go, and they go find a new job, usually with more responsibility and a pay raise. There are no ramifications for software malpractice.*

Successful lawyers put in years to learn their craft, then they put in years trying to become partner. Eventually they get to make the firm defining decisions, but only after maturing their abilities and proving themselves. In our industry you need no formal education. If you show the slightest sign of competency you'll quickly be given the keys to the kingdom. Architect promotions are not hard to come by.

I had an 'architect' title with no college degree and only 3 years of experience. At that point I'd never heard of unit testing, refactoring, or design patterns. In those days I was picking up information from O'Reilly In a Nutshell books and MSDN. At the same time I was leading a team building software for the US government (via contracts the company had won, not employed directly by them). I was massively under-skilled, and yet, there I was writing software that troops would need to stay alive.**

I wish my experience were isolated, but while I was consulting for 3.5 years I saw countless examples of exactly the same story.

I know the argument: demand is so high, we don't have another choice. I reject this argument on the basis that most good programmers spend the majority of their time fixing problems created by terrible programmers.

Good programmers fix problems created by terrible programmers in various ways. Good programmers can directly address problems by rewriting poorly written custom code. However, the less obvious way good programmers address poorly written code is when they write custom code because all the tools, that a company could potentially buy instead of building, are terrible. Would so many companies write their own time tracking, project managing, bug tracking, expense tracking and other internal tools if they had reasonable commercial options?

The argument that demand is too high completely ignores the opportunity cost of working with NNPPs.

The next common argument: We don't have that many NNPPs. Really? Write a few blog entries, attend a few conferences, do some consulting. I think you might change your mind. And, remember, the people commenting on blog entries or attending conferences are the ones who actually care about what they are doing. I'm horrified to think what the less interested NNPPs produce.

Here's a gem from a comment on my last blog post.
I honestly think I can do about 3000 lines of good code in a day... -anonymous
The commenter actually thinks writing 3000 lines of code a day is a good thing.

If you read through the comments you'll find another commenter that doesn't understand the difference between open classes and inheritance, but overall the majority of comments are well thought out reasonable responses. Several people were able to create logical responses without being emotionally attached to Java. That gave me some hope that things were a bit better than I generally picture them as. But, then I checked out the dzone score of the entry.

Now, maybe it's just not a well written or educational in any way post, that would be fine. But, when I read the comments, I'm back to disgusted by our industry. In this day and age, is it really reasonable to think that Java doesn't have limitations? I would say no. Java is a great tool for certain tasks, but there are plenty of things to dislike about it. I wouldn't want to work with people too blind to notice that.

Another common statement is: In every industry you have people who don't care about their jobs. I don't think that's a good comparison either. Bad doctors are sued until they can't afford malpractice insurance. Lawyers, very publicly, lose cases and are fired. In those industries, if you aren't contributing towards moving things forward, you're quickly exited.

Professional sports is an industry that probably has very few professionals that don't care about their job. If you aren't good enough, you don't make it, period. In basketball, there's no position for someone who is only good enough to dribble. If you're good enough, you're paid well. If you aren't, you don't make it. It's that simple.

So what is the cost of NNPPs? I'd say there are several ways to answer that question.

The first obvious cost is opportunity cost that companies lose when they can't provide quality software to their customers. This can translate to significantly lower revenue due to lack of or cancelled subscriptions or licenses. It can be the difference between the success and the failure of a start-up. For businesses, I would say the cost is epic. Is it any surprise that technology companies are some of the most volatile stocks.

There's other costs as well. When software fails, people don't get the aid they needed. This can be money, hospital care, legal direction, and many other life altering situations. Poorly designed software can cause death, and yet rarely is that kind of thing considered by a programmer.

I heard once that in Great Britain's MOD if you design software for a plane you go up in the test plane when the software is beta-tested. If all programmers were held with that level of accountability, how many do you think would still be in our field? How many would you want to collaborate with before you went up in the plane together?

Of course, we don't all write life-threatening software, but does that give us an excuse for lowering our colleague-quality requirements? Picture the things we could do if we didn't spend most of our time making up for terrible programmers and you'll know why I'm passionate about the topic.

Terrible programmers also slow us down as an industry. When I talk about Open Classes people are terrified. They always say: That's fine on your team, but we could never work with a language that has Open Classes. Is that a problem with Open Classes or a problem with the team? I worked on several teams, large and small, that used Open Classes diligently and I can't remember a single problem we ever had with them. Much the opposite, the teams were often, clearly more effective because they were talented and the language let them solve problems in the most effective way.

Java and C# are not silver bullets. The languages are good solutions to a certain class of problems, using them for problems that could be better solved with a different language stagnates the growth of other languages. The longer great programmers use a less-effective tool for the job the less time they have to work with and mature languages that are more suitable. As a result our entire industry loses out.

There's also a cost to your future colleagues. There's a big difference between a NNPP and someone new to the industry. Someone new to the industry benefits greatly from a mentor, but what if the mentor is an NNPP? Some NNPPs do small scale damage in isolated components of applications. But, the most insidious NNPPs are the architects who's ideas belong on The Daily WTF. These NNPP architects build entire armies of NNPPs around them and single-handedly waste millions, if not billions of dollars, annually. And, potentially worse, they ruin or at least drastically hurt the careers of eager to learn teammates.

The Cost of NNPPs is high enough that it's become my soapbox issue. But, truthfully, I'm not saying anything really new, so is there any hope for our industry?

I do think there are things we can do to help move the industry in the right direction. The good programmers can refuse to work with bad programmers. That might mean moving to an organization where that's a goal, or making that a goal of your current organization. Providing negative feedback directly to a NNPP teammate is always hard, but I do believe the ROI justifies the action. It's also helpful to provide that feedback to your manager, so the manager knows your opinions on the skill levels of your teammates. You can also suggest to managers that employees who refuse to take advantage of training budgets should be looked closely at. Lastly, you could suggest moving developer compensation to be based on the success of the project. A royalties model would be really interesting.

And, if you have a blog, you could write your own entry expressing your opinions on the topic.

* The exception being freelance developers, who are the minority, at least here in the US.
** Thank God, the government never ended up using the software we delivered.


  1. Great stuff and couldn't agree more, not sure what the solution is but I agree with your analysis of the problem.

  2. "I know the argument: demand is so high, we don't have another choice. I reject this argument on the basis that most good programmers spend the majority of their time fixing problems created by terrible programmers."

    I agree with that statement 100%. It's like you are in my mind. I constantly feel this way about the I.T. industry. I also wonder if there really is a way to fix it. There is the passion for software development and then there is the business side. Sadly, business seems to trump the love of development a lot.

    I've spent days fixing terrible code, and management questions "why'd you take longer than programmer X?

    It's because he programs like a rabid monkey, slapping code like he was flinging poo. Programmer X also has to work weekends and has a bug list the size of a small country. It's not cause he's passionate, it's because he's afraid of losing his job and people finding out he should be flipping burgers.

    Great Post (wish I would have written it :P )

  3. Anonymous9:01 AM

    I think we need widely recognised professional bodies with useful accreditations.

    Currently I can become a member of various bodies by paying a fee, but they're not recognised by employers because being a member doesn't guarantee any level of quality in your output.

    I can also get accredited with software vendors, but again such certification is useless to employers - they only tell you who's paid lots of money (or had their employer do so) and memorised some useless information, such as accelerator keys for arcane commands in Visual Studio.

    Of course, many employers will treat such 'qualifications' as worth something, but they are fooling themselves, as they find out later. Unfortunately there's a lack of alternatives, so they repeat the mistake.

  4. Anonymous9:27 AM

    In Canada we have the concept of Software/Systems Engineers who are professional engineers with university level training and are held to the same standards as those who build bridges, etc.

    If you need a piece of software to be written to that kind of level, hire a professional engineer who is willing to legally sign off on the software, otherwise, realize you aren't going to get that kind of guarantee and move on.

  5. Anonymous9:48 AM

    The software engineering curriculum of top accredited universities has not changed since I was in school 25 years ago. Compare it to what is needed to do good work. Compare it to the "Guide to the Software Engineering Body of Knowledge (SWEBOK). It is clear that universities do not teach the systems engineering practices that are common in other engineering disciplines. No requirements engineering, not risk analysis, very little information modeling.

  6. I am more pessimistic, and I think that the net negative producing programmers are here to stay--- because the market wants them.

  7. The best solution I've discovered to avoiding NNPP's is through starting apprenticeship programs. An enthusiastic apprentice is cheaper, less destructive, and a far better long-term investment than a typically overpaid NNPP.

  8. Anonymous9:57 AM

    Then there's the talented programmers squeezed out of the market by NNPDs. I'm lucky enough to have made it back in, but with a 4 year gap in my CV that's a bit hard to explain. I know some talented people, some smarter than me, who just gave up and went into other industries.

  9. This is particularly true for gov't contracting because there's no market to regulate failure. Especially in R&D where it's easy to chalk up failure to hard research problems rather than incompetence. I had almost the exact same experience at my first job where, with 2 years experience, I was basically the lead engineer. I was hoping you were going to say it was different on the outside :(

    Luckily, as you note, almost none of the software written in the defense industry makes it into the hands of the people it could harm. And if it does, it generally sucks so much they quickly reject it and go back to pen and paper or PowerPoint or whatever.

  10. Anonymous10:05 AM

    i think one of the main qualifiers or variable that you have, is that you are in government contracting, which requires different levels of clearance.

    in the world of government contracting, a clearance will mean 20% of a pay bump, and not only that, it filters job eligibility.

    i've seen many government contractors who know next to nothing, yet they are employed to fulfill the contract headcount, and also to fulfill the security requirements.

    whether the work gets done, or gets done right, is just a political issue all together.

  11. Anonymous10:14 AM

    @Anonymous, when I did that project for the government I had no clearance, and that was many, many years ago. I haven't done a government contracting job in over 6 years at this point. That was just one of my experiences.

    Cheers, Jay

  12. The good programmers can refuse to work with bad programmers.

    That's a solution? Instead of helping bad programmers become better programmers, you leave them behind. What about mentoring? Apprenticeships? OJT?

    In my opinion this post reflects a naiveté common to technical types who are interested in becoming better programmers but not dealing with the situation on the ground. NNPx employees exist in every situation -- that's why the ancient guild structure had apprentice, journeyman, and then master.

    Another commenter says: Sadly, business seems to trump the love of development a lot.

    This boggles my mind. My friend's dad is a glazer -- he installs and maintains windows for skyscrapers. Can you imagine a glazer who sits and can only do millimeters of sealant at a time because they're so obsessed about whether or not their line of caulk is perfectly straight and uniform? That glazer would be out on his ass because the business need to maintain the facade of an entire structure trumps the love of a perfect line. Instead, business decisions mean that you use a certain caulk with certain tools, and you get the job done and move on.

    Bringing this home -- the solution is what commenters rikkus and Dave Hoover have mentioned, and I alluded to above. Have a system of certification and apprenticeship. You mention doctors and lawyers, so think about the internships they have to go through even after they pass their exams and become MDs/JDs. NNPPs don't exist in a vacuum - they are net negative producers because WE KEEP THEM DOWN.

  13. Anonymous10:20 AM

    @Nathaniel, I meant truly bad programmers who cannot be mentored. However, I definitely didn't make that clear enough. I'm also a big fan of apprenticeships and mentoring.

    Thanks for the comment.

    Cheers, Jay

  14. Anonymous10:21 AM

    You do realize that most fields aren't anything like lawyers, doctors, or professional athletes? Those are fields with extremely high barriers to entry, and, as you pointed out, programming is *not* one of those fields.

    You'd do much better to compare programming to another field with low barriers to entry: salespeople, perhaps. Virtually anyone can get a job in sales, but there's an effective metric of effectiveness; ineffective salespeople often lose their jobs if they do not produce sufficient sales. Perhaps the biggest issue is a lack easy to use managerial metrics rather than a lack of accountability.

    Take it easy,

    David Berube

  15. Jay, I for one certainly feel your frustration. What do we do? I see three main issues.

    - How do you have a successful interview process to weed out the NNPP?
    - It takes a minimum of 3 to 6 months for domain specific knowledge to take hold for a good programmer to be effective and efficient, giving the NNPP the ability to hide and say the right things.
    - Pay

    So what do we do? It is a bad spot and even more so for a start up with time and money constraints.

  16. Anonymous10:33 AM

    A very insightful post. Taking inspiration from the British eg, why not ask the team which developed some software to maintain it and be accountable for the running costs? The current (wrong) industry practice is to sell off development and support separately to the lowest bidder.

    Isn't software TCO related to the reliability and flexibility of the deliverable?

  17. I always go with the adage 'there are programmers, and there are developers'. Programmers are code monkeys, undisciplined and usually accompanied by a host of self-serving mental quirks. Developers understand requirements and that rogue changes to the UI because it makes more sense to them are a bad thing.

    That said, the worst monkey code I've ever seen was when I was doing reporting. T-SQL and concepts behind writing efficient clean code ought to be easy to grasp but I've found 3000+ line stored procedures that I've condensed to 300... and I actually commented my code. And it took 30 seconds to run instead of 45 minutes.

    That said, there's a certain trait in some programmers that irks me... the egotistical god-complex. Really, if the client wants a bright pink background, we've told them it'll look dumb but they won't bend, make it bright pink. Yours is not to reason why, yours is but to develop and get paid. :)

  18. Rather than leaving (which, in additiona to being childish, will not result in any improvement in the field in general, just move it around), fix the damn problem. Managers can't fix the problem, because they can't identify it.

    Even the worst and most stubbornly negatively productive programmer will either get better (through education and motivation) or become demoralized and stop producing (negative value) if you review their code mercilessly enough, consistently enough, and publicly enough.

    Always have code reviews with the whole team. Always review all your code changes. Every week.

    Always. There's no other solution.

    Pair programming is a reasonable optimization to this *in theory*, but in practice it just causes the negative producers to clump together and produce *worse* code (what good programmer wants to pair program with a bad programmer?).

  19. Anonymous10:56 AM

    Are you saying that those Net Negative Producing Programmers dont have manager that can know about it ?
    Only their peer would be aware of it ?
    I dont believe that.

    A company that have such poor organisation would bankrupt unless... it's profitable to do so.

    And if it's profitable, this type of organisation will exist no matter your bad feeling about it.

  20. The problem with our field is that software has yet to be respected as a legitimate product. In context to what we do, doctors and lawyers are no smarter than we are. But for the most part they are responsible for the product/service. So then, the least responsible for their product/service or reclassified as para-legals, nurses, clerks or physician assistants.

    That reclassification of programmers may not be appropriate for us, but reason for their reclassification is. Managers, leads, mentors, gurus and thought leaders have to impact of what software has on the world! Then the newbies and the talented uneducated will have an easier time evolving to the kind of practitioners software professionals should be.

  21. Anonymous11:22 AM

    If the programmer can be overruled with regard to safety and security of code, I don't think it's reasonable to hold the programmer legally accountable. They are work for hire, they have input but they do what they are told.

  22. i can code gen 3000 lines of good, solid, well tested code a minute. boo ya!

  23. I believe what we really need is an open rating system. Seriously. Think DailyWTF + GetSatisfaction + LinkedIn. I'm considering building one...

    Also, I believe that most of the problem comes from CS departments across the country. When I finished my Associates in CS, I knew absolutely nothing, yet I was a Senior developer at a web design firm. That is why I'm attending Neumont.edu, but even at Neumont I find tons of people who are in CS because they believe that they will be paid well, not because they care or have the aptitude to do it.

  24. Anonymous1:14 PM

    It all comes down to knowledge of your field. I'm willing to be there is the same ratio of bad programmers as there are bad doctors and lawyers. You are getting stuck on the way to measure 'bad', it's easy for you to measure bad programming because you know your field and what to expect. If you ask an expert doctor to go rate the diagnosis abilities of the countries family doctors there is no way he would rate each of them equal. You're using the doctor analogy for the extreme case where the doctor is so bad that he makes a large mistake, what if the mistake is small like not reading warning signs of a patient who is developing cancer and doesn't catch it until its a month too late. There is no suit and that doctor is a 'bad' doctor. Same with programming, if a programmer is so bad he cant get a project done at all he is fired... plain and simple, so the anology is the same in both cases. Your issue is that you are judging bad programmers as everyone who isn't at the top of their game (or upto your standard).

  25. Anonymous1:56 PM

    At the start of the article you say lawyers and doctors can't be compared with programmers. Then for the rest of the article... you compare doctors and lawyers with programmers.

    Doctors can't innovate and bypass drug companies by developing a new method to treat illnesses. Lawyers have to adhere to the law, and spend years learning how to use previous cases to make their case.

    Developers on the other hand, create new products. A better analogy would be toy manufacturers. The ones who make faulty products and kill kids should be held accountable. On the other hand, if a toy is horribly designed and implemented by a programmer and because of that it doesn't sell... big f=ing deal. You should have hired a better programmer, and if you can't find one, you should have offered more money and a stake in the product sales.

    Instead, people still see us as doctors or lawyers... you have some skill you learned and now you "practice" it. We don't do that. We design the software we make, and we innovate.

    And for people who say managers design software... when's the last time a manager told you the OOP design, gave you an ERD or clearly defined what re=usable components should be produced by a product... NEVER. We do everything... or at least I do as a contractor.

    Programming is more of an art than a skill. Given a design, no two programmers would create the same software... where as two doctors would prescribe the same treatment all the time. That's why it's hard to create standards (and punishment)... it's too open=ended. And anyone who tries will just end up frustrated like this guy.

  26. Anonymous2:02 PM

    Regarding Ray's comment about pair programming, where he says bad programmers cluster:

    For effective pairing, it's important to pair promiscuously. Change partners every few hours, and seek variety. For teams just getting started, I'll make a chart and have everybody track the different pairings. That makes cliques obvious. Letting people cluster too much undermines the collective code ownership and shared style you get with a team that's doing pair programming well.

    It's funny, but I just posted 21 Ways to Hate Pair Programming ten minutes ago, and Ray's already found #22 for me: avoiding pairing with people who aren't doing good work.

  27. Anonymous4:22 PM

    "A person presented as an engineer implies to the general public that the individual has completed a rigorous course of study such as that provided by an ABET accredited engineering curriculum, mentorship under experienced engineers, and continuing education and training. The public should know that the engineer is qualified to assess the scientific and mathematic fundamentals relating to a design, problem, or situation and make a reasoned, engineering judgment as it relates to the public good." - J. Brian Dietz, P.E.

    Texas is the only state I know of that offers Software Engineering licensing.

    However, even with the licensing from the state, that does not mean the individual is qualified at their profession, it just means they are licensed.

    Take a chill pill..., and just know that every profession deals with different levels of competency.

  28. Anonymous4:27 PM

    'It's because he programs like a rabid monkey, slapping code like he was flinging poo. Programmer X also has to work weekends and has a bug list the size of a small country. It's not cause he's passionate, it's because he's afraid of losing his job and people finding out he should be flipping burgers."

    Ha great comment Khalid! Its so true! I've dealt with the same nightmare code bases myself. There really are some folks who shouldn't be allowed to program period.

  29. Anonymous4:30 PM

    In Gladwell’s book Outliers, he addresses the question of success and how it is achieved. He discusses the concept that it takes 10,000 hours to reach elite status in most professions. He illustrates this in a number of ways by giving profiles of Bill Gates, Mozart and a fascinating study of German piano players at an elite music university.

    Gladwell makes two points in his talk:

    1. persistence and collaboration might be more important personal traits than lone genius in a complex and changing world; and

    2. a person needs to invest 10,000 hours of concentrated and reflective practice to achieve mastery—this amounts to about 10 years.

    Maybe your being too hard on the NNPP

  30. You had me until you said, "Terrible programmers also slow us down as an industry. When I talk about Open Classes people are terrified."

    Many of us who are against open classes are not against change. We very much want change, but in the other direction. We want more rigorous compile time checking and static analysis tools. We want to be able to prove as much of the code as possible so we can focus our limited QA resources on business logic.

  31. Anonymous4:38 PM

    What is number one development language?

    Not Java, COBOL or C, but Excel.

    Almost every business major knows and uses Excel. Billions of lines of Excel exist and are being used daily.

    $100 Million mistakes have been made with Excel. Do we require Business people to become Excel certified?

    Engineering? NNPP? Give me a break, the problem is much more complicated and diverse.

    "There are more things in heaven and earth, Horatio, Than are dreamt of in your philosophy."

  32. Anonymous4:40 PM

    @Jonathan Allen, we want the same things, power. If Java had Open Classes it would be more powerful. At the other end of the spectrum, I like what Haskell provides me without taking away power.

    I'm cool with anything that moves me in the right direction. I'm not cool with programming with kid-gloves on.

    Cheers, Jay

  33. Anonymous11:07 PM

    The fact is that lots of functional software has been delivered by what you call NNPPs. You can sneer at their work because it's bloated, etc. -- but it does what it's supposed to do and may have done it for many, many years. So is that really a bad thing? Mainframe developers probably didn't apply the best practices that you mentioned --- yet much of their software has been running for decades. Can you say the same thing about any software that you have written?

    Are you also saying that you've never written any software that another developer has looked at and thought it was a bunch of crap? You are quite amazing if that's the case, but if it's not the case -- does that mean you were a NNPP at one time? So should you have been shown the door many years ago?

    Also note that there is such a thing as Software Malpractice and insurance companies do offer products to cover product companies, consulting companies, etc. Although I have to say (as others have mentioned) comparing Software Developers to Doctors / Lawyers is a bit of a strange comparison and not one that I've actually heard before.

  34. Anonymous2:27 AM

    What a bigmouth egotist you are like most people in the tech industry. I can't stand reading your blog so I'm leaving half way through. People like you do a disservice to the fantastic activity that creating smart entities like software is.

  35. >if you review their code mercilessly enough, consistently enough, and publicly enough.

    I'm a big fan of code review (full disclosure: I work for a company that sells code review tools), but an antagonistic approach can backfire. People become defensive and shutdown. Handling the social effects of code review requires a different approach - more here: http://smartbear.com/docs/CodeReviewSocialEffects.pdf

  36. Anonymous9:58 AM

    You have an accurate description of the problem and complete ignorance of the cause. In all of those other fields you mention where incompetents are weeded out, the capable practitioners can practically get rich.

    The reason incompetent programmers don't get weeded out is the same reason that super-productive developers don't earn five times the norm: It is much more difficult for decision-makers to judge competency in programming than in other fields.

    The results of a physician's work are readily apparent to the patient and to other doctors. A lawyers briefs are read people who wield power over him -- supervisors, judges, and opposing lawyers. Who reads the programs you write? Nobody, except maybe junior programmers who are assigned to do maintenance on it _long_ after you're gone.

    If project managers were required to read line-by-line every program written for their project and vouch for the quality, you can bet that incompetent programmers would be sent on their way and the best programmers would be amply rewarded. However, this change would vastly narrow the pool of available project managers, and would vastly increase the demands upon their time of these highly expensive people. (It costs just as much to pay a manager to read a program as it costs to pay a programmer to write it.)

    We put up with incompetency for the same reason we under-reward excellence: it costs too much to obtain the information needed to do otherwise.

    More bureaucratic hoops to jump through in the way of programmer certification would reduce the supply of developers without much increasing the quality. We all know of programmers with advanced degrees or certifications who program terribly, and people without them who do fine. And even if certification requirements weed out a great many of the people who _cannot_ do the work, it does nothing to ensure that people with the intelligence to do the work right actually take the pains to do so -- especially when the manager cannot tell the difference either way.

  37. Anonymous2:17 PM

    Great article, couldn't agree more!

    A good start for those who want to be better programmers is the book Clean Code, from Uncle Bob.

  38. Anonymous2:38 PM

    Agreed 100%!

  39. Anonymous5:38 PM

    Why this bother you man?
    Why you take it personally?
    Just enjoy your life.
    You don't take responsibility as the IT-industry master mind.
    Have a nice girl-friend, and a nice pet, and enjoy your work, and your life.

  40. Anonymous6:25 PM

    What a hypocrite. You despise what you were and how you got started. Maybe you should leave the industry and start cleaning Porta-Potties.

  41. Anonymous10:28 PM

    Good post, Jay, but I'm not that pessimistic. Being in a managerial role, I think most NNPPs are a result of poor management. I put down the reasons in this post.

  42. This comment has been removed by the author.

  43. Theoretically I like your advice:

    The good programmers can refuse to work with bad programmers.

    But I think that today that's not really practicable any more!
    At least not in enterprise IT... the times when programming was a one-man show are long over in this area.
    And like in any other area where you have to deal with social interactions, you will have to do with individuals with very different motivations/backgrounds/skills ...

    I don't think that just refusing to deal with situations that seem not optimal is the right solution. But I am not sure ... sometimes it probably IS the right way to go ... the question is where do you draw the line?

    I wrote a post about a similar topic:

    From coding whore to opinionated developer?

    ...and got some critics in the comments.

  44. Great post Jay. I couldn't agree more with your sentiments. Although apprenticeships are a great way to assist with a solution I wish more developers were self-aware all around. High confidence, low competence is running rampant in our industry.

  45. "If we didn't spend most of our time making up for terrible programmers"

    Jay what makes you think you aren't one of the terrible programmers others refer to? It's all a matter of perspective. Share what you know and hope that others smarter than you do the same. Refusing to work with someone rather than help them is just asking for karma to kick you in the balls :)

  46. Anonymous12:28 PM

    I worked on a project team of eight developers, two of whom were NNPPs. The thing that really got under my skin was when they'd go back into a class I referenced, rewrite the whole bloody thing injecting several errors along the way, and then assume it worked correctly ... leaving me to debug their code. Ninety percent of the time, the results they were trying to achieve were already the results produced by the class as originally written.

  47. I think the problem arises from an invertion in importance that happens in our field.

    Programmers are considered the least important persons in developing software. Well, testers are the least important, where people actually have formal testing teams (which, thankfully, is becoming the norm).

    Let's see.. first, the person ultimately responible for gathering ALL requisites is the programmer. No one before him has done that -- if they had, you could just feed it to a CASE software and be done with it.

    Second, performance is dependent on the programmer to a large scale. A fucked-up architecture can certainly hamper any efforts, but there's just too much that happens at coding time.

    Third, a good architect has to keep up-to-date with programming, because our field is still evolving too fast. And the only way to do that, of course, is programming. In other words, you architect has to program, be that his job or not -- and you would do better if it was.

    Fourth, programming is THE most intellectually demanding task in software development. You need to have understanding of the general, you need understanding of the particular, and you need to do so with precision. And, preferably, while jugging performance, usability, easy of change, refactoring, etc.

    Fifth, programming is the task were you receive most benefits out of experience.

    Sixth, programming requires talent. If that seems strange to you because a lot of programmers out there clearly don't have it, remember that most software projects either fail or are borderline useful -- usually in the absence (or proscription) or alternatives.

    You can add to this list. It's not hard at all.

    Now, if we were doctors, then the people who take patient history would be the ones telling the surgeons what they have to do.

    So, ultimately, the activity that would most benefit of having the most competent and experienced professionals is the activity we leave to newbies with barely any experience -- or proven competence.

    Is it any wonder that... well, is ANYTHING in our field any wonder given that? Go check succesful software stories or companies. You'll find that programmers have importance completely at odds with what you find in the Corporate world.

  48. Anonymous5:17 AM

    This is life :). If a programmer doesnt' produce anything we sue him or we make him undestand that his path is not the good one.

  49. Try nailing the net negative producing managers who support NNPPs.

    Face it. Managers suffer when projects are overbudget and out of time.

    Why should they worry when they can get NNPPs to code up the work on time, to budget ? Who is really going to look under the carpet ?

  50. I am a web developer myself, mostly building dynamic applications.

    So often, I have to work on systems made by these NNPPs, and admittedly, I have made a niche market out of fixing the problems they cause.

    So, from a selfish business perspective, NNPPs are what puts food on my table, however, I do wish that programmers were held to a higher level of accountability, so as to not to slow down our industry, and cause so much problems.

  51. Anonymous11:26 AM

    Ego abounds in this field.

    Everyone is convinced they are the best (or at least in the top ten) and everyone else is a detriment.

    The definition of "net negative producing programmer" is so subjective that it can be applied to just about anyone at some point.

    Seriously, this is the one thing I find frustrating about my otherwise rewarding career. Everyone with a few years in the game thinks that they are an authority and in a position to cast judgment on everyone else.

    I'm shocked that anything gets done in some places because of the work put in by some to not only assert their ideas but to subvert those of their colleagues. I think this is one of the many reasons that churn is so high in this field.

  52. Doctors and Lawyers spend half their lifetimes working and studying for nothing. That is why only the rich kids and extremely few lucky grant students become Doctors and Lawyers.

    You yourself do (did?) not have a Uni degree. Nor do I, yet I am consistently the best coder I work with. No that is not a pun or a foul up of words.

    You and I would have been disqualified at one point. No money in a country that requires even grandma to maintain a job to survive.

    In my opinion if you want to look for the blame, it sits on the shoulders of you and I.

    I am now spending a good proportion of time training Rails developers for free. I am paying it forward to try and fix the problem.

    All we can do is influence, impact, and guide NNPP's so that they become good programmers.

    I will speak for LA and Holland, and I will leave it up to you guys to cover India and the US.

  53. Anonymous12:29 AM

    Today, in 2013, would you hire a 2009 version of yourself? would than person now be deemed a NNPP?

  54. @anonymous, in 2009 I'd already gotten pretty far in my career. I would easily hire someone with similar experience, and I would hope they wouldn't be NNPP. You could go farther back and find a point at which I lacked experience, but that's not the same as being NNPP.

  55. I agree with Jay -- NNPP has hardly anything to do with simple experience. In fact, most NNPP I've met had some years of experience, sometimes many years of experience.

    Even the one beginner NNPP I met was strikingly different from other beginners -- not ignorance, but a complete inability to grasp essential concepts.


Note: Only a member of this blog may post a comment.