5 ms·

Clearly he's got some issues given the reaction. However, was he informed of the bug? Was there an expectation he would fix his own mistakes? I don't work in I

Clearly he's got some issues given the reaction. However, was he informed of the bug? Was there an expectation he would fix his own mistakes? I don't work in IT/Software Engineering - I work in law. But when I find fault in other's work, it's a courtesy to let them know and give them an opportunity to address it. It's part of being a team player. I am not trying to be critical of you. It's just reading this reminded me of similar experiences where I was in a similar position to you. They were important experiences. People can feel bad when other people fix their mistakes when they aren't given the opportunity to be heard about it. It's so tempting to just say 'I will just do it myself' but you might find other people react poorly to this. Of course, maybe things are different in the IT world where it may be challenging to identify who committed a buggy change to the code repository, or perhaps just a radically different culture of work. But at the end of the day we are all human. It does appear you have developed an awareness of this, given what you noted in your reply to him (and props to you for that!). From there on, his behaviour was misguided and not appropriate.

quanto 5y ago
No offense taken. Your questions are valid. 1. Would he be informed of the/a bug(s)? Absolutely. We monitor bug tickets submitted to our team throughout the day. It's a main part of our job. 2. Was there a strict code ownership per individual contributor? No. This team's culture was such that once one contributor's code was committed to the main repository, it is part of the team's responsibility, not just the original contributor. In fact, any kind of don't-touch-my-code attitude was heavily frowned upon, worthy of a warning. I understand other teams may have different cultures. I was too young to know the office dynamics back then, but in hindsight from more life experiences since then, I now see that he was just a very insecure person. His former colleagues were advancing ahead of him, making 4x his salary, and the last thing he wanted was a young team member outperforming him. This observation itself is a life lesson for me.
- ozim 5y ago
  Thanks for following up. Because I wanted to ask why he would be so mean to you. That insecurity part answers that.
  - Aeolun 5y ago
    I understand the insecurity part, I don’t understand the behavior. Or maybe I do, I just consider the person an asshole first, and insecure second. I don’t enjoy being corrected by my team members either, but that’s more out of frustration that I did something wrong in the first place. The act of correction may be annoying at times, but you absolutely shouldn’t punish the initiative.
- Hajuijj 5y ago
  One point though: i personally don't like that as well as I see my bugs/issues as something I should fix. I always prefer a short message like 'hey I saw a bug here and I will fix it. At least this gives me a heads-up. But of course I wouldn't tell you that and I would definitely not hold a grudge against you because of it.
plorntus 5y ago
Not the original poster but I think things are just radically different by the sounds of it. Every company I have worked at, once the code is in the main revision everyone is responsible for it. At that stage the code has gone through many people from reviewers to testers, its not one single persons fault. Easiest thing to do ia not to blame but to just find a solution and see as a team if it was a genuine mistake that is unavoidable or if you can make some adjustment to the process to ensure quality and reliability of your code. People can specialise in a certain area of the codebase but no one 'owns' anything. Everyone needs to respect that any change to the code is a neccesary one. The 'expert' or original coder is usually a reviewer of the changes proposed anyway so thats when they can voice opinion on whether someone has misunderstood something or not. Bugs/Features can be worked on by anyone without ego getting in the way.
- cube00 5y ago
  This is exactly why we don't put @author comments in our code. Once the code is in the main line it's owned by the team. It also helps to promote quality within the team because if you see something unreasonable you are empowered to take action (that may not be possible immediately because we all have our day jobs but at least adding a TODO for it) The standard you scroll past is the standard you accept.
  - valmarket 5y ago
    This only works if the team has a very high standard and some self restraint. Otherwise notorious code churners who are addicted to a high commit count plow through the code base, regardless of whether they are area experts or not. If you contradict them, they cite the common ownership rule and paint you as a non-team-player. If they introduce bugs into the release and you point it out, you are the villain again. All in all, many of these shared ownership code bases are a breeding ground for politics that suffer from the tragedy of the commons.
    - mjthompson 5y ago
      Very interesting stuff to read from the perspective of an unenlightened outsider.
