Do you actually own the code you ship?

Welcome to No Compromises. A peek into the mind of two old web devs who have seen some things. This is Joel.

And this is Aaron.

I've been struggling with something. I don't know if it's going to be self-serving compared to some of the stuff we do,

or if it's just a sign of the times. Or, if I'm being an old cranky man.

Yes.

Or all these different things. But as times going on here, and I hate to just focus on one particular technology.

I hate to always point at AI, because that's what everyone's saying right now. But it's just cultural when it comes to documentation

and getting code out the door and all these different things. But I'm feeling a little frustrated, or sadness, or wondering if everything's

falling apart when it comes to, do people even care about the why anymore? So, I'll sort of bundle this up into an idea.

Which is, let's just say we have a really tough problem in our code, and we want to solve it. And it's without a tool like Claude or Codex,

or something like that. But you have to do some research, you have to Google, you have to read some manuals.

You have to sort of figure out, like, did anyone have this problem before? How is it? Whatever.

And then when you sort of figure out maybe what the solution is, as you start to figure out the solution, you kind of have few choices too.

Copy and paste from Stack Overflow. If that were good to go, move on. Or, read the manual a little bit and sort of understand.

And I think before the world was probably split 50/50, right? People would just try to run out the door and just, "Whatever.

I'll copy and paste it from Stack Overflow." But there was a really good portion of people who also said, "Yeah, I'll look at a Stack Overflow.

But I've done that before. I know when I copy and paste it, it's not always a solution, but it pointed me in the right direction.

I can now look at the manual and understand a little bit more. And now I understand what the solution is for my problem."

So, I'm just making up numbers, but I kind of feel like that was 50/50 before, right? It was 50% of people did one way, and 50% of people sort of cared.

One or another. And then the level of depth that you went into finding out why something was different per programmer, but you sort of knew why.

I'm noticing that when I run into challenges now, myself, or as I'm watching other people on internet, things like that, use AI tooling.

They'll run into a problem, and then they'll say, which is correct, "Here is the problem I'm running into, AI tool. What is the solution?"

And it'll say, "Well, here's a solution," or, "here is the solution," or, "here is a solution." It'll work almost like copying and pasting from Stack Overflow.

But I'm feeling like people, that at least I've seen and even myself, you get sort of sucked into that high of just work. It's awesome.

AI sounds like intelligence, so it's probably right. And you don't even understand the why, and kind of move past.

And I think that's a bad thing, but I'm having a hard time articulating why.

Yeah. Would it be fair to label that maybe intellectual curiosity? Like, wanting to go a level deeper than just,

"This thing works, and I know it works," but like, "Do I know why it works? And do I know why this is even a good solution?"

Well, I would say it's about intellectual curiosity, but it's also about requirements.

For example, I don't... Let me bring it back. Way, way back in the day, you had to memorize stuff that was now in an encyclopedia.

So people before, you know 1900s, had to memorize things that were required for their profession.

And then, I'm sure encyclopedia has been around for a long time, but there was a sort of manual or place to these things.

And as you write stuff down, you have to less know about it, right? Because you can sort of reference it and it's explained there.

So, why would I have... is it intellectual curiosity if I don't need to know it now, because I know that any one time I can go and ask the AI tool

again to explain it to me later if I actually need to know it, you know? And so, that's why I'm saying it's not an intellectual curiosity, per se.

It's the difference of something being available to you always on demand, versus "I need to know that in order to formulate something else."

Yeah, I do think there's a couple of layers to it. And I would say, even pre-AI, you know, those Stack Overflow days,

I think even within a single developer, I'll just talk about myself. There were days where I felt more time pressure,

where I didn't give myself the luxury of like, "Oh, let's go explore this and read the manual." And like, other days where it's like,

"No, I want to figure this out. I have the time to do so," right? So, it's a little context-dependent too.

But I agree with your assessment that there's maybe just overall less of that now. And some of it is the tooling, and maybe some

of it is like the pace of, or the expectation of how fast you get stuff done, because this tooling is now available. Right?

So, like, if I just fart around for half a day to figure out some cool thing, there's no clear return on investment in the short term of that.

Like, I could have done... maybe I could have shipped another feature in that time frame, or fixed two bugs. You know what I'm saying?

So, I think there's maybe multiple pressures internally and within a team that might lead a person to not take the time or put forth the effort

to dig into something.

I think there's something about inspiration, too. When you're sort of figuring out something that you don't

necessarily need to know, you might learn other stuff.

Yes.

So, I know that I became a better programmer, a better PHP programmer, back in the day when I was writing a Symfony project

and I didn't really understand how to make Symphony forms way back in the day. So, I was reading the manual, and I was looking at the code,

and I started seeing other patterns of PHP that I hadn't used before. I'm like, "Wow, I think I like that. I think that can make its place into my own project."

But none of those patterns were actually required for me to see, for me to solve the problem.

Yeah.

You know, so I didn't need to see that code because I didn't actually use that code that I was looking at to solve my problem.

But I happened to see it because I didn't know what I was looking for.

Yeah. I mean, that's serendipity, right? It's like you bump into one thing, and you kind of accumulate all these little things.

And then sometimes they they form a hole that you wouldn't have known before to even look for it. So there's benefits to that.

I mean, should we discuss a concrete example? Because I know there was one in particular we were digging into a day or two ago,

and I think it's a good example of this. Which is, we were doing a code review, and I had a line of code, and it was an Eloquent query.

And I was basically trying to find jobs that should run, that didn't already run today. And so, it was like a simple date query,

where it's like, not equal today. But I also had orWhereNull, that column that we were tracking. And you're like, "Joel, why do you need that?

Like, wouldn't, not today also include null?" And I'm like, "Oh, yeah, I think you're right." Like, I couldn't...

I was a little annoyed at myself that I couldn't explain the reasoning, but I knew I needed it. And in this case, I had tests so I could show you.

Like, I deleted it, like my tests fail. I knew it was needed, but I couldn't fully articulate why. I probably knew it really well, maybe 5-10, years ago.

Because I've bumped into this before, but I couldn't explain it to you. So, that annoyed me and I had to go research it and then share

with you why that's the case. And I felt good about that, but it's getting a little more rare. So that's kind of an example, like, was it truly necessary?

Or, like, could we have just moved on and everything would have been fine?

Yeah, I think... Well, that's the determining question here is, are you responsible for the code that you ship too?

Yes.

And that's why I was asking you. Like, I don't care how you got the code, to where you got it. Like, why do you need to this right now?

I don't think you do. I was wrong, but I don't think you did. And it's like, then if you couldn't explain that, then do you even own your code?

Yeah, right. In this case, it was... I mean, let's even take AI out of the picture. Let's say I wrote that code,

and I wrote it first without WhereNull and it didn't do what I expected, because my tests proved that.

Then I added it and like, "Oh, now it does what I expect," but I still don't really know why I need that.

Like, that makes me a little uncomfortable. And maybe that's the old man in me, like you joked about at the beginning.

But I don't like that position, I need to know why. And once I understand it, then I do think it makes you a better programmer, too.

You know, because knowing the why behind something helps you see the actual problem you're solving and see how other things connect to it.

So, I was going to say, again, Joel, though, why? Why do I need to know that if I can, then reach over to my AI tool and be like,

"Here's my problem, solve it for me." I don't care how you do it, write the test. I wrote the test, it's not working. Code it.

Doesn't matter because the tests say it works. The user says it works, it doesn't matter. But you said something a little bit in there,

that is the key for me. Which is, it's not about even the curiosity, it's about knowing the domain to ask proper questions about.

Yes.

And so, AI tooling, or a fellow developer, more often than not... Well, AI tooling is going to give you one answer, unless you ask for multiple.

Fellow developer might give you one answer or two. But if you don't know the questions to even ask, you don't necessarily know how to get a

better response out of whatever resource you're using to interact with. So, when you say, "Why do I need to understand this?" It's because

that's the next level when you're looking at a solution and being like, "Okay, why did it do three if checks and null checks here?"

and all that kind of stuff. When you start to understand why, then you can ask questions in other parts of the application too.

Like, "Hey, in the past I've noticed that sometimes I've checked this for x, I do it for y. Why are we doing it here in this manner?"

And then you'll find sometimes the AI or the other developer be like, "Oh, yeah. You're right, that doesn't make sense.

I don't know why I told you do that." And it's not just AI, other developers do that. All of them, too.

Sure.

Like, "Oh, that's right. More context. Yeah, that was stupid. I shouldn't have told you to do it that way."

I've been writing bad code for a long time, so I can't just blame Claude for it.

But, yeah. And sometimes, I know with you and I, "Why is that there?" It's like, "Oh, I needed that and then I refactored this other thing.

And now I don't need that, and now I just forgot to remove it." So, you know what? The beauty of code review, it highlights this.

But just one thing to come back to. Because you talked about domain knowledge and it's not even necessarily like...

I think you meant this like the domain of programming, not necessarily the business domain of the application.

Because I've had sessions with Claude where it makes a very compelling argument for something, and I don't like it.

And if you don't know why to push back, or you don't have a detail to give it... Like, I've pushed back enough where it's like, "Oh yeah, you're right."

I mean, it always says, "You're right." But it genuinely... there was some piece of detail I wasn't giving it, or something bigger

in the architecture of the project I wasn't supplying. And once I was able to fill that in, then it led me to a better solution.

So I agree, it's not... maybe intellectual curiosity was too weak, that could be a driving force. But it does result in a better product,

and just like better craft. And being able to do a better job and feel good about it too, I think is valuable as well.

Yeah. I think if I were to say how we should look at this. Is, if you just want to pump stuff out the door just using AI,

you're a line cook at a restaurant, just doing stuff. If you are going to architect it and really spend time with it,

you're the head cook or sous chef. But if you actually have that intellectual curiosity where you come up with new dishes

and all that kind of stuff, you're the one who trains people. That's why we need to ask these questions and understand these stuff

so we can interact with our tooling and say, "Yeah, that is one solution. But here is details for other different solutions,

because I am the chef now."

You remember when you used to just be able to turn things off? Like, you just press the button or unplug it,

and then it was off. And I remember then it was like, Windows 95 or something like that, would be like, "Don't turn off your computer,

it's going to shut down. If you power it off, it may be corrupted," or whatever. I'm like, "That's where it just started, right?"

Now everything takes forever to even turn off. I don't understand it. I have this RODE podcaster device that connects multiple microphones

and all kinds of stuff. And when I turn it on, it takes it a while to load. Okay, I get it. There's a lot of computer stuff in there.

I don't know, buttons. Programmers suck, they take forever to program things. Got it. But when I press the power button to turn it off, at first says,

"Are you sure you want to turn it off?"

Right.

Okay, "Yeah." I mean, it's a physical button that you had to press pretty hard. I have to hold it in order to press.

Otherwise, I'll move the thing across my desk. So, "Yeah, I meant to turn it off."

Okay.

And when I press it, then it does this progress bar of like, dims the screen, and it's like, turning off.

It takes a good 20 seconds to move across there before it finally turns off. All it does is... what? Why? It's just microphone, right?

Yeah, I know. Like, as you're talking about this, there are things in my house I literally can't turn off.

Like, you can put it to sleep, right? You can suspend it, you can reboot it. We had the power out at our house, and I want to turn everything down.

But my TV? There was no way to turn it off. I had to put it into sleep mode and then unplug it. But, yeah, why are we so afraid of turning things off, Aaron?

I mean, I get the sleep mode because it's fast to turn on, or whatever. But that's not what this...

it's like, what is it that you could possibly be doing that you need all that time to turn off? Like, maybe I got it for Windows,

it was like writing files back, had memory and stuff, but I guess there's sound effects on this. But shouldn't that have been saved at

the time it was created? And if I change a setting, don't you save it then? Like, what are you doing?

Yeah.

It does turn off, though. You know you could use an AI tool like Claude to do a33 code review, but that's based off the average of knowledge.

And you need your project to be above average, to be the best.

I couldn't agree more. If you'd like us to help you review your code, head over to masteringlaravel.io/codereview.