Vrftsjtryk

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".

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.

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.

Tactics

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.

Stategy

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.

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'.

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.