The Incompetent

A Difficult Software Developer who lacks the intelligence or skill to do the job of writing software.


Relevant Podcast


Just as not everyone can be a professional athlete, or a skilled musician, or a medical doctor, there are people who are simply not cut-out to be software developers. These Incompetent Developers are often in denial, and refuse to abandon their career due to the large number of job opportunities and high salaries.

Picking out The Incompetent Developer can be difficult for the non-technical, but there are several indicators:

  • They blame their lack of productivity on a lack of company provided training.
  • They argue against technology, tools, and techniques that are “too complicated”.
  • They greatly overestimate their work (see “The Extreme Overestimator” Developer), and then still do not deliver on time.
  • Features are not implemented to specifications.
  • Features, once implemented, are riddled with bugs.
  • Skilled developers avoid or refuse to work with them.
  • When asked for status on their progress, they are full of excuses and are often defensive.
  • They apply for a management position (see “The Aspiring Manager” Developer) so that they can be “better utilized”.

The problem of The Incompetent Developer plagues the software development industry. It is a simple case of supply and demand, whereby there are not enough qualified software developers to go around.


When a manager detects that they may be dealing with The Incompetent Developer, their natural sense of empathy often leads them to assign less difficult tasks. Unfortunately, much as one cannot be a semi-competent heart surgeon, or a partially-competent airline pilot, one cannot be an somewhat-competent software developer. If you lack the competence to do software development, then you cannot even do simple tasks well.

When simple tasks prove to be too difficult, spending money on training is the next step normally taken. The fundamental problem here is that if The Incompetent Developer had the capacity to learn software development, they would have already – just as their more competent peers have, as competent developers train themselves.

There is a thought that having a not-as-productive developer on staff does not cause harm, but this could not be farther from the truth. They have two highly damaging effects:

  1. They destroy the quality of the codebase and they thrash about introducing broken code, and breaking working code (see “The Bull in the China Shop” Developer)
  2. They drive off competent developers who are fed up with working with them.

Ultimately, if The Incompetent Developer is the main developer you depend upon, your project will not get done. This leads to the sad conclusion that they must be invited to leave the development organization. If they do not take the invitation (usually issued by increasingly direct warnings), they must be terminated.

