Teamwork Makes The Dream Work

key.

Welcome to Syntax.

In this Monday, hasty treat, we're gonna be talking about teamwork And how teamwork can make the dream work, and then, basically, how you can work on a team effectively. And this was all kind of inspired by a single Reddit post that I read that Kinda made me a little upset at how this person was talking about some of their teammates. So I wanted to take some time to dive into this topic and how we respect and work with our teammates to share goals. Now my name is Scott Talinski, and I'm a developer from Denver, Colorado. And with me, as always, is Wes Bos.

Hey.

I'm excited for this. I don't I had worked on many teams in the past, but, and I I work with my assistant and AJ, who does some dev with me and the support. But I don't I wouldn't say that I'm like a major team player, so I'm curious to see what tips you got here.

Yeah. It's fun because, you know, I've always I've always felt like I'm a pretty good team player in the web world, but, like, I I never knew that I had any sort of, I don't know, any sort of, like, firm ideas. But then when I posted my my, Here's here's how I think this person should have handled the situation to that Reddit post. Like, the number one comment on it was, this dev teams, and that's like it had, like, 400 uploads. Like so people, I think they really resonated with with my response. Yeah. That's great.

This episode is sponsored by 2 amazing companies, both s companies Sentry and Sanity.

Now Sentry is the place to see all of your errors and exceptions happen in your website application or whatever. In fact, we use Sentry on both our UI as well as our API, And it's a lot of fun to see those errors. In fact, this is really this is a perfect use case for Sentry the other day. I think it was Friday. And and some of y'all are gonna laugh that I was deploying on Friday, but, I I I had been seeing this century error that was really kind of a a dumb one. So then I fixed it, and I pushed it up. And then I marked it as resolved in my century. And I'm like, okay. This is resolved. I can go home now and and be happy about my work for the weekend. Then I got an email from Sentry maybe, like, 2 hours later, and it says regression.

This bug that you had resolved, this thing's not resolved.

It's happening again. And I was like, what are you talking about? It's very clearly I put a conditional in there. It it should no longer There's no way this error is happening, and that's when I realized I only pushed to staging and never pushed to production. So Sentry saved my bacon there because there, I was able To find out that I solved the error and exactly why the error wasn't solved, thanks to their awesome system of marking something as fixed And then they're complaining about regression. So that's right. If you have any errors and exceptions, head on over to century.i0.

Use the coupon code tasty treat, all lowercase, all one word, and you'll get 2 months for free. And maybe Century will save your bacon like it saved mine. We are also sponsored by Sanity. What is Sanity? Sanity is a service that

holds your content. It gives you an entire UI for editing all of your content. You can upload all your images to Sanity.

You can create all your content types. You can relate all of them together, and you can create workflows in terms of, what the approval process looks like. You have full control over all that. It's it's awesome. I've used it quite a few times myself.

You want to check it out for your own if you've got an app that you want to push and you need a back end for that. If you've got a marketing website that your your company is gonna be doing if you, are working on ecommerce. You name it. Sanity is the one that you need. Go to sanity.ioforward/ syntax.

That is going to give you double the free usage tier.

Pretty sweet.

This is one little, One pretty sweet thing that they just did is if you want to use the sanity coupon code, you can run, npm install dash g sanity CLI, and then you can sanity init with a coupon code on the CLI. I think that's one of our first sponsors that has put the, the syntax coupon code in the CLI. So go to sanity.ioforward/ syntax to see how you can do that. It's pretty sweet. Nice.

Cool. Okay. So let's get started here. I do wanna talk a little bit about this Reddit post first and foremost because, Well, I'm not going to link to it because they deleted it anyways.

Even though the comments were occasionally harsh against them, but, I don't know why they deleted it. It would have been a nice little learning opportunity to be able to read this whole thing. I I do because I I quoted some of the things they said at the time, so I do have an access to remember some of it.

This this Reddit post, basically, to sum it up, they they were a junior developer working, with a more senior developer. They didn't specify the other person's role, but, basically, they were saying I was unhappy with the code that this person was submitting.

And they used some really kind of rough language to describe their interactions.

Direct quotes include, I already hold grudges against him. What I expected from him was to reuse the same button component, apply the right props to it, and be done. When I confronted him, I didn't understand his weird choices.

And lastly, I'm the least experienced dev. So I I I thought this was a really interesting post for a number of reasons, but also something that, you know, I think people do encounter in their teams where we write code and code can occasionally be ego filled. Right? I I've worked with a number of developers who certainly have an ego about their code. They think their code is good. They think their code is the best, and maybe they don't understand other people's code choices.

And sometimes it's easy to get wrapped up in that aspect of things about, hey. You know, I think I'm I'm really good at what I do here.

You're doing this thing in a completely different way than I would have expected or wanted you to do, but, you know, why why does that make me feel so, Like, aggressive towards you or something like that. And I think that really comes down to just some some kind of flaws in the thinking about projects and teams in general. So let's start off with talking about the fact that we are a team. When you work on a team, You have a shared goal. And the easiest way to think about this is sports. Right? You're on a sports team. You have a shared goal to win the game. Right? To make a touchdown to, climb to the top of the mountain. Climb to the top of the mountain to shoot a 3 pointer.

Can I stop you for a sec? I started watching that Netflix documentary that you recommended a while ago. What's it called? The 14 peaks one? Yeah. I'm only on a I think I'm, like, 8 peaks in, so don't spoil it for me, but it is bananas so far. It's it's bananas. And it's bananas for somebody like me who's, like,

really been into, like, other climbers like Reinhold Messner who, like, did some, Like, very insane stuff. And to see this guy doing these these peaks even with oxygen or whatever, I'm just like, yeah. This is just straight up bananas even, like, in historically, it's bananas. So, yeah. Yeah. Yeah. Very good.

Yeah. So okay. So you're part of a team, and And, you know, you have these shared goals. You have shared opportunities to make cool things in in distribute code in a way that's going to be helpful for your your client.

It's always important to remember and keep in consideration that just like any other team, you have a shared goal, And that goal is to make the best product or to deliver the best code in the deadlines and time requirements that you have. And to keep those shared goals as a keystone in your communication will always help you be a better teammate because you're you need to always have in the forefront here that, hey. We we are working together on this thing. It's not my code versus your code. It's not my code rules, your code drools situation here. It's all of our code can come together in harmony and work together to deliver the product that we need to deliver. So your teammates, first and foremost, are not your adversaries.

Do not hold grudges against your teammates. If you have, you know, beef with your teammates, go go go to hot pot and cook that beef out or something. I don't know. The guy I'm just trying to come up with some sort of beef beef joke there, but no beef. You squash that beef. Figure it out. Talk about it. Be people and talk about it. No egos. Right? Wes. Do you ever do you ever encounter developers with egos? Is that something that happens? Oh, yeah, absolutely. All the time. It's funny because, like, I've been on

I've been on, like, tech Twitter for, I don't know, probably 12 years. And, like, I've seen a lot of these personalities, Sort of like rye rise and fall where you see, people who are getting Like, it seems to be like there's people that are brand new.

And then as they get better with their skill sets and become more popular because of open source libraries or whatever, there's You see people's personality sort of take turns, and I've seen many people. I'm not gonna name any names. I I would like to, like, maybe have somebody on who I've specifically seen this in. But they've gone from, like, just being this person that has a huge ego and, fights people on every single decision and will, like, go up again. Like, you know, you there's 2 libraries that do the same thing, and They have 2 different approaches, and everybody's throwing graphs at each other. Which one's faster? Tossing graphs. All that tossing graphs.

And then at a certain point, I often see these people just, like, sort of, like, fall off.

Not that they stop tweeting or anything, but it's just like, I don't care anymore. You know? Like, what am I doing? And, like, I've I've certainly been in the in the same situation as well where You are so invested in something. And then when somebody says something, against the tech, like, you are not your code. And I think that's an important thing to remember. And that if somebody is criticizing your approach or your code Or even, like, the the course that you've put out, they're they're not attacking you personally. They're attacking the work that you you've made. And that That can really hurt, but you need to make sure that that doesn't necessarily ruin your day or or whatever.

So that's a Sort of a long way of just saying, like, yes. I've seen many people over the years, and it's it's funny to see this sort of arc of people getting more frustrated and more frustrated. And then at a certain point, I feel like it's when people I don't know what that point of enlightenment is, but out of certain people. A certain time someone just goes like, I don't care anymore if you think I'm just doing my thing. Here's the thing I've made.

Here's my ideas. I'm open to hearing your ideas as well. Yeah. And I don't know if it's it's the fact that YouTube has hardened my skin so much, But, like, you know what? It's it's so funny because for a long time, I would get so I don't know. YouTube comments could ruin my day. But somewhere between, this guy has no idea what he's talking about. Look at this guy's stupid face.

