The Incompetent

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

Discussion

Relevant Podcast

Problem

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.

Solution

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.

10 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.

    • There are more sub-categories, so I think the original classification sums it up quite well.

      For example there are developers that consistently deliver low-quality code: Misleading variable names, strange/unnatural code structure and modularization, like long functions or functions that are not split in a very logical/helpful way to reuse them. Deep indentation levels, copy-paste with tiny adaptations instead of DRY. Unnecessary or duplicate checks and validations.
      To my surprise such developers still can be quite clever.

      And then there are developers that just do not have the intellectual capacity of delivering high-quality software. That’s the ones that you to repeatedly find yourself explaining basic programming or domain-specific concepts to.

  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: https://www.linkedin.com/pulse/what-makes-good-developer-christian-baune/. 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: https://github.com/programaths?tab=repositories
    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.

  8. Dealing with a particularly frustrating dev right now, I wonder if it’s even fixable. They’ve been hired by ‘the boss’ without proper verification and technical questions, just because the interview went nice and the boss liked them. And they’ve been working with us for more than a year so it’s no longer a training period.

    The problem is they seem incapable of understanding what’s going on – does some basic coding, but doesn’t seem to understand concepts more advanced than a button on a form with a click handler. It’s so frustrating when I have to work with their code – reinventing wheels all the time, blindly ignoring all design of the software, and resorting to some ugly hacks instead of comprehending why certain APIs exist and what is the rationale behind them. Now the code is all sprinkled with their inventions and it’s not just a nuisance, it’s destroying the quality of the product and forcing extra work on everyone.

    The problem is the boss wants to keep them for some reason and keeps repeating ‘good work, good work’ whenever they report anything done, even the most trivial and basic things that took them 10x the reasonable time. Looks like the two are a good match – the boss wants to do product development and software design but they lack the knowledge and experience. And so they have an incompetent but obedient developer who will do everything they’re told to do without questioning and without putting any thought to it. So the boss feels like they’re getting the work done and adding value, but for the rest of us is just bloating the product with useless, half-done, and unusable functions that go against any proper design.

    At some point, I started asking questions about their work – trying to force them to put more thought into their work, like understanding what is the design, how it plays with the rest of the system, or how the end-users are supposed to use the feature. And inevitably pointing out the unfinished parts, functions that don’t make any sense for the intended user, or glaring holes in the logic. Did it have any effect? Yes, they accused me of being mean and nit-picking argued that their work is complete and done properly and exactly to spec and I’m the crazy person who causes problems for them for some reason.

    And they’re genuine in this, they just don’t get it, at their level of understanding everything is done – buttons and nice colors on the form, what the hell does this crazy talk about? The boss said ‘good work’ so it must be good, and I must just be jealous.

    I’m afraid I’m unable to work with them as there is no common level we can communicate and understand each other. The boss ignores my concerns of course, and I have no good way of getting rid of them. It’s a small team and we have a good product, but I think it’s becoming rubbish now and will be beyond any repair soon. From my perspective – a negative total worth employee, the company would be much better off without them.

Add your thoughts