Which Side of the Table Am I On Right Now?

Note: This post is not about a technical issue. It’s about a mindset I’ve found myself in a lot while learning how to code that I tend to get stuck in, and the way I’ve learned to get myself out of it.

While I still thought I wanted to pursue a career in HR, I completed the Mediation & Conflict Master’s program at Champlain College. Although I mostly focused on workplace disputes, the program’s fundamentals can be applied to divorce settlements, community/group conflict, family therapy, or, as I will explain below, programming.

One of the earliest critical lessons you learn as a third party mediator is the ability to discern positions from interests. It takes a bit of practice to be able to do it well in the heat of the moment, but it’s a very useful tool that speeds up the process and leads to a more satisfying conclusion for all parties involved.

One of my professors explained it like this:

Neighbor A (“Allison”) has lived happily in the neighborhood for ten years. She has a dog.
Neighbor B (“Bella”) moved into the neighborhood with her two kids a couple of months ago.

Almost immediately, Bella starts complaining, because Allison’s dog is always barking, making a mess, and running around the neighborhood without any kind of control. Allison says that she’s lived here for ten years and no one has ever minded, so Bella must be the one being unreasonable. She doesn’t change her behavior.

Over the next couple of months their fights continue to escalate until they’re screaming at each other in the street. Another neighbor calls the cops on them. Bella’s unsupervised kids start messing with the dog and the conflict reaches a boiling point when the dog bites one of them.

That night when Bella gets home and hears the story from her kids she freaks out and marches over to Allison’s house. She has made a giant sign that she plans to put up on her front lawn in protest:

So Allison retaliates with her own sign:

These are their positions. When they arrive in mediation, they are both completely rooted in those positions and will not budge. It’s the mediator’s job to parse their interests.

Ideally through one(or more) sessions, they would get to the point where their positions are gone, and only their common interests remain:

The situation seems really simple when it’s neatly laid out like that. Allison and Bella are both very reasonable people. But the conflict escalated so quickly that they became entrenched in their emotions and defense against each other that they couldn’t see what they obviously had in common. It was only the third party mediator that could see what they were missing.

This situation occurs in programming when it’s been a long day and I’m getting the same vague error message over and over again. In an ideal mindset, I want one party to be my code, and the other party to be the test, with me in the middle.

When you’re in the mediator’s chair, the positions of the parties aren’t affecting you, and you can clearly see how to get them what they both want, or at least notice the similarities in what they’re trying to do.

However, even though I know how I should be debugging, I often find myself attacking the error, doing everything I can to make it go away, just like Neighbor B wanted to kill the dog and Neighbor A wanted to kick Neighbor B out of the neighborhood.

In defending my position (that I AM RIGHT and my code is doing exactly what I intend for it to do) instead of trying to parse interests (what the code is actually meant to do), I end up on the wrong side of the table. There’s no one in the middle anymore keeping a cool head.

The bad news: The computer is never going to be able to compromise in a conflict like a human. It is never going to care how much I want something to work.

The good news: The computer, with its lack of emotional hangups, is much better at identifying and communicating its own interests than a human.

How I can tell I’m on the wrong side of the table:

1. Not reading the full text of the error message before trying something completely different.
2. Adding more and more arbitrary lines of code, hoping one will work but not really knowing why it would.
3. Getting frustrated, angry, self-defeating, and not thinking logically.
4. Feeling defensive about the code that’s already written and reluctant to delete anything.

What the right side of the table looks like:

1. Reading the full text of each error message and taking time to understand what it’s saying.
2. Commenting out the code piece by piece to isolate the issue, starting from the last point it worked.
3. Googling the error message.
4. Googling the topic in general.
5. Explaining the problem in detail to someone else.
6. Testing each change frequently and thoroughly.

Whether it’s in a heated conflict with a neighbor or just you alone at your computer, you do know when you’re on the right side of the table and when you’re on the wrong side, if you take the time to stop and think about it. I think it’s just a matter of remembering to check in with yourself about it.

Thank you for reading!