I am an international female student, working as a part-time employee in a fairly big company in Canada with a group: 2 other international male students and one male employee, "Jack", who is older than the others and has more experience from other jobs he had. I was the first person who started working in this company as R&D xyz engineer.

I designed a code to do yxz and passed it to Jack to add his parts. He reviewed my code and he said he wanted to split it into parts to make it neater. Then he added his part. He ran the code and it worked.

After a couple of months, I had to make a branch out of that code and add more features to the code. I started working on it, and noticed it was a bit time-consuming to understand what he has done in the code (he introduced a bunch of functions to my part). I was able to review the code and add those new features to my parts of the code, but I did not know about his part. I tried to ask him questions about his coding, and eventually, I edited and I got a weird error in the code. Everything looked fine in the code but the error was still there.

We were in a weekly group meeting with the boss and those teammates for giving updates. In that meeting, I said "I completed the editing but I am getting some errors in the code and I am not sure why. Jack might be able to help me to know what the problem is since he was the one who reviewed my code and added his part to it." I also said "I can provide my original code to him as well which is working if it helps." Jack immediately said: "NO I DO NOT NEED YOUR ORIGINAL CODE!" with anger.

The meeting finished and I received a chat from him saying that "you are blaming me for my code, I have more experience in coding than you and I am not insecure about my job if it was someone who was insecure they would yell at you. Those errors are from your part, not mine, you are not in the position to blame me."

I immediately replied: "I am sorry if you feel that way I did not mean that, I just tried to say you made changes to my parts when adding your code, it is good if you review it to see if you can figure out what the error is since everything looks fine"

After I said sorry, he looked at the code, he spotted that error and it was only a typo that I was not able to see. As I said my gut feeling was the code was fine, I did not have a clue why it does not work.

I actually feel that I did not blame him, I just tried to say you made changes to my code and now it got difficult for me to understand so it is better you review it, you might be able to figure out why the error is there. I feel like he is trying to show me his authority.

Jack and I used to drink tea together during our breaks, mostly in the summer. He is interested in politics and he used to send me news from my home country, not really good news. News about women's rights that are degraded in my home country, or how COVID surges in my home country.

Considering those things I mentioned, did I insult my colleague "Jack"? Or do you think he is trying to degrade me? What should I do next? How should I behave from now on?

  • 2
    Comments are not for extended discussion; this conversation has been moved to chat.
    – DarkCygnus
    Commented Mar 11, 2021 at 15:37
  • So when you say that you "add those new features to my parts of the code" do you mean that you added the desired changes to your original version of the code, the version before Jack refactored it into functions?
    – DaveG
    Commented Mar 12, 2021 at 16:39
  • @Mayou36 I'm sorry I gave you the impression I was referring to you as being rude. That was not the case. I mean the OP's comment. SO is for coding issues. Some of us, Myself included, have deleted our accounts over there due to circumstances that we don't need to get into. Here, we give answers based on what we know. Speculation, "what-ifs", conjecture,. et cet tend to distract from what we are trying to do. The different stacks are here for different aspects of life. This one is specifically for navigating the workplace. It is in that context that we give our answers. Commented Mar 12, 2021 at 18:14
  • @Old_Lamplighter that's good to know, thanks, I was not aware of that. I've cleaned up my comments as they are not needed anymore. However, the whole tendency here to have a situation where two people act unprofessional - the OP by stating facts with a not great choice of words and Jack completely out of line (I think you agree?) - and one - the student - is largely to be blamed while the senior clearly has his issues that are unrelated from OP which played a strong part in his reaction, seems to me way to strong. It's a point for specific answers though.
    – Mayou36
    Commented Mar 13, 2021 at 9:52
  • Maybe you can shed some more light on the overall situation to give us a better picture: what was your intend with the question? Was that targeted to resolve the bug or to blame him? And did anyone else made any kind of remark about the situation? Did Jack had such outbursts in the past or do others may know about such?
    – Mayou36
    Commented Mar 13, 2021 at 9:54

14 Answers 14


You did several things wrong.

  1. You brought attention to the issue in a public forum. Bad idea
  2. You said that you had an error, and that Jack was the last one to touch your code. That is the same as saying. "It worked when I did it, and Jack was the last one who touched it." because the implication is that Jack was responsible for the mistake, again, in a public forum
  3. You did not approach Jack before the meeting, so he likely felt that he was being ambushed
  4. You replied to his message with "I'm sorry if you feel that way". That's called a "non-apology apology". You are not taking responsibility for misspeaking, you are putting the onus back on him by saying that the problem is not your actions, but how he interpreted them. You are sorry for HIS feelings, not YOUR actions.
  5. You did indeed blame him, and in a very public way, causing him to lose face in front of his colleagues and bosses.

