Joel Clermont (00:00):
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:16):
When you work with somebody on a team, a software development team, there's going to be differences of opinion. I would say, especially with coding, there can be more of that because there's so many different ways of doing something, right? There's so many different ways of handling authorization or writing to a database or whatever. So there's going to be different styles, different preferences as to where to organize code, and all of that. So today, I thought you and I... I mean because we've had many of these discussions, could talk about how we approach it. Because I think there's a way to do it productively and a way to do it so that you don't feel bad about yourself.

Aaron Saray (00:58):
Yeah. You just say, "You're right, Aaron," and then you're ready to move on.

Joel Clermont (01:01):
It's very efficient to do it that way but...

Aaron Saray (01:06):
Yeah. I mean, that's a good point is... You're right, there's the mechanics of programming but there's also almost a form of art to it too. Like, you've seen some code then you've been like, "Wow, this is beautiful," and just like how would I ever explain that to someone who doesn't understand the art of code, you know? There's differences there in what constitutes beautiful. Like, even line breaks and stuff like that, you're like, "Ah, it's just so spread out," and someone else is like, "Oh, why is it so spread out? I have to scroll all the time," you know? There's all these different things whether we're talking about standards or design or even solving the problem.
So we run into that, I wouldn't say more often than I have in the past but often enough where we have different ways. I think as we've alluded to in the past, it's probably our backgrounds are a little different which bring different perspectives. Joel, you're familiar with working for yourself for a quite a long time and usually a lone wolf, single person. And I'd managed teams for quite a long time and I think of like, "How would seven programmers handle this, you know?" Those bring some different insights and thoughts into how you might handle that.

Joel Clermont (02:20):
And I would just add, there's also differences in aesthetic too. Like, you mentioned beautiful code or art and its like, well, one person likes the way this looks and one person likes the way that looks. So I think just to kind of throw this into the context early, some of these things there truly is no one pure right answer either. There's some nuance needed for two people coming into a discussion to figure out like, "Well, the right answer is that we agree but what we agree on in some cases, truly doesn't matter as long as there's a reason for it."

Aaron Saray (02:56):
Yeah, I think you're right. That's the first thing I kind of want to bring up too is, when it comes to having a discussion or there's two different viewpoints, we generally will find that the person who has the reason usually is the one who's going to end up winning that conversation. You know, is that thought-out reason or is it just a gut feeling? Well, if it's a thought-out reason, doesn't matter if you don't necessarily agree the reason is logical and that usually prevails.

Joel Clermont (03:23):
You're saying if you asked me, "Joel, why did you do it this way?" And I'd be like, "I don't know," I'm not going to win that argument?

Aaron Saray (03:31):
No, that's how you bring out the wrath in me, "I don't know." Oh man, I just feel my speech slurring already.

Joel Clermont (03:38):
Even having a wrong reason is probably better in your eyes than being like, "Well, I don't know,"?

Aaron Saray (03:44):
Well, yeah. I mean, you could say it's wrong reason but having a reason just means that you thought about it and then there's room for us to have a discussion. It's less emotional too when you have a reason even if you aren't maybe fully informed or whatever. I think that happens a lot with us is... Or the vice versa when we're doing code review. I've done this a few times where I'm like, "I don't like that," I'm like, "but I don't know why. So I guess we can-"

Joel Clermont (04:15):
Well, I know that comment.

Aaron Saray (04:16):
Yeah. I'm like, "But I think we can leave it then you know if it's..." Well, if don't have a better solution or suggestion, or if I have a "better one" I don't have a reason for it so then I have to back off on that one then.

Joel Clermont (04:32):
Well, but I think it's good that you even say that because there was one recently where it's a poll request review that you did for me. And you used that phrase and I'm like, "Yeah, I think you're right." I didn't have a real tangible reason either but I just made the change and I'm glad you said something because if you didn't say anything then it wouldn't have changed. And I think it did change for the better.

