Don't ignore that pain!

It's easy to get used to things that cause us friction or pain in our development process. In this episode, we discuss how to avoid that trap and how to evaluate when to invest time in fixing that pain.

Sign up for our Laravel tips newsletter!

Find out more about Mastering Laravel Validation Rules.

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:09):
Maybe you've seen on support forums, I think I've seen this on Stack Overflow, where there's this phenomenon referred to as the XY problem. Where if somebody asks you, "How do I do X?" It's considered a little rude to be like, "Well, have you thought about Y?" Because while that might be helpful, that's not-

Aaron Saray (00:37):
Are you saying Y like the letter or why the question?

Joel Clermont (00:41):
Yes, Y the letter. The letter X, letter Y.

Aaron Saray (00:44):
Okay. I was like...

Joel Clermont (00:44):
Yeah, it is kind of confusing. All right. But, yes, the XY problem is, "How do I do X?" "Well, have you considered Y?" That's the vague interpretation, my interpretation, of what they mean by that. And it's considered-

Aaron Saray (00:58):
Many times on Windows forums, "how do I install antivirus software on my Windows computer?" People would respond, "Just use Linux."

Joel Clermont (01:08):
Oh, boy. Yes, that would be an extreme example of this.

Aaron Saray (01:12):
Okay. So I understand what you're trying to say.

Joel Clermont (01:15):
Okay, good. Thank you for clarifying that. It is an inclination I have though. I'll hang out in a Slack with other developers and they're having a problem. Sometimes my knee jerk reaction is like, "Why are you doing that?" While it's rude and that's probably not the thing you want to lead with, I think there is some value in a person taking a step back when they're having an issue and just kind of reevaluating the context of their problem. Like, "Is this actually the right thing to do?"

Aaron Saray (01:49):
How do you balance that question with you just not knowing their domain area or the history of their project? Because I've seen that a lot, where I've asked a pretty complicated question and someone said, "Why would you even want to do that?" I don't have four hours to explain how we got here.

Joel Clermont (02:07):
Well, that's why I think you wouldn't lead with that because that's maybe where the rudeness comes in. Is you're assuming you know more than them. But I'm thinking of a specific instance of this where I did reply to the question. But then I asked, "Why is it that you do that as part of your development process?" I'll give a specific example. Like, "Why would you cache configuration or cache routes in the Laravel world on your local development environment?" They had a reason for it. I had a secondary question like, "Well, why would you do that thing?" But that addresses your question there, Aaron. It's like, sometimes there's a reason and maybe the reason isn't even good, it's just inertia or, "Oh, man it's too hard to get everybody else to do this differently." But I still think there's value in maybe thinking about the question and trying to avoid the pain instead of just trying to figure out the bandaid for the pain.

Aaron Saray (03:06):
Let me make sure I understand what you're saying here though. When the other developer asked the question, you first answered how they would do that thing.

Joel Clermont (03:15):
Right.

Aaron Saray (03:15):
The difference here you're saying is, "Afterwards I asked them. 'Now that I've shown you the answer to your question, can I ask why are you doing this thing and maybe I have a different suggestion?'"

Joel Clermont (03:30):
Yeah, exactly. I think in this particular case, I even said, "I hate to be that guy, but why are you... " So I was acknowledging that I was not trying to be pushy or tell them they're doing something wrong, but I legitimately was trying to understand. I think at the end of it, we came to the consensus that, yeah, maybe that wasn't the best way to do it. But they were extenuating circumstances and that wasn't the battle they wanted to fight that day, You know what? Fair enough, now you know why this is happening and how it work around it.

Aaron Saray (04:03):
A lot of other reasons I've seen for things that I couldn't always figure out are, "Well, I was just always doing it that way," or. "Maybe I don't have time," or, "I think it might take too long to change what I'm doing just to help me do this thing so I can continue on to what I was trying to do."

