2

I value my free time and try not to work from home on weekends as one of my colleagues.

Recently I got into following situation:

Friday evening (after working hours) QA hit me up on Slack about a small bug in the feature that I've worked on. Before I had time to answer, my colleague replied that he 'will look into it' because it was the only thing that blocked us from shipping next release. Few minutes later I've promised to fix it, reminding everybody that we will not ship next release until Monday. He agreed that it would be better if I will look into it instead.

Saturday afternoon I've fixed the bug and was checking if everything worked as intended and soon after that I got message from the same colleague in the Slack leaving me completely speechless:

I've fixed it

I remember that this kind of thing already happened in the past: me (clueless about my colleague intentions) and this exact colleague are working on the same problem in parallel.

So, the question is:

Should I talk to my colleague and ask him not to do that? At least ask him to notify me about his intentions. Or should I swallow my pride and not to take this personal?

  • 1
    He did, but after that I've replied that I will look into it, and he agreed – nemezis Nov 30 '19 at 19:30
  • 2
    It is more about my wasted time - I wouldn't start working on a fix knowing that someone else is trying to fix it. – nemezis Nov 30 '19 at 19:37
  • 1
    No, I did not. We discussed with QA in the same chat that the issue can wait till Monday. It is not like we were planning to ship it first thing Monday morning. – nemezis Nov 30 '19 at 19:47
  • 10
    I think you're being a little cavalier with timelines, or maybe your company is. Code shouldn't be still in testing on the day of release. – jesse_b Nov 30 '19 at 19:48
  • 3
    @PeterM: disagree. It's great that it passes but if a bug is found friday before the release, the release should have been postponed because a half day probably isn't enough time to even do proper tests. – jesse_b Nov 30 '19 at 19:55
16

Unless his fix is flawed you should thank him and move on. Even if the bug is in code you wrote, it's not really your bug nor is it your code. It is the company's code and the company's mission is to deploy that code without bugs. Your colleague is doing the company a favor by fixing bugs.

It's great that you want to be responsible for all code you release including bugs, but it's also a bit of an ego issue if you have a problem with colleagues offering assistance. Again, it's not really important what you do (in the big picture); it's what the company as a whole does. If you are concerned more about the company's mission than your own, you would not have a problem with this.

The only potential issue I can see with this is if your colleague is falling behind on their own responsibilities by offering unsolicited assistance to others, in which case that is not your concern unless you are their manager.

Also, you mention that the bug was discovered on Friday and you were not able to look into it until Sunday. If your colleague was able to work on it Friday you should not have disagreed. Also you say that the code was scheduled to release Monday, and fixing it late on Sunday night doesn't seem good enough IMO. Your fix would need additional testing that should be started as soon as possible, not late the night before.

  • I didn't mention that I won't be able to fix it till Sunday evening. I just mentioned that I prefer not to work on weekends, but it doesn't mean that I will not make exception for a case like this. – nemezis Nov 30 '19 at 19:50
  • 10
    It seems like there wasn't as clear of communication as you think. It sounds like your colleague was under the impression that you would work on it Monday morning and agreed but also tried to fix the bug over the weekend first, and since they did fix the bug they let you know Sunday (before you agreed to work on the issue) hoping to prevent you from having to do any work at all, and ultimately trying to put the company in a better position to finish testing before release. – jesse_b Nov 30 '19 at 19:53
  • I don't have problem with a colleague offering me assistance of any sort, it is just that in this case the assistance was not needed. – nemezis Nov 30 '19 at 19:54
  • 3
    Yes, it seems like I wasn't clear about my intentions after all. Thank you for answering – nemezis Nov 30 '19 at 19:56
  • 1
    The question appears to me as if it's not a matter of who gets appreciation for fixing this bug, but a matter of who should do it. "He agreed that it would be better if I (nemezis) will look into it" - then he did it on himself and arranged unnecessary work for nemezis. This is annoying and should be avoided. A communication problem should be solved in a neutral way, an overly active colleague causing unnecessary parallel work should be told to stop doing that. Simply thank him is not a solution to this situation. – puck Dec 1 '19 at 14:43
12

Your team needs to get organised better. Two people trying to fix the same problem is a waste of time. And the way you tell this story, it seems you don’t do code reviews - that’s something you ought to change.

Apart from that: The bug is fixed, so what is the problem?

  • 2
    The problem is as you said: wasted time. Pull requests are optional, you can still push to development branch without review. We think that required pull requests will slow us down. – nemezis Nov 30 '19 at 19:59
  • 1
    trying to fix the same problem on off hours. Talk about it during your Monday standup or your next sprint review. – Bernhard Döbler Nov 30 '19 at 20:28
  • Not necessarily the case. I have been working on one thing and realised that a completely different bug could be rapidly fixed with the same approach. – Software Engineer Nov 30 '19 at 21:43
  • 4
    @nemezis Fixing bugs that would have been found in a code review slows you down a lot more. There have been times where I worked on my own (some professional, some private), and if there is nobody else to do a code review, I do it myself. Which saves me a lot of time. – gnasher729 Dec 1 '19 at 17:50
  • 2
    "We think that required pull requests will slow us down" - you are wrong. Get familiar with the concept of technical debt. You experience much higher slowdowns from problems that you introduce,than from QA. This is why there is QA. – Mär Dec 1 '19 at 23:27
3

I am going to tackle this from the organizational side.

The way this should be done, even for bugfixes, even for small ones, is via ticket/issue.

If this was the case, make sure a person is assigned to a ticket and it is clear whether or not the ticket is currently in progress. Make sure to put a policy in place, in case you want multiple people to work on an issue, which I personally advise against. If you have to assign multiple people, because the issue is large enough, subdivide into subissues.

In any case, this will at least prevent unnecessary work. It can easily happen, that two people waste time fixing the same problem in different ways, because of a lack of communication. Ensure this does not happen.

Other than that, I have been on both sides of this over my career and it is definitely considered rude, this is if there is a clear assignee. I understand one should not emotional about such things, but I have seen conflicts arise from this, so it simply does happen, therefore it is necessary to deal with this.

You could tell your coworker, friendly, that you felt this was rude. I am not sure if there is value in confrontation, however, depends very much on how such things are handled at your place. Be that as it may, I still advise to put procedures in place. If you were assigned that ticket, even though you were not in over the weekend, then your colleague has no business interfering without your consent, i.e. if the policy you put in place is such.

  • 1
    Thank you, agreed that we should definitely review current procedures – nemezis Dec 2 '19 at 12:17
-1

As I agree with @Mär I would to add few words,

Your colleague is being a bitch for a second time , that's might not be intentional to hurt your feelings and reputation in your work place, but that is a definite result for such action,

Here there is two evil actions happening,

taking over a ticket assigned to you "1st",

actually the reason for that ticket is code you introduce to the codebase "2nd",

The second point from a team perspective depend on your team, organization, team leader, to consider the second point an issue or not, with some product managers I know That's gonna leave a negative labels over your capabilities, With some others it's just the usual workflow, and you can't do much about it in either cases,

The first point, this is hugely unprofessional action from your colleague, I would talk to him, tell him my side of the story (don't mention the second point as it's something you both can't control and something he could use a a defense that's your team actually has an open culture), but highlight his action from your point of view, explain to him your feelings, and your assumption that a ticket assigned to you is your territory and there is only two ways to enter it, by order from the team, product manager, by you asking for help with agreement from manager/team leader.

Just a ps: If you decided to talk to your colleague about it don't mention intentions at all, and if he/she used it in the defense makes it clear it's couldn't be an exercise but focus on actions and the feelings as consequences.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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