Aaron Saray (04:55):
Another thing that we, me and Joel, do in our conversations is we've kind of developed our own sort of phrasing or words or things that make sense to us as a team, and I think everyone kind of does that. One of ours is we kind of talk about dying on a hill. So it's like, "I'm going to dig it. I'm going to die on this hill for this conversation." Or it's other times where we might strongly disagree, have reasons but one of us will just say, "Well, I'm not going to die on that hill. I'm fine, you know. I disagree with this but it doesn't kill me to have this 'wrong'."

Joel Clermont (05:32):
Yeah. That's something to be able to gauge for yourself, like, how strongly do I feel about this? Because programmers have opinions but they don't always have to be really strong opinions. It's like, "Okay. Well, yeah, I wouldn't do it that way but you know what? You're right. We've done it this other way 80% of the time here, so we probably should just keep doing it." Just kind of knowing when to be like, "I don't really care about this." Not in a passive aggressive way, but like, "Yeah, it's genuinely not that big of a deal to me so let's just do it your way. That's fine."

Aaron Saray (06:03):
We're talking a lot about code but there's also another level which is ways things function or features and we can have disagreements about that too. It makes more sense then to kind of figure out, well, which one of us knows the most about the domain or knows most what the client wants or can communicate with the client? If Joel is client facing on this project and we have a disagreement about the feature, he might go to the client, talk with them. Otherwise, if he says it's the way the feature is going to be, even if I don't like it that's what I'm going to build, I'm going to build the thing. It's just because he knows the client and he knows what they need.

Joel Clermont (06:43):
I'm bookmarking this so I can use it later with you. Should we give a tangible example of this? Because one is coming to my mind and this might seem silly.

Aaron Saray (06:54):
Sure.

Joel Clermont (06:54):
But it kind of... There was a poll request I submitted that I was adding a new controller and the controller had an action that type hinted several things, right? There was the bound parameter coming from the route, there was the request itself and then there was an additional service that was going to be used inside the controller. You were like, "Hey, why don't you change the order of those?" I'm like, "What are you talking about? It doesn't matter." But then you explained and I liked your rationale. That there was kind of a conceptual ordering and if we do it the same way throughout the project, it's just one less thing that's going to be weird as you come back to it later as you move into different areas of the project.

Aaron Saray (07:40):
Yeah. I mean, it makes sense. Because there's a pattern that now when you look at a controller's action method you'll always know, "Well, we always put them in this orders so if it's missing one of those pieces of the pattern, it's missing it or it could be a mistake or something," it might help you look at it easier too. I think you gave them the example in the order that we do it but I think it was like you had maybe the request and then there was a service and then it was the model, or whatever. When I disagreed with Joel, I was like, "Well, I get that it functions fine, but my thought is, first of all our incoming request has a bound parameter. So let's put all of our bound parameters first because that's the first thing that we kind of think about.
Second is then when we have our incoming request that has our bound parameters, then we possibly do something with the incoming request data. So let's have our request class, our form response class or whatever, second in the list." And then after we have our data, sometimes then we have an injected service that we do something with that data. So that's how I always put those towards the end because they're the last ones to be used or thought of. So that was kind of the logic. Now, I mean others that are listening right now could be like, "I totally disagree, you should always have service first or whatever." That's fine but for us it was a disagreement and then we had a reasoning through it. And then we said, "Okay. Well, for our team or for this project, this is how we're going to do things."

Joel Clermont (09:07):
And just kind of replaying that conversation in my mind. At first I'm like, "But that's not actually how it's bound." I was kind of getting into framework internals in my mind and I'm like... I was almost thinking it was a premature optimization or something. Like, well, if you put it last and the form request validation fails, it won't inject that service. I was starting to argue in my mind but then I'm like, no actually even if it doesn't make a difference in how the code functions, conceptually I liked that you had sort of a layered approach to it and it made sense to me. So I'm like, "Okay." Because it made sense, I could remember it and then it's like, "Yeah, why not do it the same way in all of our controller actions?" I liked that.

Aaron Saray (09:52):
I'm going to share one other thing.

Joel Clermont (09:54):
Oh boy.

