Agile Zone is brought to you in partnership with:

Senior Java developer, one of the top stackoverflow users, fluent with Java and Java technology stacks - Spring, JPA, JavaEE. Founder and creator of http://computoser.com and http://welshare.com . Worked on Ericsson projects, Bulgarian e-government projects and large scale recruitment platforms. Member of the jury of the International Olympiad in Linguistics and the Program committee of the North American Computational Linguistics Olympiad. Bozhidar is a DZone MVB and is not an employee of DZone and has posted 91 posts at DZone. You can read more from them at their website. View Full User Profile

How to Handle Incompetence

06.26.2014
| 2300 views |
  • submit to reddit

We’ve all had incompetent colleagues. People that tend to write bad code, make bad decisions or just can’t understand some of the concepts in the project(s). And it’s never trivial to handle this scenario.

Obviously, the easiest solution is to ignore it. And if you are not a team lead (or something similar), you can probably pretend that the problem doesn’t exist (and occasionally curse and refactor some crappy code).

There are two types of incompetent people: those who know they are not that good, and those who are clueless about their incompetence.

The former are usually junior and mid-level developers, and they are expected to be less experienced. With enough coaching and kindly pointing out their mistakes, they will learn. This is where all of us have gone though.

The latter is the harder breed. They are the “senior” developers that have become senior only due to the amount of years they’ve spent in the industry, and regardless of their actual skills or contribution. They tend to produce crappy code, misunderstand assignments, but on the other hand reject (kindly or more aggressively) any attempt to be educated. Because they’re “senior”, and who are you to argue with them? In extreme cases this may be accompanied with an inferiority complex, which in turn may result in clumsy attempts to prove they are actually worthy. In other cases it may involve pointless discussions on topics they do not want to admit they are wrong about, just because admitting that would mean they are inferior. They will often use truisms and general statements instead of real arguments, in order to show they actually understand the matter and it’s you that’s wrong. E.g. “we must do things the right way”, “we must follow best practices”, “we must do more research before making this decision”, and so on. In a way, it’s not exactly their incompetence that is the problem, it’s their attitude and their skewed self-image. But enough layman psychology. What can be done in such cases?

A solution (depending on the labour laws) is to just lay them off. But in a tight market, approaching deadlines, a company hierarchy and rules, probably that’s not easy. And such people can still be useful. It’s just that “utilizing” them is tricky.

The key is – minimizing the damage they do without wasting the time of other team members. Note that “incompetent” doesn’t mean “can’t do anything at all”. It’s just not up to the desired quality. Here’s an incomplete list of suggestions:

  • code reviews – you should absolutely have these, even if you don’t have incompetent people. If a piece of code is crappy, you can say that in a review.
  • code style rules – you should have something like checkstyle or PMD rule set (or whatever is relevant to your language). And it won’t be offensive when you point out warnings from style checks.
  • pair programming – often simple code-style checks can’t detect bad code, and especially a bad approach to a problem. And it may be “too late” to indicate that in a code review (there is never a “too late” time for fixing technical debt, of course). So do pair programming. If the incompetent person is not the one writing the code, his pair of eyes may be useful to spot mistakes. If writing the code, then the other team member might catch a wrong approach early and discuss that.
  • don’t let them take important decisions or work or important tasks alone; in fact – this should be true even for the best developer out there – having more people involved in a discussion is often productive

Did I just make some obvious engineering process suggestions? Yes. And they would work in most cases, resolving the problem smoothly. Just don’t make a drama out of it and don’t point fingers…

…unless it’s too blatant. If the guy is both incompetent and with an intolerable attitude, and the team agrees on that, inform management. You have a people-problem then, and you can’t solve it using a good process.

Note that the team should agree. But what to do if you are alone in a team of incompetent people, or the competent people too unmotivated to take care of the incompetent ones? Leave. That’s not a place for you.

I probably didn’t say anything useful. But the “moral” is – don’t point fingers; enforce good engineering practices instead.

Published at DZone with permission of Bozhidar Bozhanov, 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.)

Tags:

Comments

Lund Wolfe replied on Sun, 2014/06/29 - 4:00pm

Many people out there feel your pain.  Hire the best people and let them run.  Unfortunately, incompetence is the norm in this business.  -10x "senior" developers are the norm.

They're often really good people, just not good programmers.  They usually don't have the passion for programming either, but they like the technical role, social engagement, and paycheck.  Positions have to be filled and you would have to be able to find someone better in the available talent pool.  You also have to have the hiring skill to attract and identify them.

You also need people who are loyal and reliable day in and day out who will remain with the company and know the applications.  They will usually do the simplest thing and follow the existing patterns, so if the new development is done well they should do fine.  Ideally, you just don't let them do new development.  This is where all the long term damage is done.  The same people who developed the existing nightmare applications are still trusted to develop the new applications, which they do the same way, of course.  Those companies who don't learn from history are doomed to repeat it.

Yogesh Kumawat replied on Wed, 2014/07/02 - 4:48am

 The former are normally student besides mid-equal developers, also they are prospective to be lower expert. Among satisfactory coaching plus kindly pointing absent their gaffes, they mind study. This is where sum of us permit gone although.  mri los angeles

Yogesh Kumawat replied on Fri, 2014/07/04 - 2:27am

 Obviously, the easiest resolution is to avoid it. Moreover if you are hardly a club clue (or something uniform), you can presumably affect that the quagmire doesn’t continue (besides rarely spell further refactor few crappy cryptogram).   freedebtconsolidationquotes.com

Comment viewing options

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