Joel Clermont (04:22):
Yeah, that's a big piece of the context too. Is because if I'm asking this question because I'm stuck and I have something to do at the end of the day, that's probably not the frame of mind I want to be in to have that conversation about. Like, "Well, why are we doing it this way?" Sometimes you just have to get around it and move but then maybe come back to it. But, yeah, especially if you're a single developer on a team and the team does it that way, or maybe your boss told you to do it that way. There's all sorts of things that would prevent you from really taking that step back. I still think it's a good impulse though to question some of those things. The reason I feel this way is because there is a fundamental principle that I believe in. Which is, when I feel pain I want to be sensitive to that and try to figure out why. This is just one example of that scenario, somebody asking for help. But there's other scenarios where something happens. It's not what you want but are you addressing the root cause of the pain, versus just trying to work around it in the short term?

Aaron Saray (05:29):
Well, one of the things that I can say when we talk about that is because, you know, I've led multiple teams of developers. Is, I want to make sure that people aren't just solving every single pain either. Because some of these things we know they're an issue, but in the grand scheme of things we have to solve other problems so you can get your paycheck. I get it, it's not comfortable doing this thing but I need you to put up with it. So can you think of any different... or any ways that we could figure out the difference between, "Maybe we need to solve this pain," versus,"It's annoying but we have to keep doing it."?

Joel Clermont (06:11):
Well, my answer is going to be similar to the same sort of rule I used when figuring out when to automate something. It's like what's the investment of time to put into it versus what I'm going to get back? If it's a minor pain that happens every other month when some process happens. But it might take me a couple weeks to unravel that and solve it, It might not be worth it. Time is one factor. And maybe the other factor is, well, what is the actual pain? Is it just my discomfort as a developer? Or, could I blow away the production database if I don't do this one weird thing just right on my local machine? Something scary like that, that's more than just a personal pain, that's actually a business pain then. ASo that would really go up the list in terms of priorities to fix that in my view.

Aaron Saray (07:03):
Yeah, I'll kind of build on that. Is I believe that I cared about my developer as I was managing but their happiness is equal to a lot of other priorities. When two or three of those priorities stack up, their happiness of doing a job doesn't really matter. I need these other things done too. One of the things to keep in mind for those situations is if something is painful like you said it's, "What are the risks of this pain?" It's kind of what you were saying. But also these conversations, especially with a boss or a stakeholder, don't have to be yes or no, or one-sided. It can be a negotiation. Like, "I have this pain I'd like to fix through automation or rewriting, or whatever." And the answer maybe is no. So it's not out of the realm of the developer to say, "If I were to invest A, B and C resources in getting to these priorities that we need as a company, then can I address this pain the following week?" Having conversations like that, I think we don't always think about because we're so stuck in that current pain right now. The answer is going to be, "No, you can't do it because I committed to other stakeholders we need this thing." Just be careful, don't delete the database, you know?

Joel Clermont (08:29):
Just don't do that.

Aaron Saray (08:29):
Yeah.

Joel Clermont (08:30):
Well, you acknowledge something too. Which is, as a boss if even if your answer was going to be no to explain why. Not just be like, "No, I don't want to do that," right?

Aaron Saray (08:40):
Hmm (affirmative).

Joel Clermont (08:40):
Having a little empathy for the pain even if it's not a priority to solve it for the team at that moment. I think that as a developer, I would be happier hearing that from you than just, "No, we're not going to do that." That might be frustrating as a developer but the whole explanation makes a lot of sense.

Aaron Saray (08:57):
On the flip side too. I've seen some developers... I'm not sure why. And actually I'll be honest, I've done this. Where we have a painful scenario or situation and we just keep doing it. Like, "I always run these three commands when I start up for the day," or "I always reboot my computer at 12:00 because something is wrong and I just don't have time to figure it out." "I always restart Docker every four hours because I don't know why my machine suddenly spins up all of its cores."

Joel Clermont (09:29):
"I delete my vendor directory every time I compose or install."

Aaron Saray (09:33):
Why do you think we do that as developers?

Joel Clermont (09:37):
I think some of it is because we do get desensitized to it. And if it is a reliable workaround, it's easier to just do those two or three weird things a few times a da, than to dig into the internals of why something weird is happening that we don't fully understand.

Aaron Saray (09:53):
Sounds like click bait. "Do these two or three weird things every day and..."

