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):
PHP, like most languages, is steadily marching forward. New versions get released, old versions have support dropped. For example, PHP 7.4, that one was near and dear to my heart, and it's end of life, right? It's not even getting the security fixes anymore. So when you're working in a project, I hope you're updating to at least a supported version of PHP. But when you do that, you gain some other things, right? Let's say you went from 7.4 and maybe jumped all the way to 8.1. I say that like it's hard to do but anyways.
That's not just giving you support, it's giving you new language features and things that you can take advantage of. You and I were kind of talking about this and wanted to hash out: If you do that, if you update your project to 8.1, when do you start taking advantage of those new language features? Do you go through your whole app and update something or is it like as you touch a file? Or is it when you build something new? I'll kind of kick it off that way, Aaron, and I want to hear your take on it.

Aaron Saray (01:24):
Well, I think first of all, you have to kind of... the answer might depend on the type of team you're in.

Joel Clermont (01:30):
Okay.

Aaron Saray (01:30):
The other day I was... I don't know if I was listening to something or reading something, and they made a joke about engineering managers. And they were like, "Well, you know, engineering managers never want to upgrade software or processes. So you really have to try to convince them." And I'm like, "I don't know if that's the case." I think it's that there is a sort of goal of time and they're responsible for that in releasing product at the proper time. So upgrading stuff, unless you can definitely point that it's going to hit a due date, they're less likely to be interested in that. Point to bring that up is because it depends on what type of team you're in. If you're in a small team, two or three. Or if you're in a large team, eight, ten developers, multiple teams working on something, bosses and stuff. I think the answer is a little bit different for those two things.

Joel Clermont (02:20):
Yeah, fair point. You know, there might even be compliance and auditing and a separate operations team. Yeah. the bigger the team, the more you might have to think about something like this versus if you're a solo dev or somebody on a small team.

Aaron Saray (02:33):
Yeah. I think we can probably target the smaller either solo dev or small teams first. The question really is, let's just say you got a new set of features or language features and you're doing maybe some code in a class or whatever. How do you know that it's time to upgrade to those new sets of features? I think the first question I would ask is, does the new feature give me some sort of performance that's needed? Not just performance increase but performance increase that's needed. Security improvement or does it make the code, I want to say objectively easier to read, or just as simpler, right?

Joel Clermont (03:16):
Right.

Aaron Saray (03:16):
With this new language set, can I do the same thing where it's easy to understand and follow, and it doesn't require 10 lines? It requires one.

Joel Clermont (03:27):
Okay.

Aaron Saray (03:27):
I guess I kind of combined a bunch of stuff there. But I think the first one to focus on is, does it give me improvements performance that are needed? There's a difference there between whether the performance... I mean, because it could give you better performance, but do you actually need performance? Do you need the code to speed up in that area based off the amount of time it's going to take you to change the code and the amount of money or energy required for people to review the code changes you've made?

Joel Clermont (03:59):
Right. Yeah, it's a tradeoff. And I think performance is kind of an interesting one because, at least my experience has been the performance improvements are just from upgrading the language and less from, "Oh, now I'm using like readonly classes or something." There could be exceptions to that, but I think there's probably very few new language features that are purely about performance. It's usually about kind of the ergonomics of the code and trying to express something more clearly or concisely.

Aaron Saray (04:29):
I think you can look at stuff, like using generators for example.

Joel Clermont (04:33):
Sure, yeah.

Aaron Saray (04:33):
And you can find reasons why you might want to use that. There's a lot of legitimate reasons but you don't really need to apply a generator to get better performance on something that's only retrieving three things from a database that don't have heavy lifting involved.

Joel Clermont (04:49):
Right. That's a good one.

Aaron Saray (04:50):
So that's a good example of the... Technically, you probably could give me a little performance boost but it's not really necessary.

