software engineers, please comment on this personnel issue

I’m a new IT supervisor (lead). Not manager-level. I have over 14 years of enterprise development in various MS shops. This is my first supervisory role.

I have a developer that is quite enthusiastic about coding, to put it mildly. Let’s call him W. He will routinely stay up for days at a time coding on projects that aren’t even on the radar let alone an official project list.

The two issues I’ve got are:

  1. the quality of his code. Or, should I say that his code is the most over-engineered code I’ve ever seen in all my experience. It’s so complex that my team’s turn-around rate for defects has increased by 3. Both of the other guys are complaining about it. He’s a very intelligent guy, so I have a suspicion that it’s “Job Protection Code” as I have had plenty of experience in the past working with these types, and frankly I don’t tolerate it.
  2. W has literally re-coded 80% of the entire application (in the manner described in #1) on his own time, completely on his own). He’s gotten away with it because he did it in the scope of an officially-assigned project. It’s like re-designing the car because you want to replace a headlamp. This is causing some waves with the rest of the team, as there is no way they can compete in the workplace with someone who stays up for days at a time. They have families.

Basically, I need to tell this guy that his code sucks, and he’s demoralizing the rest of the team, and to chill out with the work-related code on his own time. But in a nicer, politically correct supervisory type manner that won’t make him want to quit.

Can any IT manager type with more experience provide some mentoring and insight?

Thanks in advance.

I’m not a manager, but I gotta ask - why don’t you want him to quit? He writes bad code and demoralizes other people on the staff. Sounds like a no-brainer to me.

Tell him what he is doing wrong and explain how you expect him to change his ways.
If this causes him to quit, who cares?

If you don’t deal with him, be prepared for others to quit.

Start by setting the scene. Implement a set of development guidelines. Do this for the whole team, so that he doesn’t feel singled out.

Include these points.

[ol]
[li]In the guidelines put an emphasis on readability and sustainability[/li][li]Explain that most of the time the compiler will do a better job of optimizing than he can, so readability and sustainability are the most important points to your guidelines. Tell them that if you run into slow sections of code once it is done, you will use a profiler to help determine what needs to be optimized.[/li][li]Explain that you cannot afford to pay to have code written twice, so if code works, developers must not rewrite it just because it is different than how they would do it.[/li][li]Explain that the hidden cost of development is support, and this is why readability and sustainability are so important.[/li][/ol]
Allow them some input on the guides. They’re the ones who have to support it. Tell them that there will be peer guided code reviews. (And then I always start by letting them review my code and I usually leave some things in so that they can ding me a little.)

Be sure that you enforce your guidelines consistently - but also understand that they are guides, and there is room for *some *flexibility.

Note that this is a process. Praise improvements, point out errors and keep regular notes. Be prepared - find out from HR what steps you can take if he ignores your guidelines. Keep notes (I know, I said it twice, it is very important.) I had one woman who would always say: I didn’t know you were going to do a code review today, so I’m not prepared. Make sure that they understand their code is supposed to always be written with the guides in mind.

Understand that you can only do what you can do and accept that you may have to let him go. If he pulls down the team, you all suffer. It is never a good time to lose someone, but also know that everyone can be replace.

Years ago I wrote a set of guides based on principles in Writing Solid Code by Steve Maguire. They are outdated, are more geared towards C++ and I would not use all of them today, but if you want, PM me and I will email you a copy as a place to start. Even if you don’t use any of it, it can help set your mind thinking.

I had a guy on my team who was a lot like the man you mention. He was quite sharp, but not at all a team player. We were bought out and we were all let go, but I suspect that I would have soon had to deal with him. He just could not accept the idea that other people’s code was acceptable. His next boss has the same problems and complaints even to this day. (I know the man’s current boss quite well.) He has said more than once to me: You know, you warned me, but I pretty much ignored you. I wish I hadn’t.

What do you mean by ‘over-engineered’? You later say his code ‘sucks’? Over engineered usually means including unnecessary functionality, or it may just be inefficient code, or just code that doesn’t work. Why has his coding increased the work load for others? Are you allowing him to move on to new projects before he has sufficiently tested and debugged his work? That would be your fault for not making him complete the job. Also, if he spent a lot of time re-coding your application on his own time, how did that migrate into the your application? Do you routinely allow programmers to change the application outside of any organized plans? Hate saying this, but your fault again.

I’m sure you don’t want to discourage a productive worker, but it doesn’t sound like he’s actually being productive, just expending a lot of effort. Try making him be responsible for the full development cycle of well specified projects. Put time limits on, and hold him to the schedule. Make sure he tests and debugs the code, documents it properly, and don’t let him move on until he completes each project. When problems arise in past work, make him stop what he’s doing and go back and fix it. If he likes coding on his own time, don’t interfere with that, just don’t allow him to integrate his hobby into the real product.

I’ve worked with a few of that type, not as a manager, but as a fellow employee.

Usually these guys had a prof who told them that many of the standard libraries are faulty, and that they should write their own I/O libraries & drivers. They come into the real world, and they still want to write their own code for everything such as calender libraries & date functions, and of course never ever use any standard libraries or anyone else’s code, because they were taught in school not to trust other people’s code.

Despite their hubris, thanks to their newly minted computer science degree, they don’t have the experience or knowledge to be rewriting those sorts of things, and they end up writing crazy spaghetti code filled with leaps of logic that no seasoned programmer would make just to improve the speed of an algorithm.

This developer also doesn’t understand that existing code & libraries have been tested, not just by developers, but by end users, and by trying to reinvent the wheel they are bringing in new potentials for errors and incompatibilities.

Because in school, most projects were individual, not team based - they also do not know how to work with other people’s code, or how to adhere to standards.

If this person is one of these, you need to create a structure & standards including which libraries need to be used for any projects, how functions must take input & return data, how class structures should be set up, and how documentation must be done. As a development team the entire group should have input on these standards, but as a manager, the decisions should be yours in the end. The standards should be exacting - leaving little margin for overly creative measures that would lead to bad code.

In a way, you need him to become a code monkey instead of a programmer in order for him to learn. As a code monkey, he will learn that programming is not just an individual task, and that good programming means creating code others can understand and work with.

If this developer continues to rebel after the standards are set - then turf him.

I agree with the previous posters. You need to tell him something like this:

“Your code is the most over-engineered code I’ve ever seen in all my experience. It’s so complex that the team’s turn-around rate for defects has increased by 3. I have a suspicion that it’s “Job Protection Code”, and frankly I don’t tolerate it. Furthermore, you need to confine your work to ‘on-the-job time’ on ‘officially approved’ projects. You are demoralizing the rest of the team, and this cannot be allowed to continue.”

If he doesn’t like it and he quits, then you’ll have the opportunity to hire someone who can actually do the job in an appropriate manner.

Don’t worry about hurting his feelings. You are his boss; you can’t go out of your way to be his friend. It’s not possible for you to do your job effectively if you are worried about what your employees think about you. Make decisions that are correct for the business, and expect them to be followed. And if you can’t do that, go to your boss and tell him that you would rather step back into your old role as a developer.

The above is not meant to be snarky; it is meant as serious advice. Some people are built to be supervisors/managers. Some are not (myself included); they are much better suited to actually do the work that needs to be done, rather than to manage the people doing the work. You need to figure out which you are, and stick with that. It’s much better better for all concerned.

Is he bi-polar? (TriPolar? :)) Sucking down too much caffeine? Adderall? Meth?

Khadaji

Excellent advice, and extremely well-put. Thank you very much. I’ve had the book you mentioned cross my path, however C++ code is structured completely different than C# code. I did get a couple of tidbits out of it, tho.

Thank you again.

TriPolar

I inherited all this. It’s not my fault. Really!

Exactly. He just finished a custom SOAP handler because “he didn’t like the way Microsoft handled it”.

If I had my position when he did this, it certainly would NOT have made it past code review.

Agreed (well somewhat. I wouldn’t say completely), I do all my dev in c# now and that is why I wouldn’t use those guides any more.

It was a great book back in the day though. It shaped the way I think of development.

Suburban Plankton

You’re confusing a manager’s power with what I’ve got. I don’t have firing permissions, “official” counseling permissions, nor do I care about what the people think about me. If I want friends I’ll join the YMCA.

I also don’t want to have it come to the guy quitting and/or firings. I understand that in some cases that it’s necessary, however I believe that these are always final-only solutions and want to do everything in my power to resolve the situation first.

No snark taken, by the way – and thanks.

I guess I’m a little split on the issue.

The first problem you mention makes perfect sense to me. Readibility and sustainability are critical; he’s creating additionla cost with his poor performance in this area.

But I don’t quite understand the “he works all hours,” complaint, except to the extent that since he’s producing poor code in the first place, now he’s producing more of it.

But if he were a stellar coder, would the overnights still be a problem?

I would have to say “yes”. It would be a problem even if it was good code. This kind of behavior – right or wrong – is affecting the whole the team.

OMG! Now you have a non-standard SOAP handler which possibly does not handle standard SOAP communication - that really scares me! His name isn’t Mike is it?

With developers like him you have to lay down the law when it comes to creating custom things and let him know that hundreds of thousands of developers have used, tested, and submitted bug reports on those standard things, and his custom code is not tested and can never be as tested as the standard stuff because the user base is much smaller. If he wants to change Microsoft’s SOAP handler or anything else which is universally used, he should do it on his own time and submit it to Microsoft, not use it in a work related project.

Yeah I’d definitely say that really you just have to explain to him what the problem is and ask him to fix it. To do anything else is not fair on anyone, either him because I’m sure he thinks he’s doing a stellar job, and its not fair to let him carry on in that delusion, or anyone else as you are changing procedures for everyone rather than have the balls to call out the one guy hows actually the problem. I have been in this latter situation (where one person my development team is a problem, but rather than just call him on it, the management brought a whole raft of new procedures that were clearly just aimed at that one guy) and its just as demoralizing as working with the problem coder in the first place.

Though if you WERE going to change procedures anyway a good way to ensure engineering effort is well directed is Test-Driven Design, rather than just go tearing off and re-writing the whole app to solve some minor issue, engineers would have to specify their work in terms of creating a test that currently fails, but will pass when the work is done. This will mean breaking it down into discreet, testable, modules.

What you want to do is this:

First don’t be confrontational on your first talk. You don’t know why, you suspect but you don’t know.

So you start by going to H/R and getting information from them about documenting a talk, that’s not a write up but the first stage toward possible “correction of work habits” Make it clear to H/R this is not a write up or a disipline action but just you want it documented. They’ll tell you how to do this.

Next sit him down, and say something like "We’ve been reviewing your code (not I but “we,” if he asks who we is say “upper management”) and they’ve asked me to make a few clarifications with this.

I noticed that the code seems to be far more complex than is needed for the program to run, is there any specific reason for this?

Be prepared to show him specific examples of what is off. For instance, take a piece of the code and rewrite it so he can see what he’s doing wrong. Have more than one example

If he’s pulling something the response, well it interacts with this code, which interacts with that code and such.

This is a bluff and you must prepare in advance for this. I’m not a coder so I don’t know, perhaps you could try inserting some of your rewritten code and seeing if the program works at this point.

Next he’ll bring up, “but I worked my butt off in my own time.”

You then say “We are very appreciate of your work, and while I truly appreciate your dedication, you also have a responsiblity to yourself. It’s not good for you to be working constantly. If you enjoy coding perhaps you can find a personal project to work on.”

Essentially what you want to do is have a conversation with yourself. Since it’s your first time always present in a non-confrontational way.

Be yourself and ask the quesiton. THEN as him answer that questions as you think he would. Then you have to come up with a rebuttle to that question.

Basically it’s getting your ducks in a row, since he may have more than one answer.

When the actual time comes to talk with him, if you don’t have an answer, be honest, and say “I don’t know and I’ll get back to you”

Then when your done, take your notes and rewrite them and bring them to your boss and have a brief 15 minute interview with him and discuss what you’ve learned.

One thing to be aware of if your a supervisor without any “real power” and report to a manager, a lot of manager hate to disipline employees so they try to shove this off on their underlings, the supervisors. This is not acceptable. This is why before you start you go to H/R and ask what the line is.

If you can’t do anything effectively then you need to simply drop your notes from the conversation on the manager who CAN directly change this guy’s work and let him have the next line of conversations.

I’ve seen to many managers afraid to confront people so they push it off on the supervisors. If this is happening to you, tell your boss, the manager, I’d like to help but the company policy says “you’re the next step, and I can’t violate that.”

This pushes it back on the manager. I’m not saying this is happening, but new supervisors are often taken advantage of.

As I understand it: You have an enthusiastic worker who goes off on a tear in the wrong direction. It would be a long-term loss if he quit. Ideally, you want to train and mentor him so that he turns into a top-notch developer. If he is not the type that is teachable, then the sooner he quits the better.

This is a common problem, but to be honest it is usually indicative of a personnel issue more than anything else. It indicates that there isn’t clear technical leadership that everyone on the team respects. The problem is sometimes the over-achiever, but often it is the rest of the team that is resistant to change and wants him to ‘keep the pace’. Or it can be a bit of a combo. Make sure you understand which it is in your case.

Who is the tech-lead for your team? You? One of the other developers? Any architectural changes or re-writes really need approval from the tech-lead. This should be obvious to him and everyone else. Make sure he understands this clearly. If he violates the rule in the future, then his changes cannot be committed or must be backed out – regardless of how late he stayed working on them. You need to be firm about this even if it means you are late on a delivery because you needed his changes. At worst, this should only happen once before he learns.

In the meantime, the tech-lead or someone he respects needs to teach him of the technical downsides to his over-engineered code. Having too many layers or abstractions for just-in-case can be just as expensive as having to fix or rewrite bad code. Make sure he understands this. Walking through one over-engineered sub-system is a good way to make this example:
“Here, you have an abstraction to support any type of data-source, but we only have one data-source and are unlikely to have any others. If we someday need to support multiple sources, we can refactor and pay the cost then.”

A common reason why someone rewrites lots of working code is because he is still stuck in the mentality of “everyone’s code sucks, but mine”. Clue him in on the fact that experienced developers move beyond this attitude. They get good at looking at code with all different design styles and all types of formatting styles. That skill itself is critical to being a top-notch developer.

As others have said, just be honest with him. If your reasons are technically sound, then a mature person will respect them. If he is not mature, then he will either grow up or leave.

if you are the PM, he is supposed to work according to the plan and the spec that YOU establish and you then verify his work based on that. Now, in practice, you have to develop this plan and spec in consultation with your employees, including obviously him if he is the guy who will do the bulk of the work. During which consultation he can explain to you which features and designs are being added for what reason and then you can ack or else not ack.

It also helps to keep many backups of the code base, both in version control and in zipped files and in all sorts of ways. Just in case the job protection goes too far and has to be rolled back, and so forth.