My coworker is a nice guy, but his performance is sub-par. Do I tell my boss? [closed]

Question

I was placed on a project about three months ago that was until then under development by a single, newly hired developer because it was falling behind. To be fair, the project is an interface to a medical device that has a lot of subtleties and is relatively complex, so placing one person on the project who had no experience at the company was probably a bad decision from a managerial perspective.

Anyway, once I started working on it I realized that... well, it just didn't work at all. The UI looked nice, but it didn't actually do much of anything, and what it did do it was doing incorrectly. Again, to be fair, much of this was due to the fact that this developer was not properly prepared to write an interface to our device. However, I also quickly realized that the code that was in place was brittle and extremely hard to maintain.

Now I do not claim to be the best programmer in the world. I work with a lot of very smart people who are better developers than I. I do however try very hard to write code that is as simple as it can be and robust. I test my checkins. If I see that my code is getting messy and hard to work with early on I change it. I have had a few talks with my coworker in an attempt to help him write better code. This is a bit tricky because a) he has 20+ years of experience in the field and I have only 5, and b) he was hired as a so-called "UX expert" and others view him as an experienced individual.

That said, I just don't see it. He is a very nice guy and he is reasonable, yet time after time he checks in code that is fragile, works only in the most optimistic of cases, and 9 times out of 10 I end up fixing bugs in his work. His code just seems amateurish and he obviously doesn't have the level of experience that he claimed to have when he was hired. It has come to the point where the extra hours I spend refactoring his code and fixing his bugs have taken a toll on me. The way I see it I have two options:

1. Do nothing, bust my butt to make sure this product goes out on time and is robust and wait for him to fail in the future (I will not be working with him on this project after the initial release.)
2. Tell my boss about his performance. My boss is a reasonable man, but I just feel awkward taking this approach. I don't like to 'bash' (for lack of a better term) my coworkers and I don't know how he will take it.

So, that's about it. I have tried to work through this with my coworker by explaining why his implementation won't work or how his code could be made to be more maintainable, but he continues to make the same mistakes. I'm very interested to hear how others have handled similar situations, especially people in management currently. Thanks in advance for any advice you can offer to me.

Answer 1

I would at least consider the possibility that if he was hired as a UX guy, it may well be that nobody really expects really great code from him -- they may expect that his code should only be basically a prototype that outlines the UX, and it's up to other coders to write production code based on that.

Now, I'm certainly not saying that is the case, but it wouldn't strike me as terribly surprising. At least in my experience, it's not at all rare for UX people to primarily produce things like prototypes and storyboards. If anything, if the guy was really hired specifically as a UX specialist, I'm borderline-shocked at the notion of his checking in code at all. I'm pretty sure I've never seen that done.

If the guy really is a UX specialist, the cure may not be to try to get him to produce better code, but to get him out of coding (at least anything but prototypes) entirely. If he's honestly good at UX design, the real mistake is probably with even asking him to write production code at all. Instead, he should probably be (at most) working in a UX-prototyping sandbox where his result is used to guide the next round of real code that's produced, but never checked in as production code at all.

Answer 2

I try to have a rule that I always keep my boss informed of things that affect the project. Positively and negatively... and in cases like this I try to blame things like the code as opposed to the person that wrote it. It sounds much less like you're bashing a coworker and more like you're trying to improve the quality of the product.

From a management standpoint there are 3 common ways to deal with employees in this situation:

1. Get their weaknesses under control
2. Play to their strengths
3. Get rid of them (not really your choice)

Get their weaknesses under control by seeking outside help.

Hey Boss, I'm a bit worried about the state of the code... it's pretty fragile and breaking a lot. It'll take some work to get it into a state where I feel that it can be trusted. Is there a possibility that I could borrow one of the architects for a day or two to see if we can come up with a good design?

You're not asking for another person to join the project, you're asking for more of 'expert input' for a short amount of time. Produce whatever docs that they need, UML diagrams and code snippets if that's what the architect wants. They'll see what state the code is in and then your boss will have someone else echoing your opinions.

From the meeting, you'll hopefully get a better design that both you and the other dev can follow without him screwing a lot of it up. This is what designs and specs for in a lot of cases: reducing the damage that bad devs can do.

Play to their strengths

Hey Boss, I'm working with the code for project x, and it's gorgeous. The code, on the other hand, could use a fair bit of work. I think the project would be better off if [ux guy] was able to focus more on the UX, while I do some refactoring in order to get it into a more stable state. Once the UX is solid, project b could probably use his Midas touch.

Here, your boss is likely going to see right through it; that you're telling him the other dev isn't very good... but at least you're not being an asshole about it. And if he is honestly really good at the UX work, then he might find a stable position hopping onto each project and making them great from a usability standpoint. I imagine that he'd like it better that way too.