Joel Clermont (04:56):
No, it's negligible. Yeah, for sure. What about the readability one though? Because that one I see a lot. My first reaction is if it's new to the project, it might be new to the team, you know? Maybe not everybody on the team is keeping up with all the RFCs and the release notes and stuff. So if you introduce some feature, some different way of expressing a constructor that's shorter, and the first time the team sees it they might be, "What's that about?" right? Or, "Why is it only in these two files?"

Aaron Saray (05:31):
Well, I think that could be like PHP or it could be even like a Laravel upgrade. You can now do these things and you had to do it a different way before. I get what you're saying, I'm going to just say there's an opposite side of that too. Which is to say that it could be that you hired in new developers and they're not familiar with the old way of doing stuff that is all throughout your code.

Joel Clermont (05:53):
Yeah, it could work both ways.

Aaron Saray (05:53):
Because if they've never worked on Laravel 5, I don't even know what this means. You wouldn't do it that way in Laravel 9 or whatever. So I think it really depends on the specifics. It feels like a non-answer, but there's no real one answer. It's does it become more readable? Does it become easier to follow to the people that are the stakeholders that are going to be reading and following it?

Joel Clermont (06:16):
Yeah. I think part of why we're even discussing this is, we internally don't have a clear rule yet. We're still kind of figuring this out and like so many things you can kind of see it from both sides. What about the issue of consistency? Let's say, I'll pick a specific feature, like now in PHP 8.1 you can do constructor property promotion. Or maybe that was 8.0, I can't remember. But that's a pretty mechanical change, would you start just doing that in new files or files you edit? Or would you be like, "You know what, let's just go update all the constructors. It's a pretty mechanical low-risk change, let's just do it."?

Aaron Saray (06:56):
I guess, what does the change get you? That's the question. I might change them if I'm working in the constructor. Sometimes, like in the older way of doing, you could pass on a couple of parameters and you might then assign them to a property and then maybe the last line a constructor does a little bit of math or something and assigns it to another property. So if I have to change that math calculation, I might then change the variables that are getting set above it to constructor promotion. But if I don't have to touch that math, I'm not going to touch the rest of it because you have to have a number of tools set up on your project in order to do these mechanical changes. Because you say they're only mechanical changes, but I argue, "Whenever you have a person doing a thing, it adds mechanical changes plus bugs."

Joel Clermont (07:46):
It could, yeah.

Aaron Saray (07:46):
You know, if you talked about that the only way I would ever consider that is I have 95% unit test coverage, I have code standard tools scanning stuff, all that kind of things, so that when I make those changes I'm reasonably certain I didn't introduce a bug. If you're like a lot of the projects we see and you only have like 20 - 30% of coverage so far and you're working on it, don't do mechanical things. If the code is working, sorry, don't touch it. You're making a product for people and people can't put up with bugs.

Joel Clermont (08:14):
Yeah, there's different risk profiles. I mean, it's not just the size of the team, like we already talked about, but even kind of the maturity of the project and how big of a safety net do you have with test coverage? But yeah, like a tool, like Rector, you could just throw that at your code base with 15% test coverage and it might be fine. But, oh, I hear what you're saying is it also might not. But in so, is it worth it in that scenario? Probably not. You probably don't want to take a plunge on something that you're not going to rigorously do like regression testing across the whole, the code base, because of this "mechanical" change.

Aaron Saray (08:51):
Well then for a larger team too, let's just say you have a dev manager and they're responsible for your team's output and project and all that kind of stuff, and you do something like that and it breaks and releases a bug to production. Them trying to convey that information to the more non-technical stakeholders, you wonder why they get cranky with you or don't want you to do it. Because what are they supposed to say, "Oh, our devs did something, that actually gives us no customer value." Or, "Customer value I can't really explain and it broke something."

Joel Clermont (09:18):
"Why is there a bug in this feature? We didn't touch that, did we? That was done two years ago. Why did you break that?" That's how-

Aaron Saray (09:24):
Or, the cost of saying like, "Well, now we have to further test all this stuff with the QA team." You know?

Joel Clermont (09:30):
Yeah.

