How to maintain relationships as a developer and a lesson in confirmation bias.

---

The Introduction

A normal day at the office, some Reddit here, a little Twitter there, trying the latest JS Framework; typical day. incoming teams call, "What now?" I mutter silently, 12 participants already in the meeting, and your microphone is muted, "Must be serious" I thought, and indeed it was. This is the story of how a simple miscommunication and poor developer relations turned into a 2-day finger-pointing deathmatch and how you can avoid going through a similar experience.

Developer Relations in the context of this article is the term I'm using to describe how developers relate to one another, whether on the same team, within the org or between organizations. It's the little unspoken rules that allow everyone to work together as a team and win at the end of the day.

The Situation

I was called into a meeting with another organization and they were stating that my team had changed some settings on our service causing their brand-new service to break. The lead developer from the other org, let's call him James, was adamant all the settings on their side should work and the only reason they weren't is that the changes were on our side. This caught me by surprise because my team had not made any changes or updates to the system in question. The other org however went and redesigned their architecture completely, using mock requests and responses and when it didn't work at integration time, they were sure it was because of us. We frantically tested the service internally and found it was working normally, we called a few other orgs using the service and they confirmed they were able to access the service too; my team was left with one conclusion and James wasn't going to like it.

Occam's razor - A scientific and philosophical rule that entities should not be multiplied unnecessarily which is interpreted as requiring that the simplest of competing theories be preferred to the more complex or that explanations of unknown phenomena be sought first in terms of known quantities - Merriam Webster, 2022

The Escalation

My team knew that the issue was on the other side but we couldn't outright blame the other org completely without evidence. We decided to be diplomatic, we blocked our afternoon and scheduled a screen share session with the other team to narrow down where the issue might be, hoping they would see the error and take corrective action. This backfired horribly in our faces; we attempted a demo on their end during the call, but due to some differences in software the other org was using, the response was fine in the logs but the window showed a cryptic message. James saw this and it reaffirmed his position, even though we tried to explain otherwise, he wasn't convinced. At the end of the day, emails were sent flying all over the place, escalations and conversations at the highest level in each org... Damn, how do we get out of this one?

The Resolution

The next day, my team was quite dejected as they'd gotten wind of pretty awful things said about them in some of the communications that happened the previous day. Some of the Devs even began to think indeed we had an issue on our end. I spoke to my supervisor and told him what transpired, he told me he'd be sure to attend the next meeting; he emphasized that I shouldn't put my emotions into it and be professional as always. I needed to hear that, I was just about ready to lose my cool and come to my team's defence. But he was right, even though we felt unjustly treated, we had to go into this meeting in the spirit of conflict resolution and the open-mindedness that entails. I spoke to my team and reassured them we were fine and that if indeed we were wrong, we'd apologize and do what needed to be done. We needed to go in believing that we might be wrong, even though we were probably right. We scheduled another meeting for 2 PM that day. The meeting starts and I make one request, that James and the team update their software so we are on identical platforms before we begin the troubleshooting; I'd read up on the issue we faced and concluded it must be a version problem. James completes the update and sets up the new version as he did the previous day, he clicks send...

It Works.

The Lessons

There are a couple of important lessons to take away from this incident. James and the other team believed they'd exhausted all options and concluded the fault was on someone else, that's fine, but the confrontation and manner of execution meant the entire process would be marred with finger-pointing and all parties would be on the defensive, which is counterproductive to any form of problem-solving. So James and the team, even if they believed they were right, should have come into the process thinking they were wrong, that would have set the stage for open discussions from both sides. The second lesson is a bit more subtle, it's about confirmation bias. James and the team only saw the signs that pointed to the fault not being on their end, despite having numerous changes on their system and my team telling them none were made on our side. This is a perfect example of what confirmation bias is, cherry-picking evidence to support only what you already believe. Confirmation bias is extremely dangerous even in our day-to-day lives; it prevents us from hearing and seeing views that are contrary to our own, even when they're right in front of us. It's like an echo chamber that each of us carries around and it's up to us to poke holes in it and let outside views in... Deliberately.

Confirmation Bias - The tendency to process information by looking for, or interpreting, information that is consistent with one’s existing beliefs. Britannica, 2022

The Outro

Hey, I hope you liked this article, I'm new to writing and decided, you know, I probably can! what the hell right?! As an evolving platform, your feedback would be most helpful; tell me what you'd like to read more of, I write about both soft and hard skills of being a developer in the modern age. And yes, spaces are better than tabs 😏