Answer 3

Stop repeatedly fixing his mistakes. He won't learn; I know I wouldn't.

Programming is largely a logical task, but it also involves memory recollection. When you often write common code, you recall how you implemented the solution last time, rather than figuring it all out again. If he's never implemented the correct code, I can see why he keeps repeating the same mistakes.

Show him what he did wrong, and perhaps fix it the first time. For any further occurrences of the same incident, have him implement the fix that you showed him.

Answer 4

I'd be really careful for a few reasons:

1. How are you sure you won't be working with him after the initial release? Your management could think, "What a team, look how they delivered this awesomeness together!" and want to keep you together.

2. If you do go to your boss, how technical do you want to get in trying to explain your position? How much documentation do you have of your co-workers poor performance?

Those would be the gotchas I'd note from what you asked. I'd suggest you ask him about the code and see if he has some justifications for why it is the way it is. Perhaps he is running in circles while coding it up which causes some issues. The circle is where you code something then through a series of changes end up at nearly the exact same point that you started as someone's list of changes cancel out in the end. I've been in those situations where it is changing and undoing change after change that gets tired pretty quick.

Answer 5

What are the consequence if you don't redo all of his work and just let the project fail? The consequences to you I mean.

Surely somebody of his experience level and position didn't get there by accident so either his work isn't as bad as you perceive it or his entire career is composed of people like yourself carrying him along.

If you are working more than 50 hours a week on any project then their is something seriously wrong and you disservice yourself by not calling it to the attention of the PM or by leaving. I am a strong proponent of working SMARTER not HARDER.

Work a smart 50 and if the project doesn't work out then IT IS NOT YOUR FAULT. If it fails because of his incompetence and they blame you then that is probably not the environment you would want to work for anyway.

So many friends of mine work WELL over the typical 40/week on a mismanaged project because they are afraid of failure when they don't realize how little the failure OR the success directly affects the whole of your career.

Over 80% of projects fail, there is no shame in that.

Answer 6

Its called a peer review. Your manager kind of expects it from you, and has to be informed where his valuable developer's time is being spent. I am surprised he doesn't know about this already - but again, I have seen worse.

Don't talk to him in terms of the other guy, talk to him in terms of the daily work you do. If that means dissing his code, so be it. Go armed with checkin links etc. to give some kind of proof of your daily work. Your manager might want exactly this from you btw - he brings the 20 years UX in, and you get the robust code. Instead of doing wireframes, he just writes prototype level code. Talk to your manager.

And hope you were not hired as his baby sitter. Good luck.

Answer 7

Will the project launch sooner if you didn't have to rewrite/redo his work? Will it help come in under budget? You don't have to bash, to privately raise your concerns. Here is where most people make a mistake, they complain without offering solutions.

Are there specific recommendations that you can offer to your boss that will improve the outcome. Better documentation? Robust user testing? Your goal is to make the company, the project, your colleague and yourself successful. Pretending that there is no issue ensures failure at all for three of the four---and you're not the lucky one.

Answer 8

You need to go to your boss asap and plainly tell him what you said here.

First off, this is a medical device. Could somebody be injured or die if there's a bug? Code that peoples' lives or health depends on needs to be as robust as humanly possible, not buggy junk written by an optimist for the best-case scenario.

Okay, putting my ex-manager hat on... you have no idea whether your boss knows about this, or what his response will be if it's news to him. But if he doesn't know, he needs to, and you shouldn't second-guess him by hiding this information. If he's okay with your coworker coding this way, he'll let you know.

I ran into a situation like this many years ago. A "networking guru" and I were working on a proof-of-concept as contractors. In fact, he was hardly getting anything done, and mostly goofing off. One day, our boss told us we had a demo coming up. Soon, the "networking guru" started getting a lot of hush-hush phone calls, and he finally told me he was going to leave before the demo to take another contracting gig. As soon as I could get our boss alone, I told him about it. He dumped the "networking guru" and brought in someone I recommended, who cranked out more code in three days that the "guru" did in three months. The demo was a smash hit - but if I'd kept quiet, the project would have completely failed.

Answer 9

Yes, do tell your boss. Then you'll see if it ain't you the one out of place there. It is the manager's job to know how the team is working out and if the boss haven't noticed yet maybe they just don't care as much as you do for proper coding - like many, many places I've been.

And among all those different work places, if I got a hand full (meaning 5) of friends out of all of them that's already a big number. They all had nice guys and gals but you won't lose a friendship over doing your job - if you do lose them that's a good thing. In your instance, he'd be valuing the job more than you.

Granted, it's not an attempt to get him fired. It's just showing your concern on the project well being, which is why you all are (or should) be there.

You've tried talking to him, after all, and if you don't do anything you are actually risking your job there.