undefined | Better HN

0 pointswithinboredom1y ago0 comments

Like 10-15 minutes ....

    git co master
    git co my-branch -- .
    git add -up . # select changes relevant to first pr
    git commit
    git reset HEAD --hard
    # and again...

0 comments

anonymoushn1y ago

The question was specifically about scenarios in which this approach wouldn't work, for example because your team doesn't want to approve PRs containing only dead code or because any subset of the change won't compile or won't preserve correct behavior without the others pieces.

dkdbejwi3831y ago

It helps to have the right tooling in place to ship "incomplete" work, e.g. feature flags so that you can ship a very light and not ready for end-users version of some feature, and continue to iterate on it in smaller PRs.

e.g. first pass adds a new screen and just dumps the output

second pass adds input fields and controls

next pass adds validation

then add animations

etc

mewpmewp21y ago

It sounds so good in theory, but in practice:

1. Frequently old code needs to be touched or refactored. Feature flag would not be enough.

2. Even feature flag itself can be a risky addition, and might affect existing customer usage.

Most of the time old code does need to be touched, there really aren't those perfect new isolated features, at least in my experience.

1 more reply

jappgar1y ago

IMO this is a terrible approach, and why I hate the way feature-flags are used nowadays.

For example, I'm not approving anything without input validation (frontend or backend). I have no idea if you're actually going to add validation later before the fflag is removed. "Trust me bro" doesn't work for me.

1 more reply

j / k navigate · click thread line to collapse

0 comments

anonymoushn1y ago

dkdbejwi3831y ago

e.g. first pass adds a new screen and just dumps the output

second pass adds input fields and controls

next pass adds validation

then add animations

etc

mewpmewp21y ago

It sounds so good in theory, but in practice:

1. Frequently old code needs to be touched or refactored. Feature flag would not be enough.

2. Even feature flag itself can be a risky addition, and might affect existing customer usage.

Most of the time old code does need to be touched, there really aren't those perfect new isolated features, at least in my experience.

1 more reply

jappgar1y ago

IMO this is a terrible approach, and why I hate the way feature-flags are used nowadays.

1 more reply

j / k navigate · click thread line to collapse