what to do when coworker hands off subpar work?

December 19, 2015 11:08 PM

A coworker handed off a Thing that turns out to need more work. I might be asked to explain why the Thing isn't done already. How can I handle the question gracefully? To be clear, I don't mind doing the remaining work, and I don't want to get Coworker in trouble. But I also don't want to protect Coworker at my own expense.

The details: I work on a piece of software that is supposed to change over to using a library that Coworker wrote. To help us change over, Coworker temporarily joined our group and wrote the change.

When I got it, though, I found some serious problems: a function that supposed to query the state was missing the part that looked for things matching the query, so instead it just dumped the entire state every time; another function that listened for updates never returned anything, because Coworker never called the function that sent the updates out to the clients; lots of misspellings and copy-paste all over. (I say these things because Coworker is a young woman and I've been going back and forth in my head whether she actually did a bad job or I'm just predisposed to conclude that.)

I could send this work back, but it's probably easier to fix it myself. From what was handed over, I can figure out what Coworker meant to do. Most of it even works. Moreover, Coworker has already moved on to another project, so it'll be a struggle to get enough time allocated to fixing this. In my field, thinking of specific changes is the bulk of the work. It's not worthwhile to go back and forth with her if Coworker is tempted to do the very minimum needed to turn each request around.

The question is, what do I say on Monday if someone says, "So, I heard Coworker handed off that Thing last week..."? I don't want management to think I'm bizarrely taking weeks to dot the i's and cross the t's. I also don't want to throw Coworker under the bus. People think of me as polite and competent, and I'd like to preserve both those beliefs.

I've already talked with Coworker about finishing the work myself. I phrased it as just, "It will need some work, and I suspect you have lots on your plate already." She seemed tense during the conversation but said she was happy to have less work to do. I didn't go into detail about how awful her work was, because I don't think she's under any illusions that she turned in good work here. Based on her other work, including the library, I know she can do better. I suspect she just didn't prioritize this one, because of the competing demands on her attention.

I've also emailed another coworker (also on the project) about a design problem I've been having fixing the work. During that email, I did allude to having more work remaining than I expected, but just one sentence describing my progress as "Well, I'm N lines in and counting..." I don't think that was unprofessional.

If it matters, both Coworker and I are super-new, both hired straight out of school. I've been here four years, Coworker two. We don't formally have a deadline on this work, but we're expected to make progress.

posted by anonymous to Work & Money (19 answers total)

It probably wasn't great code, and what I am surprised by is that she didn't check or Q/A it. Honestly, she probably doesn't know the best practices yet -- you mention she is young. What I suggest is that you take a hour and explain the gaps in the code. Even if she doesn't complete what she started, she would likely appreciate the time you take to explain to her and she will improve for next round.

If management asks, I would explain that it wasn't complete on her end, but don't throw her into the ditch. Something like "Hey it wasn't done when it was handed over because it was a little tricky, but we're working together to complete it. You can expect it by X."

Try to have some empathy as well - you were likely a bad developer when you were starting, too. I think only after a certain amount time and effort it will become clear it is because of lack of skill or effort -- which is a whole other problem you will have to deal with when that becomes evident.
posted by pando11 at 11:22 PM on December 19, 2015 [10 favorites]

Since you don't have a deadline and are only expected to make progress, couldn't you respond to this (hypothetical) question by stating only the facts about the progress that has been made and what you expect to be working on going forward? From what you've stated ("most of it even works"), it seems like she indeed made some progress.

"Per my review upon receiving Thing, it looks like X, Y, and Z have been completed. I have begun work on A, B, and C, and I should be finished with that by [date]."

Leave it to the asker (who, I assume, is your boss?) to draw whatever conclusions need to be drawn from that statement.
posted by sevensnowflakes at 11:23 PM on December 19, 2015 [9 favorites]

Can you just proactively communicate, "after some review, we've identified that this would really benefit from an additional week of review/refinement. The next expected deadline is now X, with final deadline of Y."
posted by samthemander at 11:24 PM on December 19, 2015 [9 favorites]

Based on her other work, including the library, I know she can do better. I suspect she just didn't prioritize this one, because of the competing demands on her attention.

It's not worthwhile to go back and forth with her if Coworker is tempted to do the very minimum needed to turn each request around.

