I started working at a company as a junior developer, after finishing a great programming bootcamp with a deep and broad programming knowledge. Since then (1.5 years) I learned a lot, gained credibility as a good software developer, and got several projects under my responsibility. A great part of my progress was made thanks to the help I got from my colleague senior developers during this time.

From time to time, seniors make mistakes, and sometimes, these mistakes break the modules that are under my responsibility. When this happens, I usually go talk to them and say something like:

"Hey, you made change X to Y function. This change breaks my code because it's not taking Z in account, and Z is what happens on my side. Is it ok with you to do K to fix it?"

One of them, when approached regarding a mistake, gets defensive and says things like "So am I not allowed to code?" or "Well, just change your code so it complies with mine" (instead of thinking about other, better alternatives).

How should I communicate to him that I come with good intentions, but also make him understand (and agree) that he's the one who should make the required changes to fix the broken code/module?

  • 1
    Comments are not for extended discussion; this conversation has been moved to chat.
    – Jane S
    Commented May 4, 2018 at 9:43

10 Answers 10


"Hey, you made this X change to that Y function. This change breaks my code because it's not taking Z in account, and Z is what happens on my side. Is it ok with you to do K to fix it?"

You need to make this less personal. There is no my code and your code. Both of you are employees of a company, and that company owns the code. You merely wrote it, but passed on intellectual property to your employer. Taking ownership is important, but don't talk about it like this.

Instead, think of all the code as our code, and phrase it like that. Or leave it out. When you are not focusing on what they did, but rather what the current state is, it will feel way less like a personal attack.

As a result of change X to Y this other functionality broke. I took a look at it and saw that we also need to think about Z.

You can then see what they say. They might respond with something like "show me" or "go ahead and fix it" or "oh, I didn't think about that" and offer to fix it themselves.

Ideally it doesn't really matter who fixes the problem, though. It's important that there is a dialogue, and everyone works together to make the overall product stable and functional. Having only one person responsible for a particular piece of the product is dangerous in itself, and this kind of situation is as good a chance as any to making sure everyone is aware of the other pieces of the product.

On a more technical note, it sounds like you really want unit tests or another form of automated testing for at least that particular piece of software. If there's a general infrastructure that runs them and displays the results, it will be evident if something (not someone (!), although there is of course git blame) broke the tests. They are there as a safety net and for everyone to notice if things go wrong.

An additional benefit of having unit tests for critical pieces of the system is that you don't really need to go and point out that things are broken. There is no code police person any more. If the tool chain takes care of that, no-one is delivering bad news and there are less bad vibes in the team as there is less room to argue.

On the other hand it comes with the need to update the tests as well. Discussing the pros and cons of that is out of scope here.

  • 26
    "It doesn't really matter who fixes it though." I don't really agree on this, if you have a schedule and don't have time to fix other's error you have the right to ask them to fix it. Commented May 2, 2018 at 15:02
  • 98
    This is extremely god advice! Just a couple weeks ago, I found a bug and, using version control, found the developer who introduced changes that didn't massage data correctly. I told them and my team about it, but I deliberately avoided saying that it was the developer's fault to anybody. As we looked for the source of the problem, it turned out it was actually my fault - I hadn't set up my development environment correctly! But because I hadn't pointed fingers, no one lost any face.
    – Kevin
    Commented May 2, 2018 at 15:21
  • 39
    +1 - Also, you don't want to create an environment where developers are too concerned about getting punished for breaking a shared module so they recreate another one on their own. Then everyone does lose.
    – user8365
    Commented May 2, 2018 at 15:56
  • 23
    I once solved a similar problem with a developer who said "I'm not changing my code." as his mantra. I did this: "Hey, I think the code you wrote is being passed invalid parameters, could you put some debug statements in there so we can catch the culprit?" KNOWING full well the right information was being passed. That brought light not heat. And as you might guess Mr. "I'm Not Changing My Code" owned up to the problem. Commented May 2, 2018 at 17:19
  • 9
    It is important not to blame the developer, because you really don't know if it is their fault. Very possibly the mistake they introduced was because of bad requirements given to them by someone else. It takes a lot of different people to bring software to life, and all are equally responsible for the end product. Blaming individuals is a waste of time. What matters is that the problems get fixed.
    – Seth R
    Commented May 2, 2018 at 17:40

First things first - it is not unusual for dependency code to break downstream code. There are development practices that can mitigate this, like good specification, documentation, and tests. But that is not the answer to your question.

Hey, you made this X change to that Y function. This change breaks my code because it's not taking Z in account, and Z is what happens on my side. Is it ok with you to do K to fix it?

What you say can come across as an accusation - you're essentially saying "you broke my code" - and this will put people on the defensive.

A better way is to keep this less "you broke my code" and more " would you mind taking another look at X? I think it needs to do K to work with Z".

Then again, if this person is a grump no matter how you approach them, you need to let your boss know that your work is being delayed by having to fix the grump's work. Again, don't point fingers, but leave it as "work on Z was delayed by changes in X and I needed to do K first".

  • And this is a major reason to use SemVer. Commented May 2, 2018 at 22:44
  • 1
    "A better way is to keep this less "you broke my code" and more " would you mind taking another look at X? I think it needs to do K to work with Z"." This implies that you actually just think it needs to do that, and the other guy might very well not think that it does. That's not what's happening here though, OP knows for sure that the change has broken existing functionality and that's something that for sure needs to be addressed.
    – Demonblack
    Commented May 3, 2018 at 12:36
  • 5
    @Demonblack OP might be wrong. OP might indeed be the one who needs to update the code to comply with the senior developer's code. The important advice is to talk about the problem with the code instead of pointing fingers, not about who is right or wrong. Commented May 3, 2018 at 13:29
  • It doesn't really matter who needs to change what though. Even if the change is sensible, you do not commit something that breaks existing code without talking to the affected people beforehand.
    – Demonblack
    Commented May 8, 2018 at 13:02

This is actually a great opportunity in disguise. Most engineers don't appreciate how huge this is for a current employer or prospective employer. On par with technical skills is your ability to collaborate with people, accept responsibility for mistakes, work with others through their own, and tactfully advocate your thoughts. The common consensus is that this is best demonstrated when interviewing by sharing an anecdotal story. usually people cobble together such stories in retrospect, but you could be very strategic and realize you have the opportunity to write a great story right here that would answer questions such as "how do you handle conflict" and probably open surprising opportunities at your current employer.

Something to consider then are your tactics vs strategy.


Your tactics are the systems and actions you choose to help with your problem. So, for instance, choosing better wording that's less personal, choosing the right time, being mindful of audience/by-standers, helping the person you're addressing save-face, or using automated tests to catch the error. Spend time learning and practicing good tactics. This will be your toolbox you can leverage towards your strategy.


The problem you're facing is symptomatic of an even bigger problem: this person doesn't really like you. That's what you strategically want to fix.

In the workplace, especially on a team, it is beyond your control that you have a personal relationship with every single one of your teammates. Maybe someone doesn't like you and you don't like them, too bad, you are forced into relationship by being on a team. It's your choice whether those relationships are good or bad. You can choose to put effort into other people or not. Real professional growth comes when you go beyond thinking of yourself as just a code cruncher (which leads to code arrogance problems), but as a functioning member of a team, and you want to show that, with you on a team, that team is greater than the sum of it's parts. That means great relational awareness.

The strategic decision is to ask yourself what do you want that relationship to look like? Is it possible? What is missing or what challenges might hinder the relationship? What do you need to do to make that happen? For instance, many relationship problems come down to trust. So a strategy would be to show this developer that you are thinking about his/her interests and not just your own, and to bring your relationship to the point where this person trusts you. Don't be a stoic know-it-all, that doesn't get people on your side even if you are right and justified. The strategy is to realize you want people on your side, and to think through how that happens. What works and what doesn't. It's also important to realize that a successful strategy often requires patience. You may need to work and challenge yourself more than you like to make real progress.

