Hey everyone and welcome to Developer Tea. My name is Jonathan Cutrell 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 is 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. ReCurs.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 to kind of 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're 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 actually. The reason I actually found this document by the way is because Avdagram tweeted about well actually and somebody responded, I can't remember who it was at the moment, but somebody responded with this document and they said that this is a pretty good definition of well actually. 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 are adding value to 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 it doesn't really have, 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 ReCURS Center to talk about today's sponsor. Today's sponsor is digital ocean.com. Now I have gotten very familiar now with digital ocean. They've been a sponsor of the show for a while and I can't tell you how much I appreciate digital ocean and what they do. They provide a very affordable way of getting an SSD cloud server up and running today and 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 hurdle is to have a place to put their stuff, to actually have a place to launch the things that they are working on. Digital ocean 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 Teaou actually get a $10 credit which is basically like having two months for free. If you are looking to learn web development, digital ocean is a great option 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 digital ocean 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 digital ocean.com. I'm going to go ahead and talk about these other two rules and then give you a little bit of basic advice when you're trying to build relationships with people. The first one again was no fainting surprise. The second one is no well actually no minor corrections. The third one is no back seat driving. So if you over here 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. This isn't to say that you shouldn't help or offer advice especially when you are asked. 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. I've read directly off of recurs and now I'm going to give you my own opinion on this. I think back seat 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 it 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 are going to offer your help one of the most helpful things you can do is start by listening. Start by not saying 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 am going to do another episode in a couple of days probably about rubber duck debugging. Co-worker actually turned me on to this idea. Rubber duck debugging debugging but very simply do not be a back seat driver. Don't offer your advice unless you have the correct context and I would even say don't offer your advice until you are 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 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 intentionally but also accidentally. And of course I'll link to recurse 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 centers. The recurse centers 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 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 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 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. 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 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 digital ocean dot com. Go and check it out digital ocean dot com. Use the code Developer Teaat 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 that code at checkout. That's digital ocean dot 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 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.