The best argument is no argument

Disagreements and debate can sap your team's energy. We'll talk about some ways to avoid unnecessary conflicts, and how to successfully handle a difference of opinion on your team.

• 00:00 Developers want the "one true way" to do something
• 01:45 Handling a difference of opinion
• 02:33 Staying consistent within a project
• 03:44 Using tools to help consistency
• 06:00 Document your project standards
• 07:37 Keep an open mind
• 11:01 Choose your battles wisely
• 12:25 Involve the whole team in the discussion
• 13:05 Silly bit

Creators & Guests

Host

Aaron Saray

Host

Joel Clermont

What is No Compromises?

Two seasoned salty programming veterans talk best practices based on years of working with Laravel SaaS teams.

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):
Recently I saw a tweet from the Laravel man himself, Taylor Otwell. It was an observation that many developers try to find the one true way to build a Laravel app. It's not specific to Laravel, right? Most developers would face this. But his advice was basically, "There isn't necessarily one true way." So don't get hung up on that, don't fret about or change direction multiple times trying to find the one true way. Just build something, see what it's like, and decide for yourself what paths are successful and what paths led you to trouble. It got me thinking as we work on a bunch of different projects, with a bunch of different teams, I've seen the same thing where it's important to find your footing as to like, well, what is the way this team does something and trying to work in harmony with that.

Aaron Saray (01:17):
I think that's important too because it's this team, which is a bunch of individuals, not, "How would you?" Sometimes you can make your case and say, "I think it makes the most sense to do this a certain way." But if you find yourself saying, "Ah," and doing it your own way anyway, I mean, that's kind of a bad thing. It's, what does a team find most effective together? I mean, that's why you have a team because you're trying to be the most effective, the most efficient together.

Joel Clermont (01:45):
Yeah. One of the challenges is sometimes when there's a difference of opinion, you can get defensive. Like, if somebody is questioning, "Well, why did you do this?" It's easy to interpret that as like, "You did it wrong," but that may not be why they're asking. I know between you and I, we've worked on things together and I'll ask you, "Why did you do this this way?" And what's cool is you usually have a reason, which I respect. But sometimes we do things and we don't really have a reason. It's just like, "Well, that's the way I've always done it." Or "I noticed that's how it was done in this other part of the same code base and I just didn't give it a second thought. I kind of followed that." So having those discussions, but remaining non-defensive, is actually a really good way to grow as a developer.

Aaron Saray (02:33):
Well, you brought up a interesting point. Which is, what's happening in other parts of the code base. Now, I think there is a good idea to refactor and make things better and move forward, but at the same time projects, they sink or swim based off of consistency. Even though you might learn a new tool or a new technique or something like that, I still think that you might still have to kind of do stuff the old way or "the bad way" to stay consistent with your application. Now, the argument comes in we're like, "Well, if I keep doing it the old way, there's more I have to refactor." That's true but it's more of the same pattern versus I learned something this month, then I change it, and then next month I learned something new, and then the next month there's that new tool came out. Before you know it, you have four different ways of doing stuff. Then, of course, the new guy comes in picks the random, worst example of doing it-

Joel Clermont (03:33):
Always.

Aaron Saray (03:33):
... and copies that. And you're like, "What are you doing?" He's like, "Well, that was an example in the code." I'm like, "No. Obviously, don't pick that one," with no context.

Joel Clermont (03:44):
Yeah, for sure. I guess one of the ways that is handy to try to reduce some of this friction... you can't do it perfectly through tooling. But there are tools that we've used on our projects, we like to introduce to new projects, is some sort of style enforcement. Because sometimes it's bigger decisions like, "Well, where do I put this code?" Or, "Do we use events versus explicit actions," or things like that. But a lot of these decisions are also just, "How should the code look?" A style fixer or something right in your editor shows you like, "Oh yeah, we don't use braces on a separate line for this. We put it on this line." I like that because it's just something I don't have to think about. Especially if you move between projects and they're different, just listen to your tool and be like, "Okay, we do it that way on this project," and nobody fights about it.

Aaron Saray (04:40):
Yeah. Then some of those tools can make some of those changes for you automatically. But one caveat I'd put with that is, just because a tool makes a change automatically doesn't mean that you're not responsible for it.

Joel Clermont (04:53):
Okay.