Aaron Saray (09:56):
I don't know. Joel does editing so we don't know if this one will stay in the podcast.

Joel Clermont (10:02):
Okay.

Aaron Saray (10:02):
But one of the ways that we also make sure that our disagreements stay civil is we try not to make it personal. A tool that we've kind of joked around with, with that, with each other is developing another name for each other. I make no mistakes whatsoever so I can't remember the name that Joel calls me.

Joel Clermont (10:24):
Oh boy.

Aaron Saray (10:25):
But whenever I see code and I'm getting upset at Joel for that or something, just in my mind... Because, I mean, it'll be false to say that you don't feel some emotion when you think things are wrong, right?

Joel Clermont (10:38):
Right, yeah. We're not robots.

Aaron Saray (10:39):
Yeah. But I don't want to put that on Joel as Joel the person I know, I want to put it on the bad version of a programmer he was at that time. I even ended up calling him Cole, so whenever I refer to... I'll message him like, "Cole, what did you do?" He knows that I'm actually possibly frustrated. But I'm not frustrated at Joel because I enjoy working with Joel, but there's a couple decisions that he made that I disagree with. The reason I bring that up is because I think it's important that you understand that even when you get frustrated, take it out on not the person. It's a set of decisions or actions they've made, it's not them as a person... If I've made a bunch of mistakes, sloppy code, we'll say I'm not a sloppy person, I just made some sloppy decisions.

Joel Clermont (11:31):
Well, and sometimes it's past tense Cole. Cole did that like three years ago and Aaron's in the project now saying "What is this?" I'm like, "That was Cole, I have nothing to do with that."
I want to establish some nerd credentials here.

Aaron Saray (11:54):
Okay.

Joel Clermont (11:54):
I was having a discussion with my son the other day about Rubik's Cubes and he was trying to solve one. I just mentioned offhand, "When I was a kid I bought a book on how to solve Rubik's Cubes." Well, now you have YouTube, but I thought that was kind of nerdy. And my son is like, "Well, yeah, I watched like an hour of YouTube video on how to solve these." I'm like, "Okay, all right." So we're doing a little bit of a nerd battle here and I said, "You want to know what else I did that was nerdy as a kid?" When I was 12 years old I had my tonsils out, so this was my first night in a hospital, it was kind of traumatic. So my parents they said, "What would you like as a present to keep you occupied in the hospital?� or whatever. And I said, "A dictionary." And not just a general... in my mind I wanted the Webster's Ninth New Collegiate Dictionary so it was a very specific dictionary,

Aaron Saray (13:03):
For our younger listeners that's a book that they used to put all the words that people use into. A book is made of paper.

Joel Clermont (13:14):
It goes on a shelf. So when I said that he couldn't stop laughing because I had clearly out nerded him. But in my defense, it can't be that weird of a gift because in fact I still have it. I pulled it off the shelf to look at it. The front page of it is like a dedication page where it says from blank to blank on date. The fact that that was in the dictionary tells me that was a regular gift that people would give one another so I'm not that weird after all.

Aaron Saray (13:45):
Either that or they just wanted to make it seem bigger. Because they remove some words and then they're like, "Well, he'll do a page count so let's-

Joel Clermont (13:52):
We need one more page.

Aaron Saray (13:52):
People make this a gift? I don't know.

Joel Clermont (13:57):
Yeah.

Aaron Saray (13:57):
I get what you're saying. I think kids these days they don't understand the struggle. Because let me tell you what the struggle was even with a dictionary, okay? Right now you go to Google and you kind of maybe type in a word or possibly even say it and it'll figure out the word. With a dictionary, you had to have a general idea of how you even spelled it to look it up. Like, "Oh, how do I spell this?" Well, you have to kind of know how to spell it to figure out how to spell it.

Joel Clermont (14:24):
That's right. No, for sure the first letter. Maybe even the first couple letters to be able to find it.

Aaron Saray (14:30):
Oh, I had no idea to look in the p section for pneumonia.
Do you want to be a Joel and not a Cole? Just head over to masteringlaravel.io and fix that about yourself.