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.

 

- Dragan Stepanović

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