8 thoughts on “The Incompetent

  1. There is a third problem with this (which should probably go first): it sucks time from actual competent developers to review and/or fix the broken code.

    Even if your company’s procedures will prevent these people from doing too much damage (point 1), it will still mean *someone else* has to fix or re-implement whatever nonsense they wrote. Sometimes I’ve tried to guide an The Incompetent to a working solution for a while, only to realize the entire effort was fruitless, and just do the work myself. It was actually more work than just doing it myself, as I had to explain the problem, help them along the way, and then finally do it myself anyway.

    Even when I didn’t actually end up doing it myself, I still had to review the code, which is quite time-consuming when done right (often more so than doing it yourself). That’s okay if people take it as a learning opportunity (e.g. competent but junior devs), but with truly incompetent devs it’s just a waste of time for everyone.

    I also blame the increasingly ridiculous/large codings tests you’re expected to do before even landing an interview on these people.

  2. I’ve worked with a lot of software engineers who were a fish out of water so to speak. It’s a real morale killer for the other engineers who are stuck taking over their bug-ridden work. I don’t correlate intelligence with incompetence as they’re very different things.

  3. I would disagree with the classification of “the incompetent” as one problem. There are actually two different, but same-looking, problems that lead to a developer writing only broken code.

    1. A developer who is not proficient with the tools.

    2. A developer who is not proficient in the problem domain.

    E.g., for the task of writing a virtual machine provisioning system in PHP:

    1 would be if the developer does not know PHP or the framework well enough, and fights with the syntax or API.

    2 would be if they don’t understand why and how virtual machines should be provisioned, and consistently give incorrect results when interrogated, without any coding involved, how a system should behave in specific cases.

    The way of dealing with these two situations are different.

  4. Boy oh boy I hope I’m one of those…

    It’s hard to tell really, because I’ve only got 2 years of experience and I do show some of the indicators of being incompetent, but am I really, or am I just inexperienced?

    Is there a difference?

    There are other areas in which I know I’m very competent and I know how to assess them, but I don’t really know how I’m doing right now with programming.

    I see progress, but is it enough?

  5. I joined a new team with a developer who had the same amount of experience as me (2 years), only for those two years they were left to work alone on software projects with no support, not even a product manager. I worked at a company with a huge culture of learning and pairing, and lots of very experienced developers.

    I had a mentor and we paired almost every day for a lot of those 2 years and they were so good at teaching me how to reason about code, and what will happen if we do this or that. I really felt the difference, while the developer who was left on their own was really difficult to work with.

    Incompetence above can be inexperience, which isn’t always accrued just by spending time being in a job.

  6. Wow, listening you audio and “Bulshitting his way in an interview is a learned skill and everyone does it”.

    I spent years dumbing down my CV because I learned a lot, very quickly! Price to be gifted: what you are do not match at all expectations of what you should be. Cognitive dissonance kick in and your are kicked out.

    I had words because I did 100% completion on a test and they didn’t want to take me for the training. I asked why and been replied with : “We want an homogeneous group.”

    For incompetent developer, I asked “we will have a new hire and I need some of you to help me calibrate the test.”. Those who take it deliberately are the “good” ones.

    As for discussing with them: YES.

    When I was an external consultant for a company, I even took apart someone to tell him he won’t be able to escape his work and has to take proper actions: learning the materials and move forward.

    I also asked higher management to offer extra time to do some projects and have training. One of the guy had few days to learn a simple library and didn’t took it. Just wait and did something else. Then was confronted with it: “You had free time to learn it and could ask questions, why didn’t you ?”. Then he just bargain knowing we were close to schedule. So, I had to concede and let it go. We concluded he could not learn anymore and he got fired.

    And ironically, I wrote this today: I’ll update it to include this page. I believe both go in pair.

    I did need to get a piece of paper. Not because of incompetency, or at least not in development. I knew I couldn’t pass an interview. All good technically, but unable to play the social game and over sell myself.
    I always liked test based on doing stuff and contests. Never on “selling myself”.

    As for learning stuff, I learn on my own, but if required to use specific technologies, I’ll do it at work.

    For the pressure, it’s manageable. When I see pressure comes only because it has been decided, I notify it: could have been avoided! If it repeats, there is other places with better working conditions.

    For the Crystallized intelligence, that’s good, but the tip of the iceberg. Fluid intelligence go further and helps the former.

    Asking to implement something using not well known technologies is something I always wanted to do…but it’s very hard to have the companies accept this. Instead, I gave mathematical problems. These are useful, because some dismiss them as “not related to development”.

    Another trick is using public projects:
    You can quickly see the versatility and breadth of covered projects and technologies.

  7. Great post. Agree with most of the points here.

    I wondered if someone’s inability to not do a task is because of inexperience or incompetence. In some cases, yes it was lack of experience in that domain and the technology stack. However, folks who had learning attitude were able to pick up things in a few months.

    On the other hand, few folks did not have the learning attitude and continued to give excuses, however, during 1-1 they claimed to have delivered features (riddled with 100s of bugs, which was not highlighted). And blamed slowness of delivery on lack of training. With the wealth of resources available today and given the fact that all most all the software in the stack is open source, “lack of training” is just an excuse for being lazy at job. As a developer you are expected to read docs, debug issues, propose solutions.

    The main problem with these developers is that it kills the motivation of everyone in the team (includes co devs, leads, managers, product managers). People will just leave because of such people with really bad attitude.

    Personally, I have had a terrible experience because of “incompetent” devs (let’s say, really lazy and highly-unprofessional devs). Many days I hated going to work because I had to work with these folks. I wished I never worked with these people ever again.

    I would like to hear from others if there any strategies to deal with this situation.

Add your thoughts