If you want a normal relationship with him, you need to let the matter drop, or apologize. In the future, do not ever use the phrase "I'm sorry you feel that way". That phrase is typically used to either evade responsibility, or to be deliberately insulting.

  • 2
    Comments are not for extended discussion; this conversation has been moved to chat.
    – DarkCygnus
    Commented Mar 11, 2021 at 15:37
  • 1
    This is how interpreted OP's question first, but though we have diagnosed what has happened, we should not just encourage OP to stop blaming him publicly, but to stop blaming at all. Am i going too far to say the responsibility for an application where 2 developers have had input should be shared between them. Apologizing or letting it drop is not addressing the matter: OP believes the bug is caused by their colleague. I would say it's not. Thoughts? Commented Apr 2, 2021 at 13:25

You need to be careful when you say things and name names. Even if perfectly clear to you that you did not mean it was Jacks fault, it might not have been clear to others and it might not have been clear to your manager, who is probably not into the details of your project enough to understand it.

Your manager only heard "I have problems... Jacks code... does not work". Is that a shortening of what you said up to a level of downright change of meaning? Yes. Is it what happens when manager listen to developers? Sadly, yes.

So next time, just say something neutral:

I still have problems with the changes I made. Maybe Jack can help me, he's already familiar with the code base.

Done. No fingers pointed, no blame placed, even to people that only understand every second word you say. You have a problem, you need help. Jack can do it. Case closed.

  • 9
    This, yes. When asking for help keep to the point and don't attribute ownership; not for the code and not for the mistakes. Attribute abilities instead: familiarity, expertise, understanding, seniority, etc. Go for "I'm having a problem. You are [good with the technology | most familiar with the code | versatile in debugging]. Can I borrow some of that gray matter, please?" Asking "I'm having a problem understanding the code that you've written. Can you explain it?" will only get you "You'll just have to try harder, won't you?" or worse.
    – Luc
    Commented Mar 10, 2021 at 18:59
  • 7
    @Bwmat Perfectly? No. Everybody makes mistakes. But in a professional environment they should try their best.
    – nvoigt
    Commented Mar 11, 2021 at 6:22
  • 6
    Well, I accept reality and try to adapt. I cannot change managers and their attention spans and focus, but I can change the way I communicate. So I can either be a part of the solution, or I can send thoughts and prayers for the victims. I prefer the active solution approach.
    – nvoigt
    Commented Mar 11, 2021 at 6:43
  • 3
    This is spot on. Essentially, OP blamed Jack for her own mistake, in a public setting. Even if she did so inadvertendly.
    – raxxast
    Commented Mar 11, 2021 at 17:35
  • 2
    @Mayou36 I don't find it up to my professional standards either, but I would not bring this to a kindergarden level of people playing "but the other one did something bad, too". The OP communicated in a manner not suited well for the workplace, she can change that, problem solved. She probably cannot change Jack, nor might it be her place in the organization to try.
    – nvoigt
    Commented Mar 12, 2021 at 14:59

When you say to/about someone

It used to work before you changed it, I still have the old code if that might help you

You are saying to/about Jack, "you broke it." And this is not true. It was you who broke it with a typo. What's more, you're patronizing him -- he knows about source control, if he wanted the old code he could get it from there.

You and Jack clearly have different ideas of what makes code readable. You thought it was readable and understandable when you first wrote it and committed it. But he didn't. He wanted to split it into parts, to make it neater. This splitting didn't help you understand the code at all. To you, it made it worse. He probably knows that you feel this way because you asked for help saying things like "it was a bit time-consuming to understand what he has done in the code" and he was probably a little bit irritated to start with.

From his point of view, you committed code that was hard to understand and he improved it. Then you complained you couldn't understand his code and asked him to find your mistake, and then when the meeting rolled around and the code still had a problem, you said "well it was fine before Jack changed it" and suggested that your original code would be a valuable resource in making it work again. That is why Jack got so angry. Many developers would be angry if you said that to them privately, but even more so in a group setting.

Things really got worse when you non-apologized. And then it turned out to be a typo, which you think proves that it wasn't your fault.

Here's the thing: you and Jack can't both be right here. Either the code was easier to understand before it was split up, or it's easier to understand now. And in a way, it doesn't matter who is right: Jack is more experienced and felt it was part of his job to make your code neater by breaking it into functions. (That is often correct, but it can be overdone, and I am not taking a position on whether your code was more readable before or after Jack got hold of it.) You have trouble reading the code that Jack thinks of as more readable. You need to fix that. That is going to recur and the two of you are going to keep butting heads, especially if you keep saying that he broke your working code and made it hard to read.

