9

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.

Improve this question
2
  • 1
    None of the problems you describe seem out of the ordinary for a large code base. I don't see what you're asking here aside from "How can I improve my team?" That's a fairly broad question with no specific answer. Solutions could range from tightening up your hiring practices through formal/informal training programs. I do think, however, that excellence is promoted NOT by simply trying to discover and eliminate incompetence, but by instead providing examples of good practices.
    – teego1967
    Nov 11 '14 at 12:35
  • Why don't you like code reviews?
    – jcm
    Nov 12 '14 at 11:12
8

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

Improve this answer
4
  • Heck no I'm very flexible and able to apply techniques I learn. That's why I asked. I've been programming for 30 years really, and nothing I used back then is still used today. I can adapt. I like this answer.
    – Jasmine
    Nov 12 '14 at 16:16
  • @Jasmine: You might find the following..enlightening: thecodelesscode.com/case/142?topic=code+reviews
    – NotMe
    Nov 12 '14 at 16:23
  • "That's not tattling". This. Similarly, journalists don't say, "no, we don't proofread or edit articles in our organisation, because correcting typos or tightening up prose just leads to hurt feelings". Well, it shouldn't. Being corrected or improved is part of your freaking job, everyone needs to learn to do it :-)
    – Steve Jessop
    Jan 9 '15 at 2:43
  • At my workplace, we use non-public code reviews, and we require them for any and all code that gets submitted to our repository. You may want to consider something like this, as it would avoid public embarrassment while also improving code quality.
    – TheSoundDefense
    Feb 19 '20 at 22:40
4

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.

Improve this answer
6
  • 6
    Lunch and Learn? No thanks - formal education and training session should be on the company clock, not mine (I don't mind reading and mucking about in my own time, though). Plus, in many jurisdictions you can't replace a break with training.
    – HorusKol
    Nov 11 '14 at 2:26
  • 3
    @HorusKol: Who said Lunch and Learn wasn't on the company clock?
    – Eric
    Nov 11 '14 at 3:13
  • Enforcing a zero warnings policy would go a long way toward addressing some of this.
    – Jasmine
    Nov 11 '14 at 4:15
  • 3
    @Eric, lunch time is never on the company clock. It is insulting to ask people to give up their personal time for training.
    – HLGEM
    Nov 11 '14 at 5:35
  • 3
    There is nothing "insulting" about an occasional lunch and learn unless one works in a dreadful workplace where every second "off the clock" is a relief.
    – teego1967
    Nov 11 '14 at 12:39
4

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.

Improve this answer
3
  • This is my feeling on the subject occasionally. What bugs me the most sometimes about the incompetent person is the fact that they have a job at all.
    – Jasmine
    Nov 12 '14 at 16:18
  • @Jasmine - I agree to a point, but I think companies need to quit complaining about not being able to find highly skilled people and start training them. Getting a CS degree is not a language certification and those don't prepare you enough either.
    – user8365
    Nov 13 '14 at 2:24
  • Yes I agree, many of the incompetent people over the years have had degrees or certifications. Passing tests and solving real world problems are different things. And yes, I agree the way to deal with it is training.
    – Jasmine
    Nov 13 '14 at 16:10
1

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.

Improve this answer
0

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.

Improve this answer
3
  • 1
    You are approaching this from a manager's perspective, but Jasmine is asking how to deal with this at the peer level.
    – Eric
    Nov 11 '14 at 3:15
  • As she is a senior developer and "people seem to want my leadership and I give it willingly and positively" - I don't see the difference, apart from getting management to sign off on it - and the first step becomes even more relevant. If you don't want to step up to be a leader, then there's not much you can do about how other people in the team work - they don't work for you.
    – HorusKol
    Nov 11 '14 at 3:32
  • In my current team some of this would work, but in one of the firing cases I mentioned, we did all these things and letting him go was the only remaining option.
    – Jasmine
    Nov 11 '14 at 4:17

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .