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):
I've seen a common pattern when I help other developers or kind of see questions going back and forth in Slack. A lot of times, a developer will feel stuck or frustrated and it's not so much the problem they're working on, but what I observe is it's maybe a lack of how the thing actually works under the hood, so to speak. It can cause all sorts of frustration. They're chasing down things that aren't related to the problem, they don't even necessarily know the right term to search on to address what they're facing. An approach I use, and I know this isn't something I invented or unique to me, but it's just to have this idea of a clear mental model of how something works. It gives me a huge benefit approaching it, especially when I run into a problem. Is that an approach you use at all, Aaron?

Aaron Saray (01:12):
When you say mental model, what does that mean?

Joel Clermont (01:15):
Okay. For me, a mental model is not a necessarily overly technical explanation of how something works, but it's just kind of a clear high-level picture of like, "Well, what are the pieces? How do they fit together?" And some level of technical interaction if we're talking about code. So, just having a clear idea of how this thing was built and is designed to be used and the ways it can fail, that mental model, even though it's not super technical, it's a very high-level, serves me well. Like, is that-

Aaron Saray (01:54):
Okay. That makes sense.

Joel Clermont (01:54):
... type of mental model you think about? Or do you think of it a different way?

Aaron Saray (01:58):
No, I think about it same way. I just wasn't sure, everyone has different method or words that they use for their methodologies.

Joel Clermont (02:05):
So I need a mental model to describe the mental model to you?

Aaron Saray (02:08):
Yeah, I call it my sailboat.

Joel Clermont (02:11):
Can you elaborate on that?

Aaron Saray (02:12):
Nope.

Joel Clermont (02:14):
Okay. Just a random non-sequitur. Okay. Let me give an example, let's make it a little more concrete. Git version control, it's one of these things that I would venture to say most developers interact with on a daily basis and we have some level of familiarity with how it works. We have mental models most likely about, like what does it mean to stage something versus commit it, to push it, and so forth. But there's other things that are a little more of a black box. For example, I see some people get very confused on what is a rebase versus a merge? And the point of me bringing up this example is not to give a Git lesson, but as an illustration of where a mental model can really help you with this idea of rebase versus merge.
The basic mental model I have is where I have two branches and I want them to become one happy branch together. So I have two choices on how to do that. I could rebase or I could merge. Let me just throw one other thing out there. I've heard some people say, "Never rebase," and that becomes gospel and maybe they got burned. But here again, without understanding what rebase is and why you might use it and what it's actually doing, then you just become scared of this thing. While it may not be the thing your team does a lot, not having a clear mental model of what it is can limit you and cause you to get confused if you ever run into a situation where you do need it.

Aaron Saray (03:54):
One of the things that I'm very passionate about is saying that, "You're responsible for understanding your mental model." Now, when you talk about Git rebase versus merge, I think it's almost criminal as developers if you choose one or the other and you don't necessarily understand why you've chosen that. I think one thing, obviously like you said, not a Git lesson here, but maybe you can describe a little bit on how you might formulate a mental model around, how do I choose merge versus how do I choose rebase?

Joel Clermont (04:28):
Okay. Git is actually a really nice thing to form a mental model around because it can actually be drawn out on paper with lines and graphs and nodes and things like that. But since we're in a audio medium, I won't have that luxury. But the way I think of it is, and I'll back up slightly just to kind of give a concrete scenario of when I might make a choice. Let's say I'm working in a feature branch and I've been working on this feature branch much longer than I would like, maybe it's been days, maybe it's been over a week. And meanwhile the team is cranking away doing things in the main branch. I want to bring that work in. Now I have a choice, I could simply merge that work into my branch or I could rebase it.
And here, again, people have very strong opinions on why they choose one versus the other. But when I think about it, the mental model is, "Well, where do I want my teammates work to fit?" Do I want it to be as if my work started after their work and I'm putting my work on top of what their current work is? Or, do I just want to merge it in and have a complete picture so when it is time to return my feature branch to them, it's not horribly out of date? The mental model for me is sort of like, "Where does my work go?" Does it go kind of in the middle of everything that everyone else has been doing or does it get done at the end?

Aaron Saray (05:57):
So you're saying that there's more than just the mechanics of how this works? There's the rationale of what I want the end result to be?

Joel Clermont (06:08):
Yes.

Aaron Saray (06:09):
Not, if it's difficult or if it's easier or harder to do a particular type of technical process, but, "What do I really want as an outcome?"

Joel Clermont (06:20):
Yeah, that's a good way of addressing it. I know developers like rules, like, "We always do this," but here's an example where there's not a clear rule that you can always follow. Since our audience is maybe people familiar with Laravel and PHP, I will give a PHP specific example. So let's say I've installed a package in my feature branch, which has modified my composer .JSON, my composer .Lockfile, while my teammates have also installed a package. Merging that is a little bit of a nightmare. Like, if I was really to try to do that there's no clear way to merge the Lockfile, right? I'd have to merge maybe the JSON file and then do a reinstall, and be careful to not update things that I didn't intend to. But here's an example where I might reach for rebase. Because I play my stuff to the end, I basically blow away my package commit.
But I can just install it again and it's at the end and there's no harm done, no conflicts, no inadvertent packages updated. Maybe other people have different ways of dealing with that situation but that's the situation where my mental model says like, "Oh, this is going to be a lot less frustrating if I do it as rebase versus a merge." Other cases, I might just merge it in. Doesn't really matter, I just want to get their work merged in with mine.

Aaron Saray (07:36):
I want to make sure that we don't go too far down the rabbit hole on Git. What are some other examples of mental models and how you might apply them to your programming career?

Joel Clermont (07:48):
I was helping a developer friend out on a Slack channel the other day, and there was some frustration about something not working the way it was expected. And what we traced it back to was part of the work he was expecting to be done was being done in a queue. For reasons we won't go into, local development was actually using a real queue from Redis and not the sync queue that we might normally want to use. It's a common mistake, in fact I was able to help him because I had made that similar mistake earlier in the week, so I could help him get to a solution. But I've seen things like this where maybe we push something to production and then after the deploy happened, we changed something in the environment and then forgot to restart the queue worker.
Or it goes the other direction, where out of superstition we always restart the queue worker when something doesn't happen. For me, to boil it down to a concrete example, is, well, how does the environment and the configuration relate to a queue worker and the need to restart it? Like, without understanding what's happening there, you can just kind of operate out of superstition or habit without really knowing what's happening.

Aaron Saray (09:00):
What it sounds like you're saying is, part of the mental model processes is continuing to define what things mean and why they happen, not just what is the step I take to get from A to B. Because if I'm listening to what you said in the Git example, yeah, we can do these mechanically, but what is it that we want to have happen? Same thing with this is, when we push something to a queue and then we want to maybe... Why would we ever restart a queue, I guess is the question. And to be able to understand that you can kind of shape a model better and understand why you might make decision one versus decision two.

Joel Clermont (09:43):
Yeah, it definitely helps guide decisions. I think it also just really helps avoid frustration. Like, we've all had that situation where something isn't working and we waste hours on something that really wasn't related. So that's kind of where these mental models help out. I can rule out a whole class of things to test and try to debug if I know what's actually happening and I have a clear picture of that in my mind.

Aaron Saray (10:10):
And we're lucky really because we're working in open-source with Laravel that we can actually look at what's happening and follow it through. There's a lot of really interesting architectural choices inside of Laravel and when you work with them, they shouldn't be a complete black box. You can understand when you get started, "Maybe this is how I get from step A to step B." But as you work through it, like you said, "Understanding a little bit more will flesh out that whole mental model for you of how this process works." So you can make better decisions, not only that one that worked that one time.

Joel Clermont (10:46):
Yeah. That's a good point about the source being available because sometimes that's how I will form a mental model. Is like I won't really know what's going on and the documentation generally explains how things work, but not necessarily why or how things fit together. So I'll dive into the source code, figure it out, kind of sketch it out, and then that's where these mental models come from. Is understanding it at the deep level so that I can kind of pull it back and have a higher level version in my mind, to aid me day-to-day. Because I'm not going to remember these specific implementation details of all aspects of the Laravel framework. But if I just have the big picture in mind then I kind of know how things work together. That's really what I need for my day-to-day work.

Aaron Saray (11:35):
I'll tell you what I struggle with the most more than anything else in this entire world. It's because I can't relate to it, I don't know what to say and it always comes off weird, and I think you can help me.

Joel Clermont (11:47):
Okay.

Aaron Saray (11:47):
Is when someone shows me a picture of their baby-

Joel Clermont (11:53):
Oh boy.

Aaron Saray (11:54):
What am I supposed to say? So far I've been saying, "Nice baby." Which doesn't necessarily get the right results. What do you say when you see a picture of a baby and you're not... what are you supposed to do?

