an unpopular opinion: get rid of pull requests!
brought to you by eugene romero
who is this "eugene romero"?
professional breaker of things @ capgemini
15+ years doing this IT stuff
voted "most likely to quote The Simpsons at inappropriate times"
this talk is clickbait.
there is a fundamental problem with PRs.
raise your hand if...
i dislike stopping my work to review pull requests
i sometimes don't fully understand the code I am approving
seeing this makes my day better:
waiting on a PR to be approved has stopped me from deploying an urgent fix
i sometimes have to create PRs for tiny, repetitive changes
PR memes?
let's discuss some of the issues with pull requests.
pull requests can easily get way too big
pull requests can be hard to understand...
leading to LGTM syndrome aka "Stevie Wonder approvals"
pull requests can take a long time to be merged
pull requests can lead to responsibility shifting
how can we solve these issues?
get rid of PRs!
kidding.
but some things can be done better...
is a PR needed?
new functionality
potentially destructive changes
hard to reverse changes
new approach to things
if a PR is needed...
KEEP.
If a PR is big, [... ] it takes a long time to review, lots of back and forth with the author, dragging for many days/weeks [...]. It’s already too late and very difficult to course-correct [...]. Reviewers often tend to give up on the ability to steer the work, merely comment “LGTM”, and approve the PR, hoping to build in quality later. That, of course, rarely happens.
IT.
SMALL.
break into smallest possible parts
short-lived branches + feature gates
one or two days of work max
when are PRs not needed?
very simple or repetitive changes
changes on which there are no other experts
non destructive, easily reversed changes
question everything.
thank you!
@theEugeneRomero
https://damn.engineer
slides @ https://damn.engineer/slides