Aaron Saray (09:30):
I think the one I mentioned was the getting upgrades for security. So that one's almost more of a cut and try to rule. Which is, if you need to make upgrades for security, you should as soon as possible. There are a couple caveats to that but you really have to know what you're talking about, what you're doing. So I can give an example of, I have a friend that's working on a JavaScript project and she was updating it and npm keeps talking about their security holes and she can't seem to fix all of them with updates. So I said, "Well, look at what some of the ones are and are they high? Are they medium or low?"
She was down to like a couple low. So I said, "Well, look at one of those lows and see what it is." It turns out it was something with like, "Oh, webpack dev server when used with a third-party and this and this," It was a huge string of things that I knew she wasn't doing. I'm like, "Well, you don't technically have to fix that one. But again, that's a very slippery slope because you could at some point forget that you haven't fixed that issue."

Joel Clermont (10:38):
Sure.

Aaron Saray (10:38):
But, again, it's kind of weighing then. Like, how likely is this to affect me? When I say that, I don't mean how likely am I as a business to be picked on by hackers because the answer is a hundred percent.

Joel Clermont (10:52):
Yeah, it's automated most times.

Aaron Saray (10:54):
Yeah. It's how likely is the scenario for someone that set it up to take advantage of it?

Joel Clermont (10:59):
Yeah. If it's something like you just mentioned, only when you're running a webpack server and it's only in your local dev environment, that's different than something that can be publicly, remotely exploited.

Aaron Saray (11:11):
Right.

Joel Clermont (11:18):
I am a fan of listening to podcasts, not just making them. And I noticed something weird, it's a few months ago now. So some of the podcasts I listen to they have sponsor breaks, right? So not the hosts saying, "Oh, go sign up for whatever," but official commercials. I think of podcasts maybe come from NPR or some official business type thing where they have people that inject ads. And I don't mind that. You know, there's a skip button on my podcast player so I can jump right past them.
But the other day, a few months ago, I noticed a pattern where I started getting all the ads in Spanish and I can't, for the life of me, figure out why. Like, I'm sure there's some sort of surveillance capitalism going on and I clicked on something and now they think I speak Spanish. But first of all, Aaron, have you ever encountered that or do you have a theory on why that might be?

Aaron Saray (12:18):
Okay.

Joel Clermont (12:18):
You don't?

Aaron Saray (12:18):
How to phrase this without admitting to something illegal.

Joel Clermont (12:23):
Ooh. The plot thickens.

Aaron Saray (12:26):
Yeah. I have used a VPN to connect to Norway and then have googled things and then Google thought I was speaking their language. So I wonder if it's a similar thing. Were you using a VPN or anything like that?

Joel Clermont (12:43):
I wasn't.

Aaron Saray (12:45):
It's weird. You're saying you're not, but you're shaking your head yes on the video.

Joel Clermont (12:49):
I'm nodding along because I've thought about this already for a while and I hadn't considered that possibility that there was something actually like location based where it might think, "Oh," you know, maybe if I used a VPN in Argentina, it's like, "Oh, you must speak Spanish." Interesting. No, I don't have a VPN because this is on my phone. That's where I listen to podcast so I definitely don't. I haven't traveled abroad. But one other kind of cool side effect of this is NPR, for example, must have a lot fewer Spanish ads because I also noticed that while the ones I was getting were Spanish, there was like way less of them.
A normal ad break might have two or three and they might have like three of those breaks in a 30-minute podcast. And all of a sudden the podcast would say, "Oh, we're going to break." or whatever, and then they would just keep talking. I'm like, "I guess I didn't get any ads on that one." I was actually sort of enjoying it and it's gone away now so I kind of want to figure out how to get it back because it was a great hack for minimizing ads in my podcast feed.

Aaron Saray (13:59):
Joel asked me if there was one thing I'd want listeners to do, what advice I would give, what we want them to do. And I said, "I think to share the podcast."

Joel Clermont (13:59):
You don't want them to give us money? You're so noble, Aaron. Sure, if you want to share it, we would appreciate it. You can direct anybody to show.nocompromises.io and they can subscribe there.