Aaron Saray (04:55):
I'm a huge fan of making the changes pre-commit or while you have the code in your possession you could use automated tooling. And then when you're pushing something out to a certain place, all it is then is standards checking. Meaning that even if they found an issue as you're going to deploy it, it then rejects it. It doesn't try to automatically fix it because we don't know what those tools are going to do. We're reasonably certain, but we don't know a hundred percent, right? No code is perfect. So when you're using code to adjust code, you need that human interaction, that human element in there just take a quick glance at it and be like, "Yeah, that was what I wanted."

Joel Clermont (05:38):
Yeah. And I've dealt with tools like you're describing, where it does it as part of a pull request and it makes more commits. And it's just a little noisy too, it's a little frustrating. It's like, I'd rather do it locally and get it right than rely on some upstream thing that's going to change it for me to make it standard. The standard is good, I get that. And it's good, like you said, to have a check and warn you if you didn't follow it. But local tooling for sure, all the way. No arguments from me there. Other than tooling though, I know you're a big fan of documentation. Have you seen documentation help to an extent with kind of this idea of, "This is how our team does it," or, "This is the way that we found effective in terms of code structure or architecture", things like that?

Aaron Saray (06:22):
Yeah, I've seen that sort of thing evolve over time with projects. A lot of times that's in some sort of wiki tooling for the project too. It's not necessarily part of the project, it's not documentation of the code specifically. But it's like, "Hey, if you're going to do this, here's a general process that you might follow," and that might be on a wiki. And that might change, you know. Maybe you thought you're only going to use services and then turns out that we've been overusing services. So you don't necessarily change the code and you don't put a comment in the code saying, "I wish I didn't do this." You just change your team's documentation and say, "You know, now we should all refer to doing it this way." Also when new developers come in, they have a place to kind of reference.

Joel Clermont (07:08):
Yeah. And it's not like every single possible decision can be captured in documentation, but the big ones. And especially if it's something that the team has hashed out, like document that decision so that it's not just going to benefit the people involved in the conversation at that time. That it kind of becomes knowledge that the team can share and especially when that new person joins the team. Now they can read that documentation and get a sense of like, "Okay, this is why we do certain things."

Aaron Saray (07:37):
I do have a question for you though. So part of this, as you kind of alluded to, is personal opinion. When you get to a point where it is not linting or code standard and it's just a personal opinion, "I think we should structure it this way." Or, "I think we should structure it that way." How do you resolve those types of conversations?

Joel Clermont (07:58):
I guess a part of it is what I mentioned earlier is to not try to make it personal. Either as the person questioning something or as the person defending something. But I think a lot of it has to do with open-mindedness too, to not assume my way is correct. Like, "Hey. Okay, so how would you do it differently?" and then listen to those reasons. But honestly some of it too is, if you can't defend why it's good... Some things are sort of a gut feel and there's no specific logical reason why this is objectively better. But if you can't even explain a little bit of why you like doing it that way, then maybe, to me, that's the signal like, "Ooh, I guess I can't really defend this, I can't explain it. I should be even more open to what my teammate is suggesting, and give it a shot." Or at least consider it.

Aaron Saray (08:48):
Well, let me make that question a little bit harder on you-

Joel Clermont (08:51):
Okay. All right.

Aaron Saray (08:51):
... so you can't dance around the answer. I know that you've been programming for quite some time and you just know a lot. You've ran into a lot, you've made a lot of mistakes. We all have, right? So you build this knowledge, 20 some years of knowledge. And then you go into a project and you're working with a junior programmer and you run into that where they think their idea is best because of their experience or reading a new article or something And then you come into it and say, "Well, for this reason my idea is best because I've ran into it before," when you really deep down know that you're right but a team member is saying, "No, let's do it a different way." Even if you're both "open-minded", how do you solve something like that?

Joel Clermont (09:43):
Okay. If I'm hearing your question correctly, it's not that I don't have a reason why I know it's right, I can explain it. It's just that the other person disagrees, so you're just at a fundamental disagreement. Both people think they have a valid state. Okay.

Aaron Saray (09:59):
Yeah, you both have reasons. And in this case, just for my example, I'm saying that your reasoning is maybe based off of... They're both real reasons, but you just feel very strongly about your reasoning because you've been there before.

