How to Handle Incompetence?
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.
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.
Great post!
Just to add something on the topic of laying people off: apart from the labor laws and schedule implications, it might have adverse effect on the morale of the rest of the team depending on how it’s done AND perceived (and those are different things!) There’s some great research on the subject (for example: http://www.amazon.com/Positive-Leadership-Strategies-Extraordinary-Performance/dp/1609945662/)
Where I work we have some guys like that.
It’s hard to deal with them, because they have more years programming than me and they are actually “Architech” and I am a system analyst.
Even with code review and code style rules is not easy to say that they could write better and clean codes.
Of course, this assumes that you are not the one saying to the ‘incompetent’ “we must do things the (my) right way”, etc. That there are not best practices that caution against the current approach and that maybe more research (or maybe just listening to alternatives) would be a good thing.
You’ve got to remember that sometimes senior developers don’t hold their tongues when the not so senior know-it-alls ignore suggestions that are the result of years of experience; that perhaps they got to be senior developers for a reason. There is something to be said for many years of experience you know. While the technology may have advanced we senior developers see many of the old wheels being re-invented and similar problems being re-discovered as if they were new.
Mark Twain said “When I was a boy of fourteen, my father was so ignorant I could hardly stand to have the old man around. But when I got to be twenty-one, I was astonished by how much he’d learned in seven years.” Sometimes developers have the same sort of epiphany about senior developers and architects when they get to be around 30. And sometimes incompetency is in the eye of the beholder.
In my area (half planet away from Silicon Valley) the main problem with these seniors is that both management and customers love them. They never bother them with questions, they never say no to dumb specs; they just type at the speed of light and deliver code on tight deadlines.
Their secret? Skip all time consuming tasks that do not produce immediate features: learn new tools or techniques, fix unreported bugs, update documentation, remove unused code, test code, read non-fatal error messages, commit to version control repository, think about code design… A typical workday goes as follows:
1. Find file that produces desired screen
2. Move editor to last line
3. Paste bunch of code from another location
4. Tweak to add new output
They also have awesome time-saving tricks:
– Find test case that doesn’t trigger obvious bugs
– Disable error reporting in development box
– Convince client to use 10+ y.o. runtime
– Edit live files from Production server
Sure, they produce unmaintainable crap that does not even work as expected, but they have an awesome ability to slip catastrophic bugs in the places that elude a cursory review. Bug fixing (if ever necessary) can always be billed to customer (an added plus).
Then he retires, app sits abandoned for a year and finally you inherit the codebase one week before a vital deadline—and it soon becomes evident that not only can’t you match Seniour’s performance but you’re also unable to complete the simplest tasks in a timely manner.
It would be Interesting to know what “good engineering practices” means, because in the software industry it’s more about religion than actual engineering. But that’s, I guess, more because software engineering is still pretty much undefined science. When creating software it really has really nothing to do with engineering. It just about delivering value, and as long we cannot prove that value is a variable factor over time and the importance of how you write the code is the most important factor (and being able to verify it as such) you will be open for religious beliefs. And in religions everyone else is a heretic (incompetent).
The problem is when the majority of the team is incompetent and you are not. Short of leaving, what to do?
Me and my teammates once worked with an incompetent engineer (Huiya Liu) and drove us crazy. She is also a difficult person to work with. Beware if you ever have to work with this person, and hire at your own risk!
Huiya Liu
https://www.linkedin.com/in/huiya-liu-ba50714