Promoting excellence without pointing out incompetence

Question

I like to promote excellence and I try to stay positive. Those are the two main driving forces behind my general attitude and I think it's gotten me pretty far. I've had a good career in IT for over 15 years now so the result speaks for itself. While I don't actively try to be a leader, people seem to want my leadership and I give it willingly and positively. I am a senior developer, not a manager.

Some things have frustrated me repeatedly over the years with various projects and I have noticed a trend of non-excellence in specific areas and a growing tendency for management to just not care, and in many cases not even know. These things cost us money, they frustrate developers, and they lead to bugs and lagging schedules. These are typically specific issues with specific developers, but direct approaches have failed to address them (with tens of individuals over the years). I don't want to do code reviews, because while we generally approach them with a good attitude, they never end well and typically the result is everyone feels insulted and work suffers for a while. Reporting these things to management has almost never been productive.

Examples are: leaving a lot of warnings in the code, commenting out thousands of lines and never cleaning it up or explaining it, loops with a break so it will only ever run once, testing a boolean for true/false and null, checking in broken builds, building rube goldbergs, not using utility classes and application constants, spelling the same thing multiple ways in the same code block, writing just plain logically invalid code. This may or may not come along with general incompetance such as not understanding the basic terminology of the languages you're working with (if I say you need to inherit an interface you need to know what that means), failure to understand basic logic (such as testing a number for greater than 10, then inside that block testing it for less than 5), that kind of thing.

Keep in mind I'm not talking about anyone specific, this is just something I've seen quite a bit and I want some techniques for addressing it. Code reviews and "tattling" are just not my style. I want to help the people improve, not get them fired. I've gotten two incompetent people fired over the years and it just made me feel terrible. These are generally smart, good people, with a proper work ethic, they just don't know what they are doing and can't seem to learn. So, what causes this and how do I help people improve?

I know there's lots of material out there on mentoring but these are particularly sticky issues, and none of the regular techniques have really worked over the years. People either seem to get fired or the problems never get solved, and I just don't think either of those are positive outcomes. I realize the question is similar to this one: How to deal with an incompetent colleague?

The important difference is I'm asking how to deal with this trend on a large scale in general, not with a specific person right now, and I have tried the answers given there, including getting another job, but you don't get away from this problem if you're in the industry long enough.

Answer 1

Code reviews and "tattling" are just not my style. I want to help the people improve, not get them fired.

I hope you understand that the entire purpose of Code Reviews is to point out areas that are good and areas that are bad in order to improve. That's not tattling and in a good, supportive, team building environment it won't lead to people being fired. Unless they just refuse (or can't) improve, at which point firing is a completely acceptable outcome.

Point is, there is absolutely nothing wrong with pointing out mistakes. Even in a public way that a code review allows. It's how you deal with those mistakes that can lead to problems.

I've gotten two incompetent people fired over the years and it just made me feel terrible. These are generally smart, good people, with a proper work ethic, they just don't know what they are doing and can't seem to learn. So, what causes this and how do I help people improve?

I've hired/fired people and I've been fired myself: a couple times actually. One of the ways in which we, as humans, learn is through failure. Sure, you can do the right thing 100 times and not learn a single thing. But when you fail once then you've learned something: you've learned that that didn't work and it's time to try something else.

Being fired can be an eye opener. Most people want to do a good job and if they can't then they are likely to be unhappy as well which has it's own issues. Helping them make the decision to move on can be a positive change in their life. Whether they realize it at the time or not.

Regarding cause, well, if anyone knew why some people were incompetent and how to fix that then they'd likely be super rich...or burned at the stake; I'm not sure which.

The best you can do is try to help them out. Show them the way by doing things like using those code reviews you don't like to positive effect. Just remember, "some men you just can't reach..."

Answer 2

The key message is: you should not be the team police officer. Instead, you should introduce them to some good practices, potentially through Lunch and Learn sessions or similar, and then see if you can get them to agree together to try some out. You will likely need management buy in for some of these.

Most of the bad practices you want to avoid are covered in teams I work with by automated checking or self-selected, self-enforced group policies. For example, we have automated tools in the build that do static code analysis and report warnings when things are not properly checked. We collectively agree on enforcing a zero warning policy and the builds are monitored (by the team) to ensure compliance. Code reviews are instituted as standard practice: every change set is reviewed by another developer. In this way, no one is singled out for closer scrutiny.

Answer 3

Sorry, but everyone should have code reviews. Writers have editors. Athletes have coaches. Other fields of engineering have inspectors. It is very easy to fall into bad practices out of habit, time constraints, and low skill levels.

You're benefiting these people by pointing out problems and encouraging the continued use of best practices. It's the only way they're going to change. No one should expect to be perfect. Someone gets fired as a result of a negative code review? What is the alternative? Let them keep checking in bad code? You'll be the one cleaning it up and ultimately, your users will have to suffer.

These people have an opportunity to learn from a senior developer, so if they don't take advantage of it and try to improve themselves, they need to go find another job and not you.

Pardon the Rant

Can anyone take criticism any more? Do they really think they're perfect? Companies go bankrupt because of incompetence. School is over. Time for people to grow up and do their job.

Answer 4

I want to help the people improve, not get them fired.

The first step in solving a problem is admitting you have one.

People aren't going to somehow stop being incompetent if they don't know about it (and they won't). You're hindering your own effectiveness, and the growth of your peers by being selectively honest with them.

All of the things you brought up are clearly bad things. Sure, they might be minor things that you don't fix because there are higher priority things. But if you want your peers to improve, point out that these things are bad. Explain why they're bad. Explain what would be better. Lead by example with those things that are better. And importantly, provide feedback to people so that they know if/how they're doing well or not. If they don't have honest, open, correct feedback, they can't (reliably) improve.

I've gotten two incompetent people fired over the years and it just made me feel terrible. These are generally smart, good people, with a proper work ethic, they just don't know what they are doing and can't seem to learn.

There's two possibilities here really. You (and your manager/peers) are not great teachers. It happens. Not all learning problems are the fault of students.

But the alternative is that the problem employee can't or won't learn. As a software engineer that is a huge (and sadly, common) problem. Not only are they dead weight due to poor work, they drag down all of the borderline team members who look at such unacceptable work and think "if Bob can do it, then I can too". You should not feel terrible getting these people fired. You should feel angry that they would stay in a job where they were actively harming their team.

Answer 5

Start by pointing out general trends (like commented blocks, etc) and show how they hurt future development work.

Introduce short training sessions focussed on specific issues and improvements.

Write up a coding style and development guide and get everyone to sign on.

Praise individuals as necessary, but never publicly admonish them - save that for one-on-one's and personal reviews.