This guy is ridiculously dumb. Like, you know, you get so many just idiotic, comments like that. You sort of just learn to block out anything like that because it's like If if you were to take any any of these comments to heart or any of this, like, ego pushing around, it would definitely mess you up. And so I at some point, I've, like, really learned to block out some of that stuff and just like, look. This person is just either, You know, they're just either jealous of my success. They're just haters or whatever. You know? They're they're but either there could just be having a bad day and taking it out on me or who knows what. Right? So, okay, let's not hold grudges against our teammates. Let's not be adversaries. Let's be, on the same team, let's be working together for shared common goals. So let's talk about some practical tips. Right? So one, if you're a junior Or a more junior developer on a particular project.

It is your job to listen and, provide feedback, But not to to do so in a way without respect.

Your more senior developer who's ever leading, if you are the lead of this particular thing, Even if you're not even if you are less senior. Let's just say you're the lead on this thing. If you are the lead or if you are not the lead on this thing, So you're you're following on this thing. It is your role to listen, to learn, to ask questions, and to discuss things with respect.

If somebody says, hey. Can you do this thing for me? And you are confused about that approach, give them a question and say, hey. I'm just wondering about this approach here, but don't question and say, hey. I think your approach stinks.

Why don't we try my approach? What would you say? Hey. I'd just like to learn a little bit more about why you're why you're doing this approach.

Because maybe in my experience, I've seen it done this other way. Then maybe you might learn something. Right? But if you shut them down or you attack someone else's ego, you know what happens. I don't I don't know. Too many everybody's in been in interpersonal relationships in your life. And If I come at you and I say, Wes, you suck. Like, what what's your first response isn't to be like, okay. Let me hear you out there. It's to be like, no. You suck. It's like everybody responds with aggression to aggression. Right?

Also, I think, like, a lot of people are awful at Asking questions or saying that's fine. Like, me and my wife always laugh because sometimes I'll be like, like, hey. Do you wanna do this? And she'll just be like, sure. And I'll be like, sure or or yeah. You know? And it it's really funny because it's like like, are Okay. Is this like a are you just being, like, fine, whatever? Sure. Or, like, sure. That that that seems fine to me. And, like, You can especially now that everybody's online, you often lose that, when you are asking some of a question. Like, here, this is the I'm building this new thing on Remix.

Why not use Next.

Js? And, like, it's why not use Next. Js, you idiot. Yeah. Right? Or Yeah. Oh, I never thought about that. What's the like what's the differences in between? Like, what's the approach? I'd love to to hear about it. Right. And a lot can get lost totally when You aren't good at asking questions.

Yeah. In in, I mean, being cognizant of how your message could be read in different ways is also a big thing is this to be a little bit more flowery when possible. I mean, it doesn't hurt you to to be more softer in your I mean, we gotta be Charmin Baby UltraSoft here sometimes, and I think that's okay. Because again, there there is going to be ego wrapped up into it. But make sure you do understand the guidelines of what they're asking for and ask for clarity when you you don't get that.

Because If if you ask for clarity upfront and if you get that information correctly relayed to you, then when you submit your PR and they say, Oh, can you do it this this other way? Then you should be maybe aware of what they're going to say before they're gonna say it. Because, like, the way this person Came across with saying, I expected them to do it this way, and they did it. It's okay. Well, did they know that they were supposed to do it that way? Was that relayed to them? And maybe they made these choices for a reason that maybe you're not aware of. Maybe maybe your button component actually sucks. And, instead of hurting your feeling by telling you that, they they broke their own, and and maybe they were trying to to, you know, be nicer to you instead of To hurt your feelings in that way. Either way, if you are the lead, make sure the the guidelines are very, very clear. Make sure that your your other developers know what they're supposed to be doing. Don't talk down to somebody If they submit a PR and that PR is not what you're expecting, you know, GitHub has a really awesome code review feature where you can go line by line and say, hey. When you did this, like, 3 nested ternaries, do you mind doing this in an if else? Because this is maybe a little bit hard to read.

There are ways to do it. It just be nice. Just be nice, be cool. If you're doing code reviews, make sure your code reviews have the expectation that they are egoless, that everybody is Aware that we're here to produce good things and then maybe not nitpick everything.

Like, somebody left a comment that says, do not do this, and then you you leave a a PR that says, hey. Change the word do not to don't. Okay? Like, That's not important. That's not that's nitpicking. Right? So just be aware that there is ego attached to this thing. And if you were the lead, make sure that is established clearly. And if you are not the lead, make sure you understand what are the guidelines.

