Hey everyone and welcome to Developer Team. My name is Jonathan Cottrell and today I'm going to be talking to you about maintaining relationships with other developers. Now, most of you are probably working with someone. It may be another developer and really this episode isn't just about you maintaining relationship with other developers, but also with just people in general, especially in the professional sphere. So most people listening to this show are probably not independent developers working on their own applications and not interacting with other people. At the very least, you're working with users who actually use your application. It's very unlikely that you live in a bubble. So it's important that you understand how to deal with people. Soft skills are one of the most important parts of your career. If you don't develop soft skills, it is very unlikely that you will advance, that you will level up as is. Our mantra at SpecFM, we want to help you level up in your career or as a developer in your specific hard skills, but also in your soft skills. And so I found this really incredible document that it's the manual for Recurse Center. It used to be called Hacker School, I believe. Recurse.com slash manual. Of course, that will be in the show notes. And there are some social rules that they have in this document. I want to go through them and give you guys an idea of social rules that may be useful for you. The first one is no feigning surprise. And you guys all know what this feels like when you seem so surprised that someone doesn't actually know about something that you're telling them about. What you don't know about this particular band? We've all heard that one. What you don't know about Ruby on Rails? Where have you been? What rock are you hiding under? Of course, this leads to people feeling inferior. And there's no real reason to do that to another person unless you are trying to put yourself above them. And that will break down a relationship. In the document, no feigning surprise, or in the manual, rather, under the no feigning surprise headline, when people feign surprise, it says, it's usually to make them feel better about themselves and others feel worse. And even when that's not the intention, it's always the effect, almost always the effect, rather. So that one's pretty simple. Don't feign surprise. Control that urge to make yourself feel a little bit better or more superior to another person because you found it first. There's not really any value in it. And really, it just makes you look better and them feel a little bit humiliated. The second rule is no well actuallys. The reason I actually found this document, by the way, is because Avdi Grim tweeted about well actually, and somebody responded. I can't remember who it was at the moment, but somebody responded with this. And they said that this is a pretty good definition of well actually. A well actually, according to the document, happens when someone says something that's almost, but not entirely correct. And you say, well, actually, and then you give a minor correction. Now, this doesn't really serve any purpose either, right? Because the reality is they were almost correct. And unless there is a critical error in what that person is saying, then it's unlikely that you will be able to correct that person. And so, I'm going to go ahead and show you a little bit of the discussion. Instead, once again, you are making yourself look a little bit better than them. You're making yourself look a little bit more masterful than them by simply asserting that you know the details better than they do. And the reality is you might actually be wrong. It may be that you are saying well actually, and you may even be wrong. So, don't use well actually. It doesn't really serve you well. And even that small amount of value that you could be adding, it's not really necessary. Most people will find the details as they are working. They will discover that they are wrong. And you don't really have to be the one to point it out. Nobody likes for somebody to point out that they are wrong, especially about small kind of nagging things. So, I'm going to take a quick break before we go through the other two items in the social rules of the Recurse Center to talk about today's sponsor. Today's sponsor is DigitalOcean.com. Now, I have gotten very familiar now with DigitalOcean. They've been a sponsor of the show for a while. And I can't tell you how much I appreciate DigitalOcean and what they do. They provide a very affordable way of getting an SSD cloud server up and running today in less than one minute. That's 60 seconds. Less than that, you can have a cloud server up and running. Go and check it out. I highly recommend it because so many people, who are wanting to start developing their biggest kind of hurdle, is to have a place to put their stuff, to actually have a place to launch the things that they're working on. And DigitalOcean is a perfect place to do that, especially for their bottom tier droplet. It's $5 a month. And if you use the code developer T, you actually get a $10 credit, which is basically like having two months for free. So, if you're looking to learn web development, DigitalOcean is a great option for you. And if you're looking to learn web development, DigitalOcean is a great option for you. But even if you aren't a beginner, if you are well into your career, if you have a major project that you're trying to launch, the DigitalOcean network of servers is super fast and they talk to each other, which makes it even faster to get kind of collaborating servers up and running. They have a ton of documentation. It's super easy to get started. Go and check it out, digitalocean.com. So, I'm going to go ahead and talk about these other two rules and then give you a little bit of basic advice. So, let's get started. At the very beginning, you may have heard the phrase, you may have heard the phrase, build relationships with people. The first one, again, was no feigning surprise. The second one is no well-actualities, no minor corrections. The third one is no backseat driving. So if you overhear people working through a problem, you shouldn't jump in and lob advice at them. This can lead to this idea of too many cooks in the kitchen. Now, I am loosely following the document on recurse, by the way, as I talk through this. And this isn't to say that you shouldn't help or offer advice, especially when you are asked, right? On the contrary, of course, that is as valuable. That is very valuable. But it just means that when you want to help out or work with others, you should definitely fully engage. Okay, so I've read directly off of recurse. And now I'm going to give you my own opinion on this. I think backseat driving is one of the most frustrating things to deal with as a developer, because a lot of the time, the people who jump in, who butt in with advice, they don't have the full context of the problem. And that causes more frustration. It slows you down and interrupts the process of solving the problem, making you kind of go back to ground zero and try to solve it from the beginning. So if you're going to offer your help, one of the most helpful things you can do is start by listening. Start by not anything at all. Get a bit of context before you offer advice. And in fact, it may be even more helpful to help someone talk through the problem on their own and just sit and listen. A lot of the time, people can talk through the problem on their own. I'm going to do another episode in a couple of days, probably, about rubber duck debugging. A co-worker actually turned me on to this idea, rubber duck debugging. But very simply, do not be at backseat driving. Don't offer your advice unless you have the correct context. And I would even say, don't offer your advice until you're asked for it. And finally, no subtle isms. This is the fourth rule. And I'm not going to spend as much time on this one because it's completely different and slightly more nuanced than the other three. But I do think it is absolutely worth talking about, especially with the people that you work with and for you to consider on your own. And that is to ban subtle isms. And I'm not going to spend as much time on this one because it's completely different than the other three. But I do think it is absolutely worth talking about, especially with the people talking about, especially with the people that you work with and for you to consider on your own. Racism, sexism, homophobia, transphobia, and other kinds of bias. Now, this one is, the idea here is that a lot of the time, we don't intend to have these different biases. But we end up having subtle biases that come out. And we have to be aware of these things. The hard part about this particular rule is that you may not even see it happening until somebody else points it out or until after the fact. You look back and you think, wow, maybe I should have said something different. Or maybe there's some ingrained bias in me that I need to uncover and maybe eradicate. There are a lot of problems that lay very quietly under our kind of upbringing. A lot of problems lay quietly under our personal perspectives that we haven't been able to escape. Now, I don't want to go deep into this subject because we don't have time in this particular podcast. But be aware of these things. Be aware that bias happens not only flagrantly or, you know, in a way that we don't intentionally, but also accidentally. And of course, I'll link to Recurse's discussion on this. Their entire manual is worth reading. I think it is a really great way of looking at the work that you do. Some of it is specific to the Recurse Center's experience, rather. It may not necessarily apply directly to you, but a lot of it is applicable for developers. So I want to give you my personal advice on building relationships. And I'm going to start with the first one. Sum it up in a very simple sentence. If you want to build a legitimate relationship, you have to actually care about the other person. You can't fake it. You have to cultivate an interest for the other person's interests. You have to cultivate an interest for the other person's concerns and for their well-being. Now, this is the only way to actually legitimately create a long-lasting and effective relationship. And I'm going to start with the first one. If you want to build a legitimate relationship with another person, we can tell when people are faking it. You can tell when your friends are simply taking advantage of you. And most people can tell when somebody is only in it for themselves. So don't be in it for yourself. When you create a relationship with another person, actually start to care. And you can cultivate this. You can actually begin to care and listen to what other people are going through. Some simple steps you can take here are to remember to care. You can actually begin to care. You can actually begin to care. You can actually remember someone's name. If you want to create a relationship with another developer in your community, make an effort to remember their name, remember where they work, remember some of the things that they are interested in, whether it's languages or frameworks, or maybe things that are totally unrelated to their coding, their job as a programmer, rather. The reality is we spend most of our time in life thinking about ourselves or thinking about things that make us happy, or thinking about what other people think about us, right? So a lot of our focus is inward. It's thinking about what we are experiencing or what we are going through or our perspective on things. To create lasting relationships, you have to remove yourself from that kind of narcissistic environment. You have to start thinking about what other people want in their lives, what they care about, their interests, their perspectives. That is how you create lasting and genuine relationships. Start to care about what other people care about. I hope that this has been an interesting discussion on cultivating relationships and building relationships with other developers. I know that this is an extremely important part of any career. If you have found this to be valuable, come and talk to me about it. You can join the Spec Slack community by going to spec.fm slash slack. Of course, that link will be in the show notes as well as other links that are relevant to this particular episode of Developer Tea. I hope you enjoy your Wednesday. Thank you again to today's sponsor, digitalocean.com. Go and check it out, digitalocean.com. Use the code developertea at checkout. There will be a link in the show notes and a little bit of a reminder with that code in the show notes as well. You get a $10 credit if you use the code developertea. Use that code at checkout. That's digitalocean.com. Please take some time to leave a review for this show and subscribe to Developer Tea. This is the best way to make sure you don't miss future episodes of the show. And giving me a review on iTunes, that helps other developers just like you find this show. And it makes the show much more valuable because it allows me to spend more time actually crafting the content and spending time on it. And I'm spending time developing content for all of you. That is my ultimate goal with this show. Thank you so much. And until next time, enjoy your tea.