Wait a week or two for things to calm down. Ideally, wait until the next piece of code that Jack "neatens up". Look over the changes that he made. Work out why you have trouble reading it. Some people have trouble holding a "call stack" in their head when reading code. Others don't know the features in their tools that make navigating through a lot of files simpler. When you know your problem, approach Jack and ask him for some of his time. Something like this:

I see that you have put this code into functions and I know that you feel that makes it more readable. I think I need a little help to learn how to read code like this quickly and it's not the style I usually use. Can you spend 20 minutes with me to go through it and show me how to read or approach it, and explain why it is a better practice? I would like to start writing code you don't need to tidy up, but I'll need a little instruction to get there.

This request has a lot of good things going for it. It doesn't argue whether he is right or not. It respects his skills and asks for help. It shows you to be a person who wants to improve and who will ask for help when it is needed. It implies that if he invests a little time going over this with you now, it will save him time later when he doesn't need to tidy things up for you. And, by showing a weakness (I can't read this kind of of code) instead of arguing (you made my readable code horrible), it undoes whatever hostility may remain between you on this matter.

If you can't make this request because you are sure that Jack is wrong and you are not interested in learning how to read what he considers neater or tidier code, then you need to do something more drastic. But that is probably another question.

  • 10
    "you and Jack can't both be right here. Either the code was easier to understand before it was split up, or it's easier to understand now." ... that may (not necessarily) be a subjective call, based on how compatible the programming styles/idioms of the two people, their background etc. The OP and Jack will have to make room for such differences while their mental models converge/expand/adapt as they work together, and it takes two people to do that. // "wait a week or two, mend fences etc" Definitely! It isn't critical who was "right" on the technical point.
    – Pete W
    Commented Mar 10, 2021 at 17:31
  • agreed @PeteW they need to work together on this Commented Mar 10, 2021 at 18:07
  • "When you say to/about someone It used to work before you changed it..." - yeah, if one says this it is blaming. But I don't see this clearly being said in the question. "a typo, which you think proves that it wasn't your fault." Does @programmer think that? Your answer is correct under the assumptions you make, but are those really true?
    – puck
    Commented Mar 10, 2021 at 18:12
  • 2
    Yes, "I can't find it, maybe Jack can, my code was working before he made changes" is clearly what I am getting some errors in the code and I am not sure why. Jack might be able to help me to know what the problem is since he was the one who reviewed my code and added his part to it. I can provide my original code to him as well which is working if it helps. says. And he looked at the code, he spotted that error and it was only a typo that I was not able to see. As I said my gut feeling was the code was fine does mean "It was a typo and I was right, my code was fine, it was not my fault. Commented Mar 10, 2021 at 18:35

You obviously did offend him, but then you apologised and explained and he accepted both and assisted you. There is no need for this to go further.

Just carry on as if it's just a small misunderstanding. Remain polite and friendly and he'll get over it if he hasn't already.

  • 1
    And also he may be thinking to himself that he should act a bit more... maturely in the future. We all ain't perfect. Commented Mar 10, 2021 at 14:27
  • 1
    @Mayou36 Kilisi said "offend", not "insult", and for a good reason. To cause someone to lose face can be a great offence in many cultures. Commented Mar 11, 2021 at 18:38
  • 3
    @Mayou36 obviously he was offended or he wouldn't have overreacted, at no point do I imply she insulted him or even did anything wrong. There was a misunderstanding, he overreacted, then the OP did the right thing and smoothed it over and has learnt a valuable lesson. No need for it to be more than that.
    – Kilisi
    Commented Mar 11, 2021 at 19:13
  • 1
    @Kilisi I don't think you could have put it any more plainly Commented Mar 11, 2021 at 19:58
  • 1
    @Mayou36 it is normal to apologise for a misunderstanding regardless of the cause. Likewise it's normal to apologise for offending someone.
    – Kilisi
    Commented Mar 12, 2021 at 19:37

There are lots of good answers to this already, but I have 2 more points to add on how to avoid similar problems in the future.

  1. It's not your code and his code. It's the teams code. When you talk about your and others code you show that code you developed is good and code someone else developed is bad. If you have to mention a person talk about who developed it instead of who owns it. But try to avoid talking about it at all if possible.

  2. Always phrase it as if it's you that don't understand or made a mistake. Never blame someone else. If you say "I can't figure out why X doesn't work, can you please help me" people want to help out. And if it turns out the other person did something they won't have a problem to admit it. If you instead say "You did something wrong and need to fix it" people don't want to help. And when they are forced to they will do the absolute minimum, probably only enough to show that they didn't mess anything up.

  • As an additional idea to avoid similar problems, you could try conveying the same information in a way that makes other people look good. Not "Jack touched my code and now I don't understand it anymore" but "I have a few spots in the code where I don't understand it and since Jack worked on the same codebase he probably has the best understanding to help me get it"
    – lucidbrot
    Commented Mar 11, 2021 at 10:18

On one side Jack is over-reacting, on the other hand maybe you could have phrased your issues in the meeting a bit different and in a more constructive way, maybe seeking for Jacks advice or review of the current issue.

Considering the fact that he rewrote parts of your functionality which you aren't able to fully understand/read, maybe he got insulted by being alleged by someone he considers a bit inferior in terms of seniority. But generally speaking people react very different when problems (related or not related to them) occur..

'What should I do next?'

Sincerely apologize and straighten things out in a privat talk. (Which you have done already I guess)

'How should I behave from now on?'

In future you could suggest to Jack and your superior to review changes on the codbase together, nevermind who wrote what part. Since you are a team and work on the same project, it wouldn't hurt in regards to efficiency, maintainability, code-standards and atmosphere within the team.


You both acted very unprofessional in this matter, I can understand why Jack acted the way he did (still very unprofessional), but not sure why you did.

Let's first answer your question:

Considering those things I mentioned, did I insult my colleague "Jack"?

Yes. But not with what you said, but rather with how and where you said it.

You basically blamed Jack for doing a mistake in the code in front of his co-workers and boss:

"I completed the editing but I am getting some errors in the code and I am not sure why. Jack might be able to help me to know what the problem is since he was the one who reviewed my code and added his part to it."

Is basically like saying: "I did my part and it worked, since Jack added his part, the code broke."

That's how it sounded to everyone in this meeting.

Why Jack reacted the way he did?

It looks like Jack didn't see it coming, and he is 100% sure that he didn't do the mistake, and on top of that, you underestimated his skill, again, in front of his co-workers and boss by saying:

"I can provide my original code to him as well which is working if it helps"

Its like saying: "Hey, I wrote a better code, look at what I did and try to fix yours."

He had few seconds to come up with a response after he was blinded by you (from what I can tell), and he came with his unprofessional response.

Who is in fault here?

You are, he does have a part in it, but you are the reason it escalated.

Let's summarize the issue:

  1. You wrote code that worked.
  2. Jack didn't like how it looks and suggested edits to make it neater.
  3. He added his code, ran it, and everything was working.
  4. After few months you tried to add a new feature, and there was an error in code.
  5. Jack reviewed it, and there was a typo.

You failed to mention that this typo was your fault? (I assume its your fault, or else you would have stated it was his fault, considering how detailed the question is).

Then he added his part. He ran the code and it worked.

After a couple of months, I had to make a branch out of that code and add more features to the code.

I tried to ask him questions about his coding, and eventually, I edited and I got a weird error in the code.

From all of the above, it seems like you have blamed Jack for something he didn't do, in front of his co-workers and boss.

What went wrong here?

This is a clear sign of miscommunication and a bigger issue in working in a team.

From what I see, the reason it got to be this major issue in the first place is because you didn't understand Jack's code, because if you did, you might have spotted the typo, and all of this could have been avoided.

Not only this, but you failed to communicate with Jack and let him know that you didn't understand the code or the reason this code was needed in the first place.

It takes 2 to communicate so you both failed in this, but because it was your code, you should have pushed more to understand it and made it clear to him that you didn't understand it.

How to move forward from here?

I would apologize to Jack by saying something like:

"I apologize for speaking like that in the meeting, I should have come to you directly, let's try to communicate more so we won't encounter any more issues like this in the future."

I'm sure he will apologize for the way he spoke as well, it seems like it is not something he does often.

The main issue in your case is miscommunication and team work, you both should move on and start working on it.

Tips for the future?

  1. DO NOT blame other programmers for mistakes in front of the boss if he doesn't asks for it, if the boss didn't ask "who did this mistake?" he doesn't care, he only want to know in what state you are now, results, if he wants to know who to blame, don't worry, he will ask you.

  2. DO NOT blame other programmers if you don't have a proof (!!!), if you still didn't find the error, do not even try to suggest others made a mistake, if it is your code, the chances are you did the mistake, always speak in general: "There is an error in the code, I need help from Jack to figure this out", "there's an error I can't find, will fix it soon", "still working on this".

  3. When you in a meeting, its not yours/his/my/hers code, its the code, instead of "Jack will be able to help me since he reviewed it and added his part", you can say something like: "Jack will be able to help me since we both worked on this", 0 blame, 0 pointing fingers, just focusing on fixing the error.

  4. If you didn't understand his code, tell him that, it is his responsibility to explain the code to as much as its yours to tell him you didn't understand it.

  5. If something in your work relationship is bothering you (personally or professionally), and you tried to fix it but it didn't help, schedule a private meeting with your boss, and let him know.

  • I've worked with a few "Jack"s. They are in the USA, so odds are they're not the same ones. The comment about "underestimating his skill" rubbed me wrong. Often these people mistake skill for complexity, and will take a simple idea and make it complex enough that only they can maintain it. If this story was about making complex code simple, I wouldn't be making this comment. Odds are Jack made this code less maintainable, and uses his "skill" as a crutch to write unmaintainable code, which nobody can understand, using that as more proof of his skill. Insanity, but common in some shops.
    – Edwin Buck
    Commented Mar 11, 2021 at 14:14
  • 1
    Yes! I didn't have enough content for an answer, but it was along the same lines as this one. OP's misstep was in "calling out" (as Jack saw it) Jack's "error" in a group meeting in front of the boss and teammates, rather than approaching Jack privately about it. Jack overreacted but I've got to admit I would feel quite defensive in that situation (if I were Jack) as would many of the people I've worked with. Of course it depends on personality whether they would express it or just stew on it... Commented Mar 11, 2021 at 19:53
  • @EdwinBuck you might be right, but doesn't seems to be the case here: he wanted to split it into parts to make it neater. this is something that is happening very often, I also didn't get the feeling it happened in the past, even if it did, the way she handled it was the wrong way, in cases like this you should hold proofs, and only after you are sure this is the case, you should approach your boss and let him know, this is a real danger to any company, and should be addressed ASAP.
    – Art3mix
    Commented Mar 11, 2021 at 20:38
  • 1
    @seventyeightist same here, If someone comes to my office and tell me I have a mistake in my code, I will jump right on it and will try to figure out why I did this mistake, but in this case, the code was running without any issues for several months, and suddenly had an error when the OP started working on it? and blaming me in front of my co-workers and boss without even knowing where the error is? I would get defensive as well.
    – Art3mix
    Commented Mar 11, 2021 at 20:44
  • @Art3mix depending on how they "split it in parts to make it neater" they might have made it more readable and maintainable, or they might have split the core logic across a number of methods that in combination prevent the core logic from being followed. We don't know. Maybe the OP knows, but from the posting, I doubt the OP will say it's easier to understand.
    – Edwin Buck
    Commented Mar 11, 2021 at 20:56

Jack may have overreacted but I think your phrasing could be misunderstood by some people.

I completed the editing but I am getting some errors in the code which I am not sure why. Jack might be able to help me to know what the problem is since he was the one who reviewed my code and added his part to it. "

This is kind of, sort of putting blame on Jack. You're basically saying, "Jack approved my code, then he added his code, so something is wrong with his addition." You also put it on him to figure out because you're saying you want Jack AND you to figure it out together, instead of just yourself.

So in some way, I believe Jack may have a point that you made it appear that he is incompetent or at least unable to get code working. However, his reaction to it was a little blown up and exaggerated. As a professional, he should have simply said you made additions after the fact that may not be compatible but at the time, everything was working.

At this point your best way forward is to give a soft apology. Since he escalated it, I wouldn't directly apologize since it would look like you meant what he said. Instead I would say, "I never meant to offend you." Which is a true statement. At that point, it's on him to accept it or continue to escalate it. From that point, move forward and do not bring it up again. In the future, don't say someone's code broke yours. Instead just say your code is not working and you wish to get together with so-so to figure it out.

As a aside, it also depends on your setting. If you are in front of the manager or stake holders, it is best not to finger point who wrote or did what. Instead, it is best to simply bring up factual statements about what is going on. "We released revision XXXX which added feature XYZ. I made an addition ABC and running into issues with the code. I am planning to get with Jack since he is familiar with the code to see if I missed something."

If you are amongst yourselves, you can sort of joke around depending on how the team is structured. You can jokingly say, "You done broke my code, Jack!" And he might have a laugh or two depending on if you said it in a jokingly way. In my team, we joke all the time on who broke what or what broke. However, whenever we're in a meeting with someone outside or between managers or stakeholders, we never bring up who did what or what broke, or anything negative.

Best way forward is to always make a positive statement. "Jack's addition broke my code" vs "I need to figure out how to plug my code additions into Jack's changes."

  • If you have a colleague who is experienced and confident, and they break your code, then you tell them that they broke your code and they fix it. Or let's say if I break your code then I want you to tell me.
    – gnasher729
    Commented Mar 10, 2021 at 14:24
  • @gnasher729 Right in front of the manager? I don't think that is a good idea to open a conversation so-so has broken code because your stuff isn't working. "My car is out of gas because you drove your own car too fast!"
    – Dan
    Commented Mar 10, 2021 at 14:32
  • It depends entirely on your workplace culture. A good manager of a coding team knows that everything is constantly shifting. Something that isn’t working now could work five minutes from now. It depends on the egos of your teammates and the competency of your manager.
    – Preston
    Commented Mar 11, 2021 at 5:01

There seems to be a piece missing in this story. It is not normal for Jack to react angrily to you suggesting that you give him your original code to help him help you debug an issue. Aside from this incident, how has your relationship been with Jack? If you think you are nagging him a lot (or he has told you that you are nagging him a lot), then this might contribute to why he is angry with you.

If I had to guess, probably what actually happened here is, when Jack edited ("refactored") your code, you gave him a big argument about why he did it badly and why your way is better and why he shouldn't touch your stuff and so on (this is common among junior developers, you are not the first and you will certainly not be the last, so it's nothing to feel bad about if you did this, but it is important to recognize that you did, if you did). Then, when you told Jack you would give him your original, un-factored code, he probably took it as yet another argument about how your original code was better and blew up out of frustration of hearing about how much better you think your code is, which is a reasonable, if unprofessional, reaction.

