[eru]

> [...] but reality is there are a lot of smart devs who are "big thinker" types and struggle with incremental development and lots small PRs towards a bigger goal.

It doesn't really matter. You can start with a big change initially as a 'big thinker'. You just have to break it down afterwards.

I often have a bit of feature creep when working on a change, and add all kinds of incidental fixes I find along the way.

But afterwards, I use git's tooling to 'peel off' all those extra changes and stick them into their own PRs. That makes my main PR slim again. If the main thrust is still to big after that diet, I think about breaking it down into incremental changes that make sense for reviewers.

That process of breaking down is all about telling an understandable story to reviewers (both reviewers right now, and the poor folks who have to look at my commits in a few months to figure out when and where we introduced a bug, or why certain decisions were made. Those poor folks often include my future self.)

> I prefer incremental and used to roll my eyes at them, but it's just a different way of thinking and people/teams are diverse.

Some people produce incremental PRs naturally, and that's great for them. But for the 'big thinkers' it's a learnable skill to break their PRs into manageable chunks after the fact. No need to change their natural style.

[mewpmewp2]

> It doesn't really matter. You can start with a big change initially as a 'big thinker'. You just have to break it down afterwards.

But that's extremely difficult I think and requires some out of the box extreme creative thinking on how to split it up after the fact. And I would also think it doesn't help at all.

I usually like to imagine how I build the new feature in head. Then I vomit out whole bunch of code, but I feel like splitting it up is extremely difficult and it will just lose context of why I did something as I did.

E.g. if I split it in a way where I only show shared components, it won't be understandable why I made them shared in certain way because you won't see the actual other logic that uses them, so reviewers are kind of left to trust that these will be used in later PRs.

And I think the way you make things reusable is likely the most important part because there's a fine balance there, you don't want to make everything too reusable that is not intended to be reusable, but at the same time you want to make it as reusable as possible considering the future, and it will take a lot of thinking to understand future implications. A reviewer won't have understanding of the reasoning without going through the process themselves on how something might be reused.

There's a lot of disagreement as well on how DRY you exactly have to be. Some people follow the rule of write it 3 times then refactor to be reusable, some want to do it immediately, etc. And having shared components first no one knows what is going on.

And then if they were to criticise my shared logic, and they want me to change anything, which could even be a change they request because of misunderstanding I will have to change all the other logic down the other PRs as well.

[eru]

> But that's extremely difficult I think and requires some out of the box extreme creative thinking on how to split it up after the fact.

Thanks for the compliments, but I don't think I'm such a genius, and I manage this regularly. Splitting gets easier with practice.

It's the same as writing any technical document or a scientific paper: you have some idea, and then you decide how to split up the presentation so that your readers can make sense of it.

> E.g. if I split it in a way where I only show shared components, it won't be understandable why I made them shared in certain way because you won't see the actual other logic that uses them, so reviewers are kind of left to trust that these will be used in later PRs.

You can explain that with PR descriptions. Or you can have multiple clean-up commits in a single PR.

> A reviewer won't have understanding of the reasoning without going through the process themselves on how something might be reused.

You are allowed to tell them. That's what the PR description and code comments are for.

(It's better to put as much as is reasonable into code comments, because they are easier to see for future folks trying to understand the code. And, of course, even better is to make the code self-explanatory, where feasible. It's a hierarchy of descriptions.)

> And then if they were to criticise my shared logic, and they want me to change anything, which could even be a change they request because of misunderstanding I will have to change all the other logic down the other PRs as well.

That's always a problem, if you make a big change and only give it to review afterwards. No matter how you present that to the reviewer.

Yes, it is easier to write code that incorporates review feedback, if you can get review feedback early.

[jacobegold]

I like this take. The onus is on these devs to learn how to use available tools effectively to split up their changes.

There's a clear parallel here to the idea of a "genius" who isn't able to communicate their ideas effectively. Can they really be considered that smart if no one understands them?

[eru]

Yes, though it's is all about trade-offs. It works best, if your reviewers are also putting in some work.