Start With Why

And it basically comes down to start with why.

And I think that's a phrase that's been used a lot in product circles.

And I can't remember where it really comes from.

There's probably a ton of books and things that people have written that talk about why.

I remember historically things like the five whys.

It's like keep asking why until you get to the real reason why something is important.

And the little tidbit that I want to weasel out today is on pull requests, you should start with the why.

And it should be a really clear answer straight off the bat.

And I'm going to tell you why.

What I'm seeing, we were going through some pull requests yesterday, but one in particular, Shane and I were working through this one pull request that he had opened.

I say he had opened it, but actually it wasn't him.

He guided the work.

But what was happening was the pull request didn't start with why it kind of started with what, and then it went into how, and it was a Claude or Codex or one of them that did it, you know, whatever he was using, which is fine.

Uh, but it, it betrayed a couple of things that I think are really important.

And it got me thinking back to, um, back to when I worked at a company called LV and I was managing a team and trying to help, uh, very experienced, very excellent developers to improve the way that they're working, especially as part of a team.

And one of the things that, uh, came up fairly, fairly regularly, I would say is, they would often create PRS either with no description that that would happen a lot.

It's okay.

Uh, that happens, especially when it's really obvious and small change.

No description can be okay.

Just to be clear.

But, um, When you're doing work in an area and you're sort of pre-AI, I guess, in some respects, we're expecting other human beings to review our work, which is still a post-AI activity, incidentally.

So we should still be doing that.

But when we're expecting another human being to review our work, We need to get to the point.

We need to make it as easy as possible for them to review this chunk, and it is a chunk of work that they need to figure out.

And why that's especially important is Now, in fact, what is even more important now is because those chunks just seem to be getting bigger.

And it basically comes down to start with why.

And I think that's a phrase that's been used a lot in product circles.

And I can't remember where it really comes from.

There's probably a ton of books and things that people have written that talk about why.

I remember historically things like the five whys.

It's like keep asking why until you get to the real reason why something is important.

And the little tidbit that I want to weasel out today is on pull requests, you should start with the why.

And it should be a really clear answer straight off the bat.

And I'm going to tell you why.

What I'm seeing, we were going through some pull requests yesterday, but one in particular, Shane and I were working through this one pull request that he had opened.

I say he had opened it, but actually it wasn't him.

He guided the work.

But what was happening was the pull request didn't start with why it kind of started with what, and then it went into how, and it was a Claude or Codex or one of them that did it, you know, whatever he was using, which is fine.

Uh, but it, it betrayed a couple of things that I think are really important.

And it got me thinking back to, um, back to when I worked at a company called LV and I was managing a team and trying to help, uh, very experienced, very excellent developers to improve the way that they're working, especially as part of a team.

And one of the things that, uh, came up fairly, fairly regularly, I would say is, they would often create PRS either with no description that that would happen a lot.

It's okay.

Uh, that happens, especially when it's really obvious and small change.

No description can be okay.

Just to be clear.

But, um, When you're doing work in an area and you're sort of pre-AI, I guess, in some respects, we're expecting other human beings to review our work, which is still a post-AI activity, incidentally.

So we should still be doing that.

But when we're expecting another human being to review our work, We need to get to the point.

We need to make it as easy as possible for them to review this chunk, and it is a chunk of work that they need to figure out.

And why that's especially important is Now, in fact, what is even more important now is because those chunks just seem to be getting bigger.