What? This isn't a productive attitude, if you're going to be working together on the same kinds of projects. It might not be a question of priorities; she may have some gaps she's nervous about. It would benefit both of you to discuss what happened. If there are gaps, help her identify them, and point her in a direction so she (and you as a team) can do better (and so you can be less frustrated) in future. If the issue is people having too much to do, working that through jointly would be a benefit to you both, too.

2nd seven snowflakes and samthemander (you want to do the best job possible).
posted by cotton dress sock at 11:34 PM on December 19, 2015 [4 favorites]

If you were the one accountable to management, then it was your responsibility to ensure it was done on time and to spec. Consider it lesson learned and chalk this up to needing to manage the requirement better if you work with her again. Feel free to let her know personally that the work wasn't up to grade though.
posted by ryanbryan at 11:59 PM on December 19, 2015

While there are many ways you could approach this, the way to accomplish your stated goal is to avoid assigning any blame or ownership. You simply need to map out the tasks that still need to be accomplished and provide a timeline to whomever is in charge of making sure the project is progressing.
posted by DarlingBri at 12:30 AM on December 20, 2015

I could send this work back, but it's probably easier to fix it myself.

Don't do this, it doesn't help as much as it seems. This is her work, talk to her and find out what happened. Maybe the spec was incomplete? Hard to say, but I mean, it sounds like it's not even tested. Once you talk to her you can talk about how it will get resolved, but if you're the face of it you're going to have to come up with a story. These things happen, though, schedules slip, and it sounds like you have a handle on the end result.
posted by rhizome at 12:58 AM on December 20, 2015 [8 favorites]

You say you're both new, but then state that you've been there four years and Co-worker has been there two! That's not new in anyone's language. I would not be making excuses or redoing her shoddy work for her, by now both of you should know better than that, covering for her does not help her to become better at her job and creates an expectation that if she messes up or just doesn't feel like putting 100%, someone else will pick up her slack.

What I would do is sit down with her and go through the project, explaining what isn't working and why and give her a deadline to complete it. Then tell your superiors you're making progress and there's just a few things that need finessing.
posted by Jubey at 1:26 AM on December 20, 2015 [5 favorites]

I agree with rhizome. I am in an unrelated field, and over time a culture of fostering incompetence has developed. It's miserable. Talk to her, and follow some of the excellent advice above. Build a strong, competent team member. You'll be doing her and yourself a huge favor.
posted by LaBellaStella at 3:52 AM on December 20, 2015 [1 favorite]

Personally, I'd let her know that she didn't do her job and that I was going to take the time to fix it. If it happens a second time, I'm pretty explicit about the person's failure and pretty clear on the person needing to do the thing they were asked to do. If it comes up again, I would go up the chain of command because at that point it really stops being my problem.
posted by sciencegeek at 5:08 AM on December 20, 2015 [1 favorite]

Pair up and code review.
posted by parki at 5:26 AM on December 20, 2015 [16 favorites]

+1 all the people saying to work with Coworker on improving it rather than hitting the "fuck it, I'll do it myself" button. This is an excellent mentoring opportunity! Just approach her as a code reviewer, not as a critic, and explain your reasoning and help her to get the code up to par. Both you and she will get something out of the experience. She'll learn better practices (is this a good time to mention test-driven development?) and become a more solid coder as a result, so in the end you'll have more reliable coworkers; and you'll build cred as a reliable, honest, and helpful resource that will benefit you when it comes to "what sets you out from others" review/promotion time. Also mentoring looks great on a resume. I would way rather hire someone who has a track record for building up the team rather than a superhero.

As for handling the questioning, I'd just say something like, yep, it was handed over but during the CR I identified some places for improvement, so I'm working with Coworker to get the quality up, and we should be ready for the changeover on X new date. NBD.
posted by sldownard at 5:31 AM on December 20, 2015 [16 favorites]

+1 sldownard 's comment, its dead on. I had a whole long comment typed out but it was basically rehashing the same points, only mine had more words than necessary.
posted by cgg at 8:11 AM on December 20, 2015

The only issue with the suggestions to have her redo it OR to do it yourself is the timeline of when it needs to be done and the additional work you both have that is not this Thing.

I agree that "Code Review revealed some issues" is the right way to approach it, maybe something like "the bulk of the requirements have been met but it still needs some tweaking/refinement" Now, someone needs to decide who should do the work to fix those issues: the original coder, you, or some other person on the team. That decision should be made by the person who is in charge of coding assignments for the team, who knows what each person's priorities are compared to the priority of the projects across the team, and who knows which person has the bandwidth to make the changes. If you're Agile, then the team itself can decide this and it sounds like the original coder is no longer on your team.