Joel Clermont (10:12):
Sure. Well, on a team, generally somebody is going to be in a position to make kind of final decisions. But instead of just relying on some arbitrary or some boss to be like, "Whoa, this is the way we're going to do it." Especially if I'm that boss, I don't want to necessarily throw my weight around. But I guess there's also degrees of, "Is this the hill I want to die on?" If I feel strongly then maybe that is, then maybe that's the time to pull the card of authority or appeal to whoever the team lead is to make my case and have them rule in my favor. But maybe it's not something that really matters. Like, "Yeah, that bugs me, I don't think it's right. I'm pretty sure it's going to bite us eventually, but it's not that big a deal." For team dynamics I might just let that one go.

Aaron Saray (11:01):
Yeah, I think it's a area I've struggled in the past too. You're right, is this the battle I want to have? Does that really matter? One of the other ways I've kind of attacked that too in the end, saying, "Well, because of what I know and here are the risks involved, I just want everyone to know that this is a likely outcome of this." You know, "X, Y, Z bad situation, but I'm willing to do it the other way." For me, it's almost like hands... not hands washing, but like "Hey, I told you so," is almost a strong thing too. But to say, "This is what I predict will happen, but I understand that as a team to function, we need to go this direction." That way at least we're prepared too of what might come down. Versus if you keep that to yourself or never really elaborate on what that means, just, "I know this is the right way to do it," there's no educational part of that.

Joel Clermont (11:59):
Yeah. I guess that's a way of kind of gracefully backing out of the conversation whilst not giving up on your principles or not just throwing your hands up and like, "I don't care anyway." Because that's not a good attitude either. But I like that and I think having that proof so you can come back and be like, "I told you so," is perfect. That's awesome, that will make everybody on the team happy. But, well maybe-

Aaron Saray (12:22):
Yes. Just, "I told you so."

Joel Clermont (12:24):
... one other thought I had while you were saying that is, a lot of times there's kind of two people maybe going head-to-head with different opinions but the team is probably more than two people. So your point of even just laying it out for the team as a whole, "Here are the pros and cons," maybe the team as a whole will kind of come to a consensus. And that's where if you don't agree with the consensus, maybe you just give in. Kind of document it, keep it in mind if it does actually come back up in the future. And then gently remind people, kind of go back to that earlier conversation.

Aaron Saray (12:58):
No. Never give up, never surrender.

Aaron Saray (13:00):
That's our motto. Die on every hill.

Aaron Saray (13:08):
I was thinking the other day about what are some of the worst pickup lines or ways that you've tried to get a date. And I know you're married, Joel, so you're going to have to think way back. But I think I'll share one of the embarrassing ones I had and maybe you can tell me something as well. I know a lot, somewhat. I know something about tea and I was in the tea aisle of the local grocery store. So you know that already that's a bad choice. But I saw a nice young lady there that I, "Oh, I want to chat with her." So some book or something at some point told me, if you want to find a girl in a grocery store, ask her for some advice.
All right, so I walk up to her and she's looking at the tea and I face her and she looks at me, kind of smiles. And I go to say something and then something weird happened to me. Something that's never happened to me before in my life and never again since. It's just the worst thing that could possibly happen at that moment. She looks at me and smiles and I explosively sneeze right in her face. And she goes, "What the," and I'm like, "I'm sorry," and she goes running away. So now I know there's a woman in this world that has a story that, "Some guy walked up to me in a grocery store and just sneeze blasted right in my face." And my take away from that was, "Man, I am just not great at picking up women."

Joel Clermont (14:46):
Was it a perfume or something she was wearing?

Aaron Saray (14:49):
No, I have no idea. It was just like what? Do you have any stories that'll make me feel a little better about my life?

Joel Clermont (15:02):
I do. I have a story, but boy, it's a totally different direction than that.

Aaron Saray (15:07):
Okay.

Joel Clermont (15:07):
No, I was just going to say as you called out, I am married. But not only am I married, I've been married since I was literally 19.

Aaron Saray (15:16):
Wow.

Joel Clermont (15:16):
And, bonus points, my wife proposed to me. So that shows how much of a go-getter I am. I could literally say, I don't think... I'm trying to think, I don't think I've ever contemplated like, "I want to go talk to that person and thought about it." I am the wrong person to ask. I can give my children no advice on dating for this very reason so I will send them to you, Aaron.

Aaron Saray (15:43):
Do you need someone to come in and argue with your team about everything you're doing wrong?

Joel Clermont (15:47):
Well, we won't do that, but we can help. We can share our experience to help your team find tools and processes that will make it better. Contact us for a free consultation on our website nocompromises.io.