Now, what you should do from here depends on whether or not what I said above is actually (close to) the reality. If it is not, then what Jack did is grossly unprofessional and unacceptable. You should go to your manager and say that you do not appreciate Jack treating you this way, and you feel intimidated to work with Jack in future because you don't want to be yelled at.

If the situation above does reasonably describe your situation (and again, it's totally normal as a junior developer to do this, Lord knows I did it more than once myself, and I've had it done to me on numerous occasions as well), this is a learning opportunity (it's a learning opportunity anyway, but if Jack just flew off the handle for no reason then that's more important to deal with immediately). You need to understand things like why a "one-function application" is bad and why "one-screen functions" are good. The best way to learn about this is to have it done to you. Here's an exercise for you: If you have code of your own that you wrote many years ago and you remember what the application does but forgot the exact implementation details, go back and read it, and try to figure out what you were doing at the time. You will almost certainly find that what you wrote is incomprehensible, and you will find that a large part of that is because you are trying to do too many things at once. If you take that old code and break it into many functions, much the same way as Jack did to you, you will find that it is much easier to manage. This is what Jack was trying to explain, that he can't process your code in the way it's presented because it is too complicated.

This is one of the largest "level-up" hurdles that you go through as a junior developer, when you learn code structure patterns, and it's super important, so take it seriously. As for what to do with Jack, once you have internalized the difficulty of dealing with messy code, you should apologize to him for giving him a hard time. He should remember when he was a junior developer and he (almost certainly) gave his senior developer a hard time, exactly the same way as you're giving him a hard time now, and it shouldn't be a big deal going forward.

