Joel Clermont (00:01):
Welcome to No Compromises, a peek into the mind of two old web devs who have seen some things. This is Joel.

Aaron Saray (00:08):
And this is Aaron.

Joel Clermont (00:15):
Programmers have opinions on things. I don't know if you've noticed this, Aaron, but... And they like to express those opinions and they like to be right about their opinions. Maybe that's just a human trait, I don't know. I'm too much in the programmer bubble. But there will come up situations, it comes up between you and I, it comes up on teams, it comes up sharing what we do on social media or other places where people disagree. I thought for a topic today, we could kind of talk about this idea. Like, what if you actually think somebody is wrong and you want to share that with them. Is there a more productive way of approaching a conversation like that and what are your words of wisdom, Aaron?

Aaron Saray (00:55):
Well, I think that when you say that someone is wrong, it really kind of depends sort of the area, like what you're doing. For example, I'm going to focus on something where it's code view or code planning or-

Joel Clermont (01:10):
Okay.

Aaron Saray (01:10):
Because there's a lot of steps when you have other people to work with and we've always talked about that. Like, if you're in a team make use of your team, if you're on your own find another developer that's on your own and split some time with.

Joel Clermont (01:22):
Sure.

Aaron Saray (01:22):
So, if you're going to plan out your project maybe and you want to talk it over with someone, there's going to be times when you're going to hear them planning it out and you're going to be like, "Yeah, they're wrong." But you still kind of want to respect and honor the fact that that person took the time to plan something and share it with you. You don't want to go and ego in there, "Destruct and destroy." I mean, programming is not a UFC fight, right? You're trying to-

Joel Clermont (01:45):
Yeah, I think you're right about that.

Aaron Saray (01:50):
You're like, "No, I want to destroy." But you want to get your point across but you don't necessarily want to have to...You want to have healthy conflict, not anger and conflict.

Joel Clermont (02:01):
Correct, yeah. I was just going to say, along with that... Because the goal is you want to arrive at consensus, right? You don't want to just... Like, you were saying, "Don't beat somebody down." Kind of the old adage that, "Put yourself in somebody else's shoes." Like, how would you want to receive this feedback? I think that's a good rule to live by.

Aaron Saray (02:22):
Yeah. One of the first things I do when I have those feedbacks is, like you said, you really try to put yourself in their shoes to understand even what they're thinking and then ask questions. When you look at something and you say, if you say to yourself, "Oh, that's completely wrong." You shouldn't 100% know that they're wrong, right? You should have a good feeling that they're wrong. But you really need to put yourself in their place, follow their path, their pattern of thinking, and there's a couple things that might happen. First, you might realize that you're actually wrong thinking they're wrong because you've put yourself and figured it out. For example, oh, you wouldn't do it that way normally but they only have a day to do this project. You know?

Joel Clermont (03:06):
Okay. Sure, some other constraints.

Aaron Saray (03:06):
Yeah, that's wrong. But it's right in that scenario, I guess. You know, hopefully they're going to go back and fix that or negotiate for longer time or whatnot. You put yourself sort of in all of the... try to gather that information, put yourself in their shoes, and then you can kind of look at it and then you should be able to start to see some differences if you have a different idea where your thought patterns separate. Then that's a perfect place to ask a question. You can say, "Okay, I'm following what you're doing. I see you've planned X, Y, and Z. What about when A or B happens?" You're almost leading the question but not being snarky about it. But saying you've seen the holes, so you ask them about those specific problems in your logic and see what they have to say. You actually get some really good feedback that way or good engagement. Because people will be like, "Oh, I never thought of that," or "I have thought about that, I just didn't tell you about that."

Joel Clermont (04:02):
Sure.

Aaron Saray (04:02):
Because I can tell you one of the things that frustrates me, I am definitely not perfect but I do think out a lot of things and I share less than I think of. So I might come to you, Joel, and be like explain something and then you're just like, "Well, what about..." I'm just like-

Joel Clermont (04:18):
That sounds like me.

Aaron Saray (04:20):
"Joel, I thought of that. I just didn't tell you." Then I'm kind of fired up and you're like, "Well, you asked for feedback and why didn't you tell..." You know, I'm back and forth and then you pull out your boxing gloves and there you go, we're in that fight.

Joel Clermont (04:33):
That's right, yeah. I was going to say, as you're describing these techniques, I'm like, "I think Aaron's using these with me. I don't know if I like this." You know that question? But, yeah, to your point, don't assume somebody hasn't thought about something but you also can't assume they have, right? Asking that question allows you to kind of cover that concern without being accusatory and without just piling on. I also like the fact that you admit you're fallible, like you might be wrong about something. That's another reason why you don't want to come out swinging because it's a little more humiliating than when you actually turn out to be wrong. But I guess the other thing I was thinking of too in this, and I like how you sort of time boxed or scoped this down to code review.
There might be situations I think, where something is "wrong" or you think there's a better way to do it. Would you always call that out? Or are there times where you're like, "You know what? I've already mentioned this particular thing before, or, "It doesn't really matter here," or, "these other things are more important." Would you ever choose to just kind of stay silent on something that you think could be improved upon?

Aaron Saray (05:42):
Well, I accept your question and then choose to ignore it and answer a different one.

Joel Clermont (05:47):
I accept your acceptance of that

Aaron Saray (05:50):
No. I mean, along those same lines is, part of this is you have a reasonable assumption that you maybe are right and that maybe you've mentioned this a couple times before or whatever, it's still good to kind of ask those questions, listen to the logic behind the other developer's choices. Because when you have that conversation, then you get to solidify and understand if you actually really do know what you're talking about.

Joel Clermont (06:16):
Yeah, sure.

Aaron Saray (06:16):
I think we've mentioned this in the past in other podcast episodes where we've said sometimes even during code reviews someone, one of us, will say, "This feels a little weird, feels a little itchy. I don't know how it could be better, but I just wanted to point that out." You've done that to me and I've been like, "Yeah, you're right. There is something wrong here. I don't know what it is." So you can also leave yourself a little wiggle room there. Maybe you even did know what you thought it was but you wanted to point out that this area needs more thought.

Joel Clermont (06:50):
Yeah. I was thinking too, there have definitely been times in the context of a pull request review where you're like, "I don't know about this, I'm going to accept it but maybe you want to change that," right? Where you're not putting down the hammer, rejected, you're still raising it. I like the nuance of that. That you don't always have to drill it down into every possible thing that could be discussed, but you also don't want to gloss over things too. The whole point of a pull request review is to solicit that kind of feedback.

Aaron Saray (07:18):
Yeah. I think wrapping this all up is we kind of want to have a formula of providing feedback that is less confrontational but still honors the actual confrontation, which is the way we get better. Yeah, I guess that's right. It would be, we want confrontational-less conflict and you can get that by asking questions and trying to put yourself in there and understanding that. That doesn't mean that you don't know what you're talking about, it just means that you're taking a more mature, more holistic way of bringing up the conversation.
In a lot of cultures, when you get older people start to think, "Oh, you're more wise, you learned more." I mean, that's what time should do, it should make you a smarter person. But I think there's a different thing that happens. I think you see older people stop doing as many stupid things because they're just tired.

Joel Clermont (08:19):
That's a fair point. Yeah, I'm putting myself in the shoes of that older person, I could maybe see that argument.

Aaron Saray (08:25):
I can see maybe when you're younger, maybe you go to a pub or a bar and you might even get in a fight or something that silly. As you get older you're like, "I don't even know if I want to go to a pub, I might just stay home."

Joel Clermont (08:37):
It's too expensive out.

Aaron Saray (08:40):
People would say, "Oh, well, as you get older you're smarter and you're not getting as many conflicts." I'm like, "No, I just don't want to go anywhere. I'm just tired."
Sometimes it's hard to ask for help from developers who have been doing it a long time because you're going to feel foolish. But we go out of our way, as we've hopefully demonstrated on this podcast, to share feedback in a nice, comfortable way. Do you need that?

Joel Clermont (09:06):
We can help. Head over to masteringlaravel.io and use the contact form.