efficax 5y ago
Software is a machine. You don't ask the other mechanics if you can go and replace a faulty part on an engine they rebuilt last week. The engine is broken, you fix it and move on.
- Hajuijj 5y ago
  I would still expect communication. After all I don't want someone else to take away a potential learning experience. If someone else just fixes stuff for you all the time that just might not be good in the long run.
david38 5y ago
The bosses behavior is the worst I’ve ever seen. Sure, if there is time, it is best to file a ticket and notify the code writer so he can fix his own bug. That’s how he learns, but an urgent bug? The worst part is his reaction. He literally twisted the person’s words to the worst interpretation possible. What a piece of shit colleague.

quanto 5y ago

No offense taken. Your questions are valid. 1. Would he be informed of the/a bug(s)? Absolutely. We monitor bug tickets submitted to our team throughout the day. It's a main part of our job. 2. Was there a strict code ownership per individual contributor? No. This team's culture was such that once one contributor's code was committed to the main repository, it is part of the team's responsibility, not just the original contributor. In fact, any kind of don't-touch-my-code attitude was heavily frowned upon, worthy of a warning. I understand other teams may have different cultures. I was too young to know the office dynamics back then, but in hindsight from more life experiences since then, I now see that he was just a very insecure person. His former colleagues were advancing ahead of him, making 4x his salary, and the last thing he wanted was a young team member outperforming him. This observation itself is a life lesson for me.

ozim 5y ago
Thanks for following up. Because I wanted to ask why he would be so mean to you. That insecurity part answers that.
- Aeolun 5y ago
  I understand the insecurity part, I don’t understand the behavior. Or maybe I do, I just consider the person an asshole first, and insecure second. I don’t enjoy being corrected by my team members either, but that’s more out of frustration that I did something wrong in the first place. The act of correction may be annoying at times, but you absolutely shouldn’t punish the initiative.
Hajuijj 5y ago
One point though: i personally don't like that as well as I see my bugs/issues as something I should fix. I always prefer a short message like 'hey I saw a bug here and I will fix it. At least this gives me a heads-up. But of course I wouldn't tell you that and I would definitely not hold a grudge against you because of it.

plorntus 5y ago

Not the original poster but I think things are just radically different by the sounds of it. Every company I have worked at, once the code is in the main revision everyone is responsible for it. At that stage the code has gone through many people from reviewers to testers, its not one single persons fault. Easiest thing to do ia not to blame but to just find a solution and see as a team if it was a genuine mistake that is unavoidable or if you can make some adjustment to the process to ensure quality and reliability of your code. People can specialise in a certain area of the codebase but no one 'owns' anything. Everyone needs to respect that any change to the code is a neccesary one. The 'expert' or original coder is usually a reviewer of the changes proposed anyway so thats when they can voice opinion on whether someone has misunderstood something or not. Bugs/Features can be worked on by anyone without ego getting in the way.

cube00 5y ago
This is exactly why we don't put @author comments in our code. Once the code is in the main line it's owned by the team. It also helps to promote quality within the team because if you see something unreasonable you are empowered to take action (that may not be possible immediately because we all have our day jobs but at least adding a TODO for it) The standard you scroll past is the standard you accept.
- valmarket 5y ago
  This only works if the team has a very high standard and some self restraint. Otherwise notorious code churners who are addicted to a high commit count plow through the code base, regardless of whether they are area experts or not. If you contradict them, they cite the common ownership rule and paint you as a non-team-player. If they introduce bugs into the release and you point it out, you are the villain again. All in all, many of these shared ownership code bases are a breeding ground for politics that suffer from the tragedy of the commons.
  - mjthompson 5y ago
    Very interesting stuff to read from the perspective of an unenlightened outsider.

efficax 5y ago

Software is a machine. You don't ask the other mechanics if you can go and replace a faulty part on an engine they rebuilt last week. The engine is broken, you fix it and move on.

Hajuijj 5y ago
I would still expect communication. After all I don't want someone else to take away a potential learning experience. If someone else just fixes stuff for you all the time that just might not be good in the long run.

david38 5y ago

The bosses behavior is the worst I’ve ever seen. Sure, if there is time, it is best to file a ticket and notify the code writer so he can fix his own bug. That’s how he learns, but an urgent bug? The worst part is his reaction. He literally twisted the person’s words to the worst interpretation possible. What a piece of shit colleague.