Noteworthy is that, as other answers have said, "I'm sorry if you feel that way" is not a phrase you should use in English. I've heard it from many friends who speak ESL so I guess it translates from your native language, or you learned it in school, but in English it's actually the opposite of an apology; an apology is "I did something wrong, I'm sorry", whereas "I'm sorry if you feel that way" is "I did nothing wrong, but if it makes you feel better to hear an apology then I'll give you one even though you don't deserve it". So don't use that phrase anymore, just say "I'm sorry".

  • 4
    "I've heard it from many friends who speak ESL so I guess it translates from your native language", I suspect it might be the opposite: real apologies, like from friends and family, is something they only hear in their native language, the only "apologies" they ever come across in English is people on TV (or this site indeed) that issue those politician's non-apologies.
    – nvoigt
    Commented Mar 10, 2021 at 21:03
  • 3
    +1 because there is always back story and context to when people may seem to "fly off the handle". Yeah, "Had a bad day" is one but more often it's been slowly building up one way or another. It's a rite of passage for juniors, more or less.
    – David
    Commented Mar 10, 2021 at 23:48
  • I doubt that Jack merely broke the OP's massive function into nicely-named parts. If so the OP should have had no trouble understanding it, and Jack would have been able to explain it. First-year students learn that stuff (the major compliant is "why should I write a function for just 1 line", not "replacing this with setYear(y1) makes it hard to read"). Maybe Jack changed it to use their own API, or added concurrency checking...or, my guess, did the "bosses must always make a change to prove who's in charge" thing. Commented Mar 11, 2021 at 17:02
  • @OwenReynolds You're assuming a lot about the quality of OP's education. I personally have a Master's (and Undergrad) degree in CS from the top CS school in my country and I never learned that in school.
    – Ertai87
    Commented Mar 11, 2021 at 17:55

