3

Hi for a bit of background I a developer in the UK and we work in an agile environment.

A senior developer (let's call him X) and myself are working on a project, now I like the guy, he's a nice guy and I don't want to throw him under the bus but I have done roughly 70%-80% of the code.

So we have a breakdown of tasks to get on with, we both have other projects we need to work on but the head of development (Our boss) has told us both this is our main priority.

Most the tasks that X has undertaken have had to be re-written by myself or because of tight deadlines I've had to do his work. Now because of this some small bugs or tasks have fallen through the cracks either because I didn't know about them or X told me they were done when they weren't.

Now the issue here is that when anything goes wrong I'm being blamed by the head of development for all bugs or tasks not being finished even though they weren't mine to do in the first place.

I don't wan't to throw X under the bus but what can I do about this?

I've tried talking to X about the bugs or work not being done and he just brushes it off or says it's working on his machine, when I ask to see it working he makes excuses to not show me.

Note I've read the below question but this is different because he's my senior so I'm not sure the advice would differ. How do I deal with getting blamed for my coworker's sloppy code?

|improve this question
  • Him being your senior doesn't really change the situation, although it sound like you're in charge of the project, in which case you should expect to be blamed when things go wrong. – Dukeling Dec 1 '17 at 11:40
  • do you have something written saying which tasks were done by you and by your coworker? – Homerothompson Dec 1 '17 at 11:41
  • @Homerothompson We use Trello and assign ourselves to tasks, but you can also un-assign yourself – Tfish Dec 1 '17 at 11:42
  • @Tfish Trello keeps a history of changes, so it should be easy to look up. Also, your version control system should log exactly who wrote what anyway. – Erik Dec 1 '17 at 11:43
  • 1
    DEFEND YOURSELF! Tell the truth, and stand your ground. – AndreiROM Dec 1 '17 at 14:14
4

You should make a case for establishing clear processes. No code should be put into production without a code review. All tasks should be clearly assigned.

Have him review your code, and you review his. If there's more people involved, even better. This will make it clear who is doing what. Do not approve code in review that you find lacking.

As part of this policy, it should also be made clear who does testing, to what extent, and where to log that this has been done.

You do not have to place blame. In fact, this approach would be useful if you were the person responsible for errors or dropped tasks.

Follow this process rigidly and without exceptions, and do not get personal about it. Just point out there was a reason to introduce this process ( bad code making it into production, missed tasks ). Do not pick up tasks if you cannot finish your own!

Make it out to be a team effort ( "We have been making errors!", "We have been missing tasks" ) as reasons why the process is needed. This avoids placing blame, which you (wisely) would like to avoid.

This is a reasonable and effective approach, and addresses the problem in a generally accepted manner. Ask your manager to back you up on why the processes are needed, if the Senior is refusing to adhere to them.

|improve this answer
  • "Follow this process rigidly and without exceptions, and do not get personal about it" Exactly, that's all there is to it. – Fattie Dec 1 '17 at 12:35
3

Bugs are only classed as bugs when the users see and report them.

Until that point, they're unit/QA test failures.

The point here is that there's a failure in the test process here, either by you unit testing the changes, or the QA team not picking them up.

Strengthen your testing process.

|improve this answer
  • We've released it to a client for their internal process testing and a few of the bugs that showed up were linked to his modules and work he did. – Tfish Dec 1 '17 at 11:43
  • Ok. So assign those bug fixes back to him then. – user44108 Dec 1 '17 at 11:46
  • I will try this but if he doesn't do them then i'm back to square one. – Tfish Dec 1 '17 at 11:48
  • Snow is right, it's the way the process work, you assign the bugs to him, if he doesn't fix them use source control evidence to show why is his responsibility – Homerothompson Dec 1 '17 at 12:06
2

If you've already attempted to talk to X about these bugs and you're getting the brush off then I hate to say it but you might just have to throw him under the bus to a certain extent.

What you've described sounds like a pattern where X seems to offload his work on to you or let you pick up the slack for any bugs in his code. You've done the reasonable thing and attempted to resolve it between the two of you (which was absolutely the correct thing to do) and his response was to hang you out to dry and let you take all the flak so at this point you've got to look out for yourself and prevent further damage to your reputation.

|improve this answer
0

I don't wan't to throw X under the bus but what can I do about this?

Nothing. You should not need to do anything.

The system that tracks development work ( Trello ) should show how the developer in questions work went through the process multiple times.

  1. Dev
  2. Test
  3. Back To Dev
  4. Test
  5. etc.

If it doesn't, you need a new system to track your work. If the system does indeed track the work correctly, I don't see how you could be blamed for the buggy code of someone else.

|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.