Joel Clermont (09:57):
Well, it was funny. As you were talking about it, I could think of some specific things I myself am guilty of that I've done in the past. Where it almost becomes superstitious, like I have to do this and you don't have to do it anymore. But I think that's one reason. And maybe the other reason two is just you've tried to fix it once before and you couldn't figure it out and you don't want to go down a rabbit hole for another day or two. So you just live with it for the time being even if it is slightly annoying.

Aaron Saray (10:24):
Yeah, I think that's a good point too. There's something to be said though about three months from now. Whether you think about it or not you know a lot more than you did. And you've had time to think about it, your brain has solved it. So just because you couldn't figure it out three months ago doesn't mean that you can't figure it out now.

Joel Clermont (10:39):
Yeah, that's a good point.

Aaron Saray (10:46):
I was thinking the other day about things our parents used to tell us and then what our response now is as we get older and they become more senior, I guess we could say. And why those things don't necessarily translate. I just can't figure it out, but I can give you some examples of what I'm talking about to explain.

Joel Clermont (11:09):
Please.

Aaron Saray (11:09):
You remember when you're a kid and you'd see something on TV and they would always say, "Don't believe everything you see on TV."

Joel Clermont (11:18):
Okay.

Aaron Saray (11:18):
But now it's like, we have to tell them, "Don't believe everything you read on Facebook."

Joel Clermont (11:23):
Oh boy.

Aaron Saray (11:24):
It's a flip there. It's like they just discovered this thing, internet or someone's website. You have to explain, "No, anything can kind of happen there." It used to be a good idea, they would always tell us, "Work at a job for a long, long time, it's really good the longer you got a job." But nowadays, if you're at a job for too long, especially in tech, people are like, "Were you just not learning anything? You weren't growing? You're not advancing your career?" If you're like 20, 30 years back in the day versus now, I've been a programmer for 30 years at this one job. It's like, "You were just a paperweight by the time you hit 20 years in." Or, they told me, "Stop always asking "Why, why, why?'" As a toddler or a young child, like "Why? Why?"

Joel Clermont (12:10):
Because.

Aaron Saray (12:11):
But now, all I get from my mom and my dad are suggestions of documentaries I need to watch-

Joel Clermont (12:19):
Oh boy.

Aaron Saray (12:19):
... to figure out why.

Joel Clermont (12:22):
The tables have turned.

Aaron Saray (12:23):
Yeah, have you noticed this at all in your life?

Joel Clermont (12:26):
I haven't. I'm trying to think of a specific example of something my parents frequently said to me. To be honest, when you were talking about this, the place my mind went first was as I got older, realizing things I did that were mannerisms or things my parents did. It initially annoyed me. Like, "Ah, I'm doing that same thing that they did."

Aaron Saray (12:52):
Like what?

Joel Clermont (12:54):
I work out over at my dad's place, he's got all the weights in his basement so I'll go over there. The other day we were just both walking down the stairs at the same time and humming a little stupid tune that was nothing. And I'm like, "Oh my God, we're both doing that same thing." That happened last week in fact. I'm like, "Man, that I wonder how much other stuff like that I'm doing." But, yeah, I'll have to think more about the advice. Nothing's coming to mind on that one right now.

Aaron Saray (13:24):
I guess there's probably like you said mannerisms is a good one too. At some point in your life, you just start noticing that you have to always say, "Ah," after drinking something.

Joel Clermont (13:37):
Yeah.

Aaron Saray (13:37):
I don't remember when that started but that certainly wasn't all of my life. Now I just can't. It's like, "Ah." I could be thirsty or not thirsty, that's a sound that has to happen. The humming thing, not so much. But I have noticed myself do that. Sometimes having conversations with yourself, I think we kind of touched on that before. I think that's something that happens.

Joel Clermont (14:01):
Oh yeah.

Aaron Saray (14:01):
But yeah, and just the weird things. I remember my parents being like, "Oh, that guy's going way too fast down the street." Now, "Man, why is everyone going so fast on the street?"

Joel Clermont (14:13):
I know.

Aaron Saray (14:13):
Is what I think. Sometimes pain comes from having messy data or user input that we don't expect but validation can help.

Joel Clermont (14:25):
Then you might be interested in our new book, Mastering Laravel Validation Rules. Head over to our website to find out more at nocompromises.io/book.