You've already spoken to the coder, so she knows the issues. IF it makes sense in the priorities to have her do it, great. But if it doesn't make sense - if her new project is top priority- that is not the same as fostering incompetence. You state that her other work is up to standards and when she did this original work it was not her top priority - that is not the same as letting her get away with incompetence, that is poor project planning at a level above her.

And I also agree that 2 years and 4 years is NO WAY super-new, young, or lacking skills. I don't care how old you are. The fact that she is young AND the fact that she is a woman have no bearing on the fact that she normally does good work but she screwed up this one.
posted by CathyG at 8:50 AM on December 20, 2015 [4 favorites]

To help us change over, Coworker temporarily joined our group and wrote the change.

But not for the actual, you know, change-over itself? That was a mistake, letting her go back without being invested in or responsible for the result. From your description, it sounds more that this was a case of low interest/priority and not of skill. I hear you that often in that case it's easier to fix it yourself than to try to "mentor" someone when that's not what they need.

That said, as far as your management is concerned, that's barely relevant. She joined your team for this to help. That doesn't absolve your team lead and supervisor from any responsibility to drive the project to completion on time (or manage expectations otherwise as necessary.) Your team lead knew when she was going back to her real project, right? Why didn't it work by then?

You don't want to pin this on her, because it only makes you look worse. Everyone's rough draft isn't great. Your team had unrealistic expectations, poor communication, and inadequate checkpoint/milestones to recognize you weren't going come through when expected. Sorry to sound so harsh, but that's the way it is. I'd keep cc-ing her on team emails about problems found and fixes made, just as a FYI and documentation for what's taking so long. Also be prepared to answer the question, "how much would it help to take her off of her project and back on your team vs. fixing it without her? How long would you need her?" Management is going to have to decide what it would do to her other project vs. how much it would help you, taking into account your projects' relative priorities.
posted by ctmf at 10:52 AM on December 20, 2015 [1 favorite]

If you are going to do the fixes yourself, you might open defects immediately in your tracking system to demonstrate that you find the issues quickly and the time you spent fixing them. Depending on your corporate culture you don't need to add her or management as cc:s but if your work is called into question, you'll have documentation.

Has anyone done code review on the library the coworker wrote? If they were sloppy with this code, I'd be worried about what other traps might be buried in the library.
posted by Candleman at 10:58 AM on December 20, 2015 [4 favorites]

And just to be clear - you don't just code it yourself without anyone else knowing about it. You open defects, you run it past the project manager/team lead/whoever, you get the fixes into the project plan with a person assigned to fix them and a due date for those fixes. Then, if it's you who is assigned to the fixes, then you fix them. But you are not trying to hide the fact that a deliverable was delivered at less than perfect. It's not a favor to her, and it's not a favor to the team if you try to hide this.
posted by CathyG at 12:24 PM on December 20, 2015 [1 favorite]

Mainframe programmer here, so not the same environment for sure. But on each line of code there is a place to put date/time stamp to be changed out any time you're in a program. And it's just good practice to put in documentation, telling what you've changed and why. (More documentation is way better than less.)

Was it me, in your situation I'd leave her code in there but comment it out, so it doesn't run, then your new repaired code underneath.

Your call whether to tell her or not, to request that she fix it or not. It does sound like you can easily fix it, probably in not much more time than it took to write this AskMe.

So maybe fix the code, put your name on it, but don't move it into production until you are double-dog sure it's working correctly -- you could end up looking like a big bozo. Do a review of it with her, making sure that it works as it needs to.

There are no secrets in programming shops, not really, not for long anyways. Everyone finds out fast who can do the deal and who cannot, who writes sloppy, undocumented code and who is to be trusted.
posted by dancestoblue at 9:46 PM on December 20, 2015

. Was it me, in your situation I'd leave her code in there but comment it out, so it doesn't run, then your new repaired code underneath.

There's few-to-zero scenarios where leaving bad code in the file commented out is the right answer, and this isn't one of them. Assuming you have source control, just delete bad code if you're replacing it. If some of the code looks useful, then use it in your fix.
posted by the agents of KAOS at 11:39 PM on December 20, 2015