This seems mostly like a problem with your supervisor, Jack. If I have this right:

His casual conversation includes insulting your home country. That's not normal -- it's borderline racist. Then he redoes some of your work. That's fine, except his job is also to explain it. You're a part-time student employee so even more than usual, his job is to teach you how things are done. Then you have to make changes, but don't understand the parts he added. That's doubly his screw-up -- he knew you didn't understand the changes he made, so what did he expect? Then you bring it up at the smallest meeting -- just him and you three students. That's the perfect place. He snaps at you and doesn't apologize. Even if you were a bit rude (which it doesn't sound like) a normal person apologizes for yelling at you.

There are people who enjoy working with interns. And others, like this guy seems, who think being forced to work with kids as a demotion and beneath them. He was going to get mad, at you, at the unfairness of it all, whatever, sooner or later.

  • 2
    Why do you think/see that he "insults" OPs home country? (unless it was in the original comments, but not in the Q itself, though having scanned the 'comments moved to chat' I can't see it.) ... I could only see that Jack is interested in politics and used to send me news from my home country, not really good news. News about women's rights that are degraded in my home country, or how COVID surges in my home country. ... I took that to mean that he was opening up a discussion about goings-on in OPs homeland, rather than being insulting? Jack and OP were "work friends" at that point. Commented Mar 11, 2021 at 19:59
  • @seventyeightist Right, that. My reading is that Jack made a point of bringing up negative things about OP's home country under the guise of politics. Like if I was interested in Canadian politics and innocently wanted to discuss:the PM's blackface scandal, the drug-addled mayor of Montreal, and all those missing-presumed-dead women in the north country. Regular stuff like that. Commented Mar 11, 2021 at 23:56
  • 1
    Talking about another countries politics, even negatively, is not racist, borderline or otherwise. Stop bringing the wrong -isms into it please. Calling everything racist or sexist or any other -ism when it's not only gives more power to racists, sexists and others that can rightfully say "see, they are labelling everything with that label now, I'm not at fault".
    – nvoigt
    Commented Mar 13, 2021 at 8:14
  • I'm upvoting this answer. And not because I think it's correct. I don't think it is. But it could be correct that if she felt annoyed by him constantly bringing up negative news items about her home country, and it's possible that she was also really annoyed that he didn't have the time to talk to her about the code when she asked for help. And that those unresolved annoyances may have come out in a passive-aggressive fashion during the meeting. In which case, this is bad if this is what happened. If she really did introduce this misunderstanding on purpose during the meeting, then it's bad. Commented Apr 30, 2021 at 19:05

You don't say how recently this happened, but if it happened very recently, you can casually (but publicly) work it into a conversation that the problem was something you did, which might ease some of Jack's concern.

  1. It will be clear to any management types that Jack didn't cause a problem.
  2. It should hopefully let Jack know that you're willing to acknowledge your own mistakes and that you won't throw him under the bus for things.
  3. It will generally let people know that you don't mind working with Jack and you think Jack's code is OK.

If you have to force this or make it into an obvious effort to talk about Jack then it doesn't work (it looks weird).

The way I would do it would be to use the same meeting where you originally brought up the issue, and when you talk about the status of that part of the project just say, "Jack helped me with xyz and it turned out to be a simple typo on my part so that's all working now." And then continue giving the rest of your updates as per usual.

  • I wondered how long ago it was as well, but what I inferred from OP with do you think he is trying to degrade me? What should I do next? means it is an ongoing or at least unresolved issue, so, likely recent. Probably between the weekly meeting where this conversation happened, and the next scheduled meeting. Commented Mar 11, 2021 at 20:15
  • 1
    Btw, I don't necessarily think it looks weird to deliberately bring it up. Personally if I were OP in this situation I'd be inclined to explicitly address it (in the next instance of the weekly meeting where that part of the code gets talked about) and say something like "[blah blah blah my update] also I just want to apologise to Jack for my comments last week, it turned out to be just a simple typo but I'd got too lost in the weeds, sorry it came off more harshly than I intended". ... but then I am typically quite direct in my approach in general and maybe OP isn't so that would be weird. Commented Mar 11, 2021 at 20:20

I think I know which country you are from. My advice will be according to that. He is elder than you ( also more experienced) and we need to pay respect to these people. Imagine he thinks the kid from yesterday is giving me mind about how to do things. Even in the meeting you said about the issue in a very kind way and good intention, supposed mistake of him was heard by everyone. Even though European culture seems that you can discuss everything openly without being judgemental, the culture is also more politically correct. So imagine you did this conversation with bad intentions to make him look bad in front of boss. You would still say the things exactly the same way. And they are human too. We all people can get offended, suspicious or hurt. Overall, Jack was a nice guy and gave room to the issue so he could think of other possibilities and he didn’t retaliate. If you want you can tell him that you didn’t have any malicious intention and you are young and don’t have enough experience, you couldn’t think all implications and apologise. Also, in the next meeting you can tell in front of everybody that “Jack helped me about my little mistake and it’s working now thanks to him”. Something like that. Also, even though I don’t know you guys and your relationship, I kindly recommend not to discuss any political stuff with colleagues.


You could have done better, but that pales in comparison to Jack's overreaction. There is a huge difference in what can be expected of a student versus a senior employee. Jack seems to be the most likely one to take a mentoring role in the team. His behavior is out of line for someone of his seniority.

Note also that while you seem to have learned from this experience, I wonder if the same goes for Jack.


This is not about blaming the person but the code (this is a word!) in order to find the bug. This is normal procedure. No one cares (in tech) who did it.

You are fine and have done things well!

Your behavior is completely normal in coding.

(Yes, not perfect, e.g. prefer to speak about 'the code', not 'mine' and 'yours')

For all non-coders

Bugs happen all the time. We can't write bugfree code. But that's why there are many mechanisms in place such as unittests, CI, code review etc.

But the difficult part is to find a bug. In order to track it down, one needs to find the lines in the thousands or millions of lines. That's hard! So you try to be as specific in order to find the bug which includes to find when it was introduced in order to blame the "commit" (the edition/version/timestamp) it was introduced with.

And that is what OP did. This conversations are everyday life. Taking a bug personally is a huge issue, no (normal) coder does that.

If you don't believe me...

... look at github repositories where the code is. People constantly report bugs and the authors are thankful for that (!). The more specific, the better. For example here where it is exactly pointed out who broke things. You find them in a dozen.

... and now for the actual answer

This answer is quite contradictory to the others, so let's have a look at the situation and step back:

There is a meeting where things are discussed and the facts should be on the table. You state the facts, and that's it. Yes, make sure to say it in a way that is less blaming, but other than that, fine.

However, Jack's response is completely out of line! You just stated the facts and Jack can't deal with it. You did not lie or similar. In a meeting, if you want to progress, you should state the facts and you should be able to handle the facts, even if they include sometimes that one may have made a mistake. The professional answer is along the lines of "Really? Sounds strange, I'll have a look at that later."

People often get offended not because of you, but because of their own problems. Can you spot the the (subtle hidden) issues of Jack? If all cases where as crystal clear as this, life would be easier :) and to mention: Jack probably feels awful about it now.