The cool thing about this is that, if you develop a really solid relationship with this senior developer, then the tactics that got you there become much less necessary and it's easier to be more efficient and more successful in your job. A good strategy can get you to a good relationship, and with a good relationship you'll find it much easier to achieve your objectives. So think about working on your relationship with this person when there isn't a problem, and that will make it easier when issues like this come up.


How should I communicate to him that I come with good means, but also makes him understand (and agree) that he's the one should make the required changes to fix the broken code/module?

You'd better make sure your boss/team agrees that this is how it should be handled. Ideally in a coding environment there is some sort of automated testing system, so if code being attempted to check in breaks it is rejected until it is fixed. Usually this is by the person who changed it. Everyone should take pride in their work which comes with a level of responsibility to want to fix things they break.

Your boss may feel it is a waste to have senior developers' time fixing every little bug they introduce into the system. They think that task is left for junior devs; I don't agree with this. You need to find out how this is supposed to work.

  • If code breaks across module boundaries, this is definitively senior developer material. Commented May 2, 2018 at 17:56
  • It's the senior developer who should decide how to fix it. But that doesn't mean they have to personally write the fix, or that the fix has to be in the code that they wrote. Commented May 3, 2018 at 13:34
  • @ThorbjørnRavnAndersen - that may make sense to assign it to a senior developer, but most projects become chaotic at times and best practices are not followed. Also, it could be viewed as a teachable moment for a junior programmer to figure it out and have the senior member provide more oversight.
    – user8365
    Commented May 3, 2018 at 15:19

My approach to this kind of problem is to ensure there is sufficient methodology and tooling in place to make the issue technical and not personal.

For example, make sure you have automated builds and smoke tests. If these get broken, have a rule that the breaker must provide food at the next team meeting.

Sometimes people will just boldly challenge the status quo in a selfish quest for personal progress. In a way, this is normal. It is entrepreneurial at best. The individual is moving forward in a framework that permits it. So, change the framework. Those types of people will not be thwarted, they will make progress in different ways. So as a manager your aim is to harness that spirit and direct it in a way that is positive for the team and the aims.

Part of that strategy of harnessing will is to make sure people still feel a sense of ownership. The most popular answer here thus far advocates a philosophy of renunciation of ownership. I think this may be counterproductive. Let people passionately own their area. But make sure they do not trespass others'.

  • I wrote the answer you're referring to, and I do agree with what you're saying as well. However, to a junior on the team in question, your advice is not particularly actionable. I don't believe they can change the way things are in their company. Can you give more concrete advice not to the manager role, but rather for the position the OP is in specifically? I'm not sure myself how they could influence that, hence I went the other route with my answer. I'd like to hear what you think.
    – simbabque
    Commented May 3, 2018 at 12:34
  • @simbabque Yes, my answer is more towards managerial roles. I think the OP could always escalate to his manager the same advice, but my feeling is that that still keeps the problem in the 'interpersonal' sphere, where a technical solution may be available. It is hard to know the details, but the way the OP phrases his problem suggests he is responsible for delegation of bugs and there is a slack culture where OP just goes up to colleagues and face-to-face dumps bugs onto people. Technically s/he can avoid this by adding more tests, or making the code enforce dependencies at build/compile time.
    – Sentinel
    Commented May 3, 2018 at 14:59
  • Thanks for your response. I now see where you're coming from. To be honest, I understood it more in a way that the OP is rather junior and inexperienced, and thus jumping to conclusions maybe too quickly. I therefore think suggesting a course of action to their manager might not be the preferred move, depending on their culture.
    – simbabque
    Commented May 3, 2018 at 15:02
  • 1
    @simbabque It's hard to know. In my opinion when a bug is logged, and it says "module A outputs values 1..6" and "dependent module B expects inputs 1..5" then someone needs to determine where the change should be made, if the culture encourages area ownership. If it does not, then the change can be made by anyone. In any case, it looks to me that this is a problem for technical leadership, and arbitration specific to that culture.
    – Sentinel
    Commented May 3, 2018 at 15:13
  • 1
    @simbabque If the aim is to make sure there is sufficient tooling and methodology in place, and if escalation via management is not an option, then the counterparties in the ownership dispute can solve their issue by working on the tooling/methodology proactively between themselves.
    – Sentinel
    Commented May 3, 2018 at 15:15