Yeah. And I think also To reiterate on the point you said earlier is like you have to remember that, like, let's say you're building a website to help people book real estate appointments.

You have to remember that at the end of the day, you're trying to make your client's life easier and make them more money and all of these things. You need to keep those goals in your head and not get so lost in that, like, everything revolves around you as the developer, and you are the keeper of the code and and everything like that. Right. Like you, of course, have to make sure that the code is good and and whatnot. They have to make sure that your your end goal is is being met as well. Totally. Totally. Totally.

Interpersonal tips.

Listen.

Don't pretend to listen. Really listen. Like, when You're talking to your spouse or your partner about something and, or they they want you to listen about how they're feeling. Listen.

Don't Don't pretend to listen. You know? Listen. Just for real. These are people, and these are real relationships. These are your coworkers. Listen to exactly what they're saying. Respect your coworkers, respect their work, respect their code. It's something that they've put effort into. I mean, like, if I built something by hand like a bookshelf, And I said, look. Check out. I built this bookshelf, and you come in. You're like, you forgot an arrow over there. That doesn't help me. Nobody nobody likes that. That's not happy. That doesn't make people happy. Don't hold grudges about code. There's nothing there's nothing in the world that that should make you hold a grudge against someone else because of their code. If you have beef about it, talk about it, but there shouldn't even be beef. Just just really make sure that you're aware that you're on the same team with common goals.

People write code. Consider the fact that there is a person behind that code. And, again, if you insult that code, you may be insulting that person, so don't insult code. Just talk about it. Right? Be cool.

Consider that you are not always right. If somebody does something differently than you, maybe ask why they took that approach before telling them that that approach is wrong. Try to get inside of their headspace and figure out exactly why they made the decisions they made before trying to crap on their decisions.

And, likewise, again, be a student and a teacher. If somebody is struggling with something, teach that to them, but don't do it in a condescending way. And, likewise, if somebody is doing something you don't understand, ask if they could teach you about how they did it.

Lastly, I wanna talk about celebrating wins. We, as a team, we we you know, you see sports teams, they they they do the game, they score the goal, and then they get the Gatorade dumped on them. That's great. That's so much fun to get the Gatorade done. Now they say, oh, this is cold. Right? This is so much fun and cold. So think about sports. And when a team wins, they all celebrate together. They all they all cheer rah rah Celebrating the wins, in a way that's positive for your entire team, and be cognizant about that. Know your team members. Right? If somebody doesn't drink, Don't go to the bar. That person doesn't that's not celebrating for that person.

You know, and it it but if you then again, if you're all if you're all super into drinking. Sure. Go to the bar. Whatever. I don't know. But do outings that everyone would enjoy and really take the time to get to know everybody in a way that you can understand Lee. Exactly, like, what would be fun for people or maybe even get management to approve some spending or something to say, hey. If we do this big win, we do this big. We all work overnight and and get this thing pushed out the door in time. Can we do x, y, and z? Can we get this course? Can we get this tool? Can we you know, can you buy us all licenses to this particular thing or something? And who knows? Maybe it'll get approved. Maybe it's not. Maybe Maybe that's one that you gotta know your management and what they can do. But either way, celebrate those wins in a way that's fun.

Take a break and Put on some music and have a dance party. Who knows? I've I've had some teams that that have been, like, that have had all different ways of celebrating wins, and there's nothing better than working really hard on something and getting that chance to take a breather and and have everybody, you know, really celebrate that shared goal for you. So make sure that you are a team. You're working together.

Respect, celebrate, and be cool. Beautiful. I like it. These are are are really good tips And how to make your team go forward.

And I if anyone else, I would love to hear, like, other people's tips. Sure you tweet them at syntax fm. It's still like like, do you have any, like, mantras or rules within your team to make sure that this type of stuff doesn't happen? Because I really think that this could really tear a team apart totally

oh yeah and and I think it's important as like being a manager to be aware of like maybe who's who's fighting with who or who's got issues with who and and get ahead of that stuff. And maybe you can mediate in a way that is, you know, good for everyone. Alright.

That's it. Thank you so much for tuning in, and we'll catch you on Wednesday.

Peace.

Head on over to syntax.fm for a full archive of all of our shows.

And don't forget to subscribe in your podcast player or drop a review if you like this show.