Make a Daily Pull Request

The following philosophy has worked well for me in many projects, large and small:

This may seem controversial, but keep in mind I’m merely describing a method that works for me. I don’t want to push it on anyone! It probably doesn’t make sense in many contexts.

I’ve been a professional software developer for 23 years. I’ve worked at a mix of mature companies and startups, in open source and closed source, at the library level and at the application level. I’ve collaborated with others in fast-paced experimental codebases, as well as battle-hardened codebases that affect billions of users.

Over time I’ve found that the daily PR method works well for my own happiness and productivity. The benefits apply not only to my emotional well being – they also apply to the quality of the software that I craft, and even the speed with which I craft it!

This advice will immediately strike a lot of folks as wrong. I’m not at all suggesting it as a way of measuring productivity. I’m not saying you should “work harder” or change your work/life balance either! It’s not something to be implemented with stubborn tenacity either. The truth is, I mostly fail to actually implement this.

It’s more of an attitude.

The most obvious benefit to the daily PR method is that it forces you, at least on occasion, to implement the well-known guideline that pull requests should be small and focused.

Wait, what about complex feature work? Difficult bugs? Broadly scoped refactorings? These are all multi-day tasks! Some features take weeks to implement properly.

My claim is that it doesn’t matter. You can take some piece of that big thing you’re working on, and pull it out into it’s own thing. Even though it’s just prep work – maybe it’s something as simple as moving a file from folder A to folder B – you can still justify it to your code reviewers. Maybe they’ll reject it but that’s okay. It’s pretty small so your feelings won’t be hurt.

If it’s absolutely impossible to extricate some small portion of your work into an isolated change, then that’s probably a red flag; it would indicate that various components in your codebase are too tightly coupled to one another.

But, in this dire situation I would argue that you can still implement the method. Just take a break from your huge complex task, and do one of those small things that you’ve been wanting to do. Maybe a badly named class has been irking you in the back of your mind. Try renaming it, and see what your code reviewers will say! If they hate it, no biggie, just close your PR and move on. The stakes weren’t high, and you achieved your goal, which was to make a daily PR. The goal isn’t to submit a daily PR.

One of the most demoralizing things you can experience as a software developer is the feeling of being stuck. There are many things that can cause the stuck feeling: tricky bugs, obstinate code reviewers, impossibly complex and sloppy codebases. I’ve found this to be an elixir. It makes me feel like I’m always moving forward.

Addendum

Thanks for reading my first post on general software engineering. One of my old computer science professors would often utter Maximize cohesion, minimize coupling as though those words came from God. He would slowly explain how correctness and robustness are contradictory, and at the time I would shake my head impatiently. When I was a student I had already made my own shareware game that was published on a “200 Games” CD-ROM, and I felt I knew I was doing. These utterances from a supposed guru didn’t seem very useful. Over the decades, I’ve come to appreciate some of things he said.

In fact, I now feel there is a paucity of conversation around high level software engineering practices compared to decades past, when my colleagues would proudly quote from books like Fowler’s Refactoring or McConnell’s Code Complete.

(*) Yes, “pull request” is a GitHub term, but I’m referring to any batch of reviewable changes. In some projects this is always a single git commit. I believe it’s called a changeset in Mercurial. At Google and Pixar, we called them changelists (due to Perforce).