This question probably heavily depends on the culture of the company.

There are companies where "mistakes don't happen". Or rather, you're not allowed to talk about them, and a manager getting to know someone made a mistake, will "watch that person closely".

In that situation you disclose the problem to that person personally in a way the manager only hears about it if absolutely necessary, telling them exactly what you want them to do or fix, after you tried to fix it yourself. (Ofc. you should also run, red flags yada yada.) You also should tell them it's between you and them and that you're cool.

In any functioning company, you need to make sure that your disclosure doesn't sound like an accusation.

You still need to make sure that you tell them exactly what you want from them, and why you can't do it yourself (because if you can fix it, then why are you complaining, fix it quickly and move on, they didn't do it to create work for you, they had to fix their own problem).

Also make sure that their manager or project lead is aware and has given his ok for them to fix it.

They can't decide what to do with their own time and get work assigned by their manager/project lead.

Coming along and talking about a bug in a ticket that should be done by now, without doing those things prior to that and adressing them directly will create stress and the impression that you want them to do work in time where they are assigned to something else or in their spare time.


Most conflicts or issues with people are due to underlying issues of process. That is certainly the case here.

You, your colleagues, your company and worst still your ultimate customers are all victim of failing processes that should be in place to manage the quality and integrity of your combined code.

Thinking and acting from that perspective is key to resolving the underlying quality issues that directly led to the problems you are experiencing. It is also the key to finding common ground with your colleagues (e.g. You will find it easy to agree upon the process issues that are causing you all the pain).


Although you probably just want to get the job done and progress in your career, if you are perceived to be out to get one-up on more experienced co-workers, you will damage your working relationship with those who are best placed to help you.

My advice would be propose a fix, either in detail (as a Pull Request, for example) or an outline of the overall approach that you would propose as a solution. Take this to the person whose code you consider to be broken and ask for their opinion. And most importantly listen to the answer.

This presents the co-worker, who you may have just interrupted, with a solution, rather than a problem and therefore additional work. Not only will you likely learn something from the response you get, but you will be viewed as helpful and a team-player.

As others have suggested, you need to de-personalise this. There should be collective ownership of the code. Less of "you broke my changes!" and more like "how can we get both changes to work well together?"

You might also want to consider whether there is scope for improving communication during daily standups (if you have them - or suggest introducing them if not), so that generally there is more awareness of what people are working on and therefore less possibility of conflicting or breaking changes.

Providing the right level of detail at standups is tricky, but if you colleagues aren't aware of the broad area of the code in which you are working, you may want to consider giving a little more detail.

Something else to keep in mind - as a younger, but less experienced developer, it is quite possible that you can code faster than your more experienced colleagues (a younger, sharper brain is a real asset sometimes!), however you should also recognise that your more senior colleagues have the edge with experience and may be more considered in their approach, based on their years of experience. Indeed most development projects are more like marathons than 100 meter sprints. The best teams draw on all levels of experience.


How should I communicate to him that I come with good intentions, but also make him understand (and agree) that he's the one who should make the required changes to fix the broken code/module?

I agree with much of what has already been said. Different people interpret the same message in different ways, and what one person perceives as completely normal, effective communication, another person finds irritating or intimidating - for whatever reasons. That person is probably communicating (implicitly) that he finds your style unpleasant. Try something else next time. Try changing the setting - catch him at the water fountain rather than his seat. Sit next to him before you start the conversation, instead of standing over him. Try different approaches - use your common sense.

And one more thing I can suggest, try to balance your communication with him. If he's sensitive about you pointing out his mistakes, find opportunities to (sincerely) compliment him for smart designs or effective execution - that goes a long way with most people.


The easiest way to handle it is not to handle it. Let the developer argue with a failing test instead. Ask them how the code is supposed to work then build a test around it. Hand them the test and tell them it fails.

  • 5
    Passive-aggressive and they may well find a solution that both passes the test and breaks your code. What then - escalate the smart aleckry?
    – user53718
    Commented May 4, 2018 at 10:18

You must log in to answer this question.

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