Joel Clermont (12:08):
I am not the right person to ask about this despite having many of my own babies, because I really don't... Here's what I don't like. I don't go on Instagram a lot but when I do it's like too many pictures of people's kids. And I'm going to throw this out there, and their pets. You know what, could we throw pets into the same boat with this? Or, do you know how to respond if somebody who says, "Hey, look at my cat?"

Aaron Saray (12:31):
Well, no, because it's not so weird. Like, if someone says, "Look at my dog." Then I'm like, "Oh, that's a nice dog."

Joel Clermont (12:38):
Okay. "That's a good boy."

Aaron Saray (12:39):
Yeah, that makes sense.

Joel Clermont (12:41):
Wait a second.

Aaron Saray (12:41):
When they say, "Oh, look at my baby." "Oh, that's a nice baby."

Joel Clermont (12:46):
No, I figured it out.

Aaron Saray (12:47):
"What? What are you a robot?"

Joel Clermont (12:49):
Aaron, same answer you'd say if they showed you a cute dog. "That's a good boy." When they say, "Look at my baby." "Oh, what a good boy."

Aaron Saray (12:57):
I don't think that's done at all in the real world.

Joel Clermont (13:00):
No. Would that be more creepy?

Aaron Saray (13:02):
Yeah. And then what if it's ugly?

Joel Clermont (13:05):
Well, it always is. I mean, let's be honest.

Aaron Saray (13:08):
Yeah. Like, "Oh, look at my beautiful baby." "That is a baby."

Joel Clermont (13:14):
No, I'll qualify that. But if it's like a brand new baby, right? Like, this baby was just born in the last few hours, most of them look kind of weird. Like, oh my-

Aaron Saray (13:23):
Yeah. They all look like Walter Matthau.

Joel Clermont (13:26):
Great. Yeah, you could think of a celebrity that their baby looks like. You know what? "Wow. That baby really looks a lot like Cher."

Aaron Saray (13:34):
"Oh, that baby looks a lot like Shrek."

Joel Clermont (13:37):
Shrek would be even better, yeah. No, I guess it would depend on how well you know this person and their sense of humor. But generally I think a polite acknowledgement is probably the right answer for that situation.

Aaron Saray (13:52):
I know that sounds like you answered, but I feel like you didn't. Because here is the problem. You know, how I speak and how my cadence is. So pretend you showed me a picture of your baby, what are the words I'm supposed to say? I'm a programmer, spell it out for me.

Joel Clermont (14:11):
Step one, line 10, go to 20. There's no one true answer here, Aaron. Just don't be creepy, that's my advice.

Aaron Saray (14:20):
That's what I'm asking for help? Can I say, "That's a nice baby," and people are like, "Why you got to make it weird?" I'm like, "What am I-

Joel Clermont (14:28):
What was the tone of voice when you said, "Ooh, that's a nice baby." Or is it just a, "Oh, that's a nice baby."?

Aaron Saray (14:33):
I say that... I don't know if I have a tone. I just said, "That's a nice baby."

Joel Clermont (14:38):
All right.

Aaron Saray (14:39):
They're like, "Oh, look at my baby." I'm like, "Nice baby." Like, "That's weird." Like, "Well, what am I supposed to say?" No one can seem to answer this, everyone tells me I'm weird, but then they won't help me.

Joel Clermont (14:49):
Yeah. No, you have to figure this out on your own.

Aaron Saray (14:52):
Oh, you're drowning but I'm not going to throw you a life jacket.

Joel Clermont (14:55):
Have some other odd picture to share back with them and then it'll be like nobody knows what to say to the other person and the conversation will just move on to another topic.

Aaron Saray (15:06):
Okay, I'm following your advice. So you pull out picture of baby and you're like, "Oh, look at my baby." And I then silently open up my phone and show him a picture of a dog and I say nothing?

Joel Clermont (15:18):
No, no. You say, "Oh, nice baby. Look at my dog." You've immediately shifted the burden onto them. They don't have time to react to the potential weirdness of "Nice baby," because now they're trying to think, "Well, what do I say about his dog?" And everybody knows what to say about a dog. Problem solved.

Aaron Saray (15:33):
Oh, and then they'll say, "Oh, nice dog." And I'll be like, "Yeah." It wasn't weird.

Joel Clermont (15:37):
Yeah, problem solved.

Aaron Saray (15:38):
Well, thanks for your help, Joel.

Joel Clermont (15:39):
You're welcome.

Aaron Saray (15:42):
Now, instead of just ignoring that one block of code, hoping it works and praying for the best, maybe it's time to form a mental model.

Joel Clermont (15:49):
We can help. Contact us for a free consultation on our website nocompromises.io.