For much of your career, you're going to be focused on the aspects of being a programmer that produce code, the ideas of adopting a language or framework or an ideology or enacting some kind of best practice as a developer. We can discuss in terms of the product that we create. And while this shouldn't be ignored, we can think further. We can think beyond just the things that we make and more specifically, we can think about the people that we make them with. In today's episode, we're discussing anti-patterns. Specifically, we're going to discuss three anti-patterns that you are probably either experiencing or participating in with your co-workers. My name is Jonathan Cutrell and you're listening to Developer Tea. My goal on this show is to help driven developers like you connect to your career purpose so you can do better work and have a positive influence on the people around you. And that's exactly what this episode is about, having a positive influence on the people around you, not a negative one. And so we often develop habits either because we've learned them throughout our earlier life experiences. We've observed them. Maybe we've emulated that people around us and maybe we have developed them because of some kind of sense of protection. There's all sorts of reasons that humans act the way that they do. In today's episode, we're going to talk about specific behaviors that you can avoid to improve the relationship that you have with your co-workers. And before we get started, we don't have a sponsor for today's episode. But in lieu of us not having a sponsor, I encourage you while you're listening to this episode before it's over. And by the way, it will be over pretty quickly because our episodes are pretty short on the show, encourage you to pull out your phone or whatever device you're listening to this podcast on and subscribe. This is the best way to make sure you don't miss out on future episodes like this one. Okay, let's jump straight into these three anti-patterns of co-worker relationships. Number one, labeling. This is something that we haven't really talked very much about on the show. We have talked about the pitfalls of stereotyping and why it's so important to avoid stereotyping as developers. But I want to talk to you about this other behavior. And it's called labeling. It's very simple. It is the idea that you can reduce a person to a single dimension and then give that dimension some kind of signifier, some label. Now, it's not always as simple as giving somebody a single word label like nerd, for example. This is obviously a bad idea. And hopefully we've come past this in our culture, our collective kind of conscience as a culture. But it goes beyond that. It goes beyond that to even labeling people, things that we think are good. We may label somebody the UI expert on the team. This is the way that we describe them. And it may feel like a way of providing a sense of deference, a positive label for someone else. Now, here's the problem. Of course, it is exacerbated when that label denotes something negative. But people are not when dimensional. Developers are not when dimensional. When your skill sets, in fact, perhaps even mostly your skill sets are not when dimensional. Furthermore, as we grow in our careers, most people have aspirations. And those aspirations tend to be relatively complex. Their interests tend to be relatively complex. And so when you apply a single dimension label to another person, you've essentially created a relationship that is limited. In other words, that person is not going to see you as their advocate. They're going to see you as someone who will use them in a very specific narrow role. Of course, this has to be balanced. If you have a title in your job or if you do have a specific role in your job, then it's reasonable to expect some level of specificity. But in normal conversation, especially when you're not formalizing these discussions, for example, if you're formalizing it in a pitch where you're showing everybody's titles, instead, if this is just over lunch, for example, and you reduce somebody's identity down to this single dimension. Even if it's a good thing in your mind, even if they're incredibly skilled, and even if they like that thing and they accept that label, this is still limiting the complexity and the multidimensional reality that is that person's experience as a human being. Now this isn't to say that you have to go and apply all of those labels to that person. You don't have to know everything about a person. You don't have to understand all of their skillsets. You don't have to understand all of their interests. But what you do need to do, and this is backed up by research, a healthy perspective on coworkers begins with the perspective that that person's personality is not fixed. Their interests are not fixed. Their skillsets are not fixed. Their person's experiences are changing all of the time. Their perspectives are changing all of the time. So this other person that you encounter on a regular basis is a complex human being, and developing a healthy respect for the complexity of all of your coworkers is a baseline for creating better relationships. So that is anti-pattern number one, and it's a big one, labeling. When you do the opposite of labeling, the kind of antidote for the anti-pattern of labeling is instead to ask questions, ask the person that you otherwise would be labeling to introduce themselves, to tell you what they're interested in. If you give up the floor, and instead of making this an opportunity for you to prove your insight into that person, instead give them the floor. Allow the other person to speak for themselves. It says powerful implications, and this doesn't necessarily mean that you have to put them on the spot that's not the point here. Instead, the idea here is to provide the respect of believing that someone else has a complex personality that can't be reduced to a single dimension. Okay, let's move on to anti-pattern number two, and that is something I'm calling iceberg criticisms. This is a very simple concept, and most of us have probably experienced this. If you are a developer especially, and you've gotten into conversations with people about various types of technology, then you've probably experienced this kind of weird phenomenon, where a developer will disagree and then not tell you the reasons they disagree. This iceberg criticism, I'm calling it iceberg criticism, because it's like you've seen only a very small part of why that person has an issue, let's say, with a particular practice, a pattern that someone's using, a way of going about the process of programming. They share only enough for you to know that they disagree, that they're kind of on the opposite side of the fence. In the name of, for example, avoiding an argument, often people won't detail why it is that they disagree. The problem with this is not that you have disagreements. Disagreements are healthy, they're important, and it's important to work through them. The problem is that if you begin down this road of having these iceberg criticisms, and people are going to see you as generally contrarian, and on top of that, you're not providing a better way. The first problem of being generally contrarian is that very few people are going to seek out your advice. In fact, they will likely start to avoid you. If you have only criticism and no alternative advice, of course, a better way here is to provide reasonable criticism when you have good reasons to back it up, when you have experiences, for example, but also to recognize that those criticisms that you're bringing to the table are your opinions. If you come to the table and you have entirely disagreed with other people, and you won't tell them why, versus coming to the table and saying, I have a different opinion than you. Here's what I've experienced. This is a much more open conversation. People are much more likely to engage with you, and you're much more likely to be able to affect positive change. The absolutely most important piece of advice I can give you when dealing with criticisms and sharing criticisms is that you must be open to hearing other people's opinions. Not only open to hearing their opinions, but also considering whether their way could be better than your way. Most of the time, the answer in these kinds of arguments is that neither one of you is necessarily right or wrong. There's just different approaches, different ways of getting things done. And more specifically, different ways of doing things, given different contexts. We've talked about this a lot on the show, and trying to create black and white arguments, this is something that iceberg criticisms does. It says that I see this issue as black. This issue that you're saying is mostly white, I see it as black, but I don't want to discuss it. I don't want to get into it. This comes across as arrogant. It comes across as if you're not really open to discussing your opinions, and you're certainly not open to changing your opinions. This is a very bad habit to get into as we've already discussed. So I encourage you to instead approach with openness and a willingness. If you're going to share your criticisms, your disagreements, a willingness to provide an alternative. Okay, let's move on to number three, the third anti-pattern when dealing with co-workers. In today's episode, we're going to talk about a third anti-pattern called the protagonist obsession, the protagonist obsession. The idea of this anti-pattern is that in every conversation, you make yourself the protagonist. If you're not familiar with the term, the protagonist is the person at the center of the story, the hero in the story. We've all experienced this person, and we all know what it feels like to have a conversation with this person. Anytime you make a comment or tell a story, this person doesn't chime in to comment on your experience. Instead, they turn around and they tell a story that is somehow related to yours, but about themselves. Very often, this person is also guilty of another kind of bonus anti-pattern for today's episode, and that is one-upping. Telling a story that is equally or even more unbelievable or interesting or impressive than your story. This anti-pattern is very easy to fall into because it seems like you're participating in conversation. It seems like you're being social. It feels like you're actually interacting with your co-workers. The problem is that you've turned the spotlight on yourself at every opportunity that you have. The antidote to this anti-pattern is to ask questions, surprisingly, if you have noticed all three of these anti-patterns have been about making everything about yourself, about your own beliefs, about your own stories. When instead, you turn your interest from yourself to someone else. This fulfills a fundamental need for human connection. It is that you're actually interested in the people around you. Instead of only being self-interested, you're interested in the well-being of your co-workers. You're interested in understanding them as people. Ultimately, these anti-patterns can be very difficult to avoid, and we all will fail from time to time. It's important to remind ourselves on a regular basis that the people around us have their own experiences. They have their own desires, their complex human beings. We can't reduce them to a single dimension. We have to recognize that other people's beliefs and experiences are valid like our own. We have to remember that our story is not the only story that matters. I encourage you to take a moment and think about your co-workers. Each time that you interact with your co-workers, try to learn something about them. Instead of approaching every day as if your co-workers are just extras in the movie that you're starring in, imagine what it would be like if you were the supporting character. Thank you so much for listening to today's episode. I encourage you once again to subscribe if you've enjoyed this episode. You will probably like more episodes and we do three of these a week. So it's easy to get behind. It's easy to forget to subscribe. Go into whatever podcasting app you're using right now and subscribe. Thank you so much for listening and until next time, enjoy your tea.