It is absolutely correct not to sincerely apologize for that but to give a response as you have done. Don't apologize for his issues. In fact, he is the one who should apologize to you for his unprofessional behavior.

...and we didn't mention yet that he is the senior person and should be able to deal with things better than you!

People have problems and they often confuse you to be them

Advice: Be proactive

  • You should talk to people before meetings about smaller things.
  • Why don't you talk to Jack now in a quiet minute? Don't mention the meeting, just be friendly. Remember, you're the calmer and he is most probably ashamed of what happened. Give him a feeling that you are on good terms and you aren't a threat.

He fought you because he cannot fight his real enemy: his own issues.

  • 1
    Comments are not for extended discussion; this conversation has been moved to chat.
    – Lilienthal
    Commented Mar 11, 2021 at 20:09
  • 2
    I did DV, because you are jumping to conclusions. The OP never said she used a functionality called "blame". The only person who mentioned "blame" was Jack and clearly in a way that does not refer to the functionality of annotating the code with the commit info, but the plain English usage of the word. Since the OP did not know where the bug was, there is no point in using said feature either. So, yes, a feature called "blame" exists, but that has nothing to do with the question asked.
    – nvoigt
    Commented Mar 12, 2021 at 17:31
  • 3
    Yes, in fact I do. I would never do that, for exactly the reason described here. The OP said something that was (mis)interpreted as blaming Jack. In fact, it wasn't Jacks fault at all, the error was not in Jacks code. I can understand Jack being upset, because everybody heard that there is a mistake in his code, but nobody was there when the two found that there wasn't. It's like a tabloid that posts a big smear story. Even when forced to print a counterstatement, it will appear days later on page three. The damage is done, many more people will have read the false claim on page one.
    – nvoigt
    Commented Mar 12, 2021 at 17:51
  • 2
    @nvoigt I don't think we know that Jack acted "unprofessionally". We have one side of the story from someone whose emotional involvement and natural desire to paint themselves in the best light may be skewing their representation of what happened. They were at a team meeting, the OP implied that Jack had messed up the code they were working on in front of the entire team, Jack got frustrated and pushed back, then privately contacted the OP after the meeting, told them why they were upset, and then helped them fix the problem in the code. What exactly was "unprofessional" on Jack's part?
    – ColleenV
    Commented Mar 12, 2021 at 20:08
  • 1
    @Mayou36 The last time Jack touched it was 4 months ago. It has been working since then. It was working when the OP checked it out. Then the OP made changes and it stopped working. ... So what do you think git blame says about this bug? Commented Mar 12, 2021 at 21:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .