How to handle a developer getting defensive when faced with breaking code?

Question

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?

Answer 1

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

Answer 2

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

Answer 3

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.

Answer 4

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.

Answer 5

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

Answer 6

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.

Answer 7

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

Answer 8

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.

Answer 9

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.

Answer 10

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.