I just want to take a moment to apologize to my awesome colleagues who review my pull requests with amazing diligence, care, and kindness. I just need to say I appreciate you and your patience, for dealing with my particular brand of branch-pushing and PR-staging.
I’m a Lion
My preamble - I’m a Lion Chronotype, meaning that I start (early) with energy and lose steam over the course of the day. So my productivity looks pretty much like this:

I wake up with energy, new ideas, and focus. At the end of the day, I’m usually a little bit slower, less sharp. It’s pretty much a directly linear graph, with maybe a small bump from mid-morning caffeine.
Abusing drafts
Unfortunately, usually my PRs come as I’m wrapping up work for the day. I just get the urge to stop, commit, and then summarize where I left off, and often times a PR is a good way to do that.
These PRs usually come in ‘draft’ status, with a big WIP label slapped on them, and usually some indication in the description that things are in-flight. This doesn’t stop the prying yet helpful eyes from making their way to this new implicit proposal for changes.
The result — my PRs inevitably end up being of better quality.
Side effects
Boo hoo, right? The downside here is twofold.
Time “wasted”
I end up wasting my co-workers time, as they have to spend time reviewing a PR multiple times. They also inevitably spot issues or opportunities that require comments / feedback, some of which might not have been there by the time they had their next morning’s coffee.
Impostor mode activated
Pushing a PR is implicitly exposing yourself to critique and constructive (hopefully) criticism. Other devs have to scrutinize the code you’ve written and evaluate it. This is naturally a vulnerable place to be for any dev.
By pushing branches and opening drafts before they’re fully ready, I expose myself to feedback on code that may (likely) not be my best work. Not always great for the confidence.
Getting better
I think my personal goal in writing this post was just to acknowledge a questionable dev habit. I think there are probably better ways to handle this, but I also think there is some merit to how I manage my PRs.
For example, I could probably be a bit more thoughtful about consulting my own ‘definition of ready’ when opening a PR. If it’s after 5 and you’ve just finished running the build with your latest fix to the point where it ‘works’ — it is actually okay to take a step back and just make a quick commit and leave it at that. Let ‘morning AJ’ get another crack at it before the rest of the team.
On the flip side, don’t be the dev that holds back PRs until the last possible second. Especially if your team relies heavily on them to communicate changes. Polishing code to a perfect sheen only to learn that you’ve missed something structural is the opposite danger here.
Anyway, thanks again to the folks who review my PRs. The little extra effort does not go unnoticed, and I appreciate the grace 😇