For software developers, a Pull Request (PR) is a foundational unit of work. Although there are quite a few software engineers that I’ve encountered that are more on the isolationist side, most are naturally collaborative. Asking for feedback is something that we do often. A PR is fundamentally a request for feedback upon a slice of code that the author would like to add to the shared code base. In order to enforce the quality of the project, other engineers will review the code that author wrote, provide suggestions for changes, and iteratively work to incorporate the code into the codebase. Once the code is of sufficient quality, the request is merged into the main codebase and the process begins anew.
The entire process is all predicated upon the review of the colleagues, without which the code cannot be merged and the author is stuck. I have spent a large amount of time in my career thus far not obtaining those reviews. Initially it was frustrating. I spent a long time writing the content of my PRs, even including a bit of narrative flair to distinguish it from all the other PRs. And yet… I barely obtained review weekly, and many of the reviews were approvals without comments. What a waste! Over time, I realized that this frustration was actually a blessing. The large amount of time it took to get reviews opened up a world of opportunity.
In the work-from-home world, waiting around for review has given me plenty of time to accomplish other tasks, whether that’s washing the dishes, cleaning the house, going for a jog, or finally responding to those mandatory security training emails. If getting a jump on those tasks sound appealing to you, read on. I’d like to share some tips for how to make your PRs unlikely to receive timely reviews, thus freeing you up to do all the housework you’ve been putting off.
Strategy One: Security Through Obfuscation
My absolute best strategy for making my PRs unreviewable is by simply making them complicated or obscure. Much like many developers bias towards self-documenting code, I bias towards self-documenting PRs. Keeping descriptions and informative tidbits minimal has done wonders for the frustration reviewers feel when looking at my PRs.
Choosing a Title
Always begin by titling your PR in the most concise way possible. This will often mean removing many of the details of the implementation of your PR. Don’t worry about that! Your code is self-documenting and a PR is just a collection of code. Your reviewers will figure it out.
By making your title brief, you’re ostensibly saving your reviewers valuable time. In reality, most of what you are accomplishing is removing initial context from the development you’ve done. Because context-setting is such an important part of understanding the development, eliminating it in the name of brevity allows you to throw your first curveball to your reviewers right out of the gate. By picking an obscure and unhelpful title, you may already thwart your busier colleagues. They’ll simply look at the title and put it in their mental backlog to do later. Mission accomplished! Unfortunately, more intrepid reviewers may not be deterred. Fortunately, there is much more you can do to break their spirits.
Writing a Description
If your fellow engineers make it past your poorly-written title, you can likely throw them off with an equally-as-unappealing PR description. This can come in two drastically different approaches. These approaches are only effective against certain adversaries so approach with caution. If you pick the wrong approach for your intended audience, you may end up in a disastrous situation where your colleague will feel empowered to review your code. This will result in feedback, changes, and ultimately will cut into your valuable household time.
The first approach is similar to ineffective titling. It is to simply be vague. The gold standard of PR vagueness can be achieved by titling and describing your PR with the same single word: update.
Now those adventurous reviewers that were not deterred by the vague title are once again faced with a similar obstacle. They have no choice but to venture into the code to work out what kind of mess you’ve made. This tactic is especially effective against detail-oriented developers who wish to receive large amounts of background info or context before jumping into reviewing the code. It is also effective against developers who are unfamiliar with the project. DO NOT use this against more experienced developers who have a good handle on the project. The more of an expert that someone is with the area you’re touching, the more comfortable they will feel jumping into the code. They are unlikely to be thwarted by your economy of language. If you find yourself facing these folks, employ the second tactic.
The second approach is the polar opposite to vagueness. Create an overly detailed and point-by-point decision tree, research background, and implementation steps for what your change is and does. In as verbose language as you think you can get away with, create a narrative that walks the reviewer through your experience creating this code. Bonus points for:
- Tangents into background research or “failed attempts” to solve the problem that ultimately did not end up in this PR
- Editorialization of design decisions
- Point-by-point description of the codepath
- Descriptions of expected and unexpected behaviors
- Pictures, charts, diagrams
- Acknowledgements section(s)
The verbosity of your narrative will serve several purposes. Initially, it will be off-putting simply due to its length.
By clearly spending the amount of time you have to create a polished document, you’ve either spent very little time on low quality code, are creating pristine code that is intimidating to review, or are expecting kudos on your excellent documentation. All of the above options are unappealing to a reviewer. They are especially unappealing to more senior or experienced developers. Unfortunately, more junior developers and those willing to put up with your nonsense will often appreciate your level of detail. Pick your audience and tactics carefully.
Strategy Two: Cast a Wide Net
If you’re in the fortunate position of being able to select your own code reviewers, you MUST take advantage of this fact. Because companies and organizations are intelligent, they have often implemented strategies around mandatory reviewers (both individuals and teams) as well as expectations about review timing. Using policies like CODEOWNERS allows admins to enforce review by the correct people and teams. This can be a huge obstacle for the devious developer. Fortunately, many companies do not implement such controls, instead relying upon the individual developer and teams to select reviewers. This is a huge win for you.
When selecting your reviewers, the number one way you can ensure that it takes as long as possible is by asking everyone you can possibly justify as being relevant to review your code. If you can, pull in your entire development team. The brilliance of this move is in its exploitation of the good impulses of the collaborative environment. In a world where teamwork is the norm, how can adding more people to the task result in a worse outcome? It is particularly this naive reaction that you can exploit to your advantage.
In my experience, the principle of Diffusion of Responsibility has often outweighed the teamwork impulse. It makes logical sense. Software developers are very busy and often have to juggle many different competing priorities. If assigned to a new task that falls somewhere on the stack of work to do, it is a completely understandable inclination to allow it to slip by the wayside if it is a shared task with many other engineers. After all, the rest of the team is smart and capable as well, so the task is in good hands. Fortunately for you, if enough of your coworkers think this way, there’s a good chance that no one will review it. Your lawn and garden will thank you!
Strategy Three: Write Effective Code for Unrelated Problems
A lot of fellow conspiratorially-minded developers will employ a naive tactic to attempt to avoid work: writing bad code that solves the problem at hand. Bad code is appealing because it can often be hard to understand and can give developers an “area of expertise” that they can become gatekeepers for. This allows them to argue for their contributions to the team and can translate into positions of prestige and financial rewards from non-technical stakeholders. It is a well-known tactic for other nefarious purposes, but does not apply here.
Unfortunately for you, your fellow engineers are smart and can spot bad code. Writing bad code will actually work against you because it gives your teammates incentives to review your code. If they’ve made it past your first few layers of defense, they will quickly sniff out your mistakes and add helpful review comments to your PR. This is the worst case scenario. Once a developer has left a comment on your PR, they are now invested. Worse than that, you’re now on the clock for responding to their comment and, due to your bad code, fixing the problems they’ve noticed. It is a disastrous situation.
Rather than writing bad code that solves the problem at hand, strive to write very good, well-tested, and effectively documented code that does not contain any obvious errors. In this way, it will be difficult to spot at a glance anything wrong with it upon initial review. In addition, adding effective documentation adds size to your PR, which is also beneficial as it increases the cognitive load required to review it. The main benefit that writing code to the wrong problem gives you is that it allows you to produce output that is won’t trigger alarms for experienced developers, and more junior developers are unlikely to venture into well written code with feedback. It is another perfect diffusion of responsibility designed to weasel your lazy butt out of having to respond to comments.
Countermeasures
Unfortunately, there are many effective strategies that companies and organizations can employ to thwart your devilish tactics. It begins from a cultural level and extends down to a process level. In my experience, you are most likely to get rapid and useful PR reviews in teams that are small and highly organized. In addition, if the PRs are themselves small and easily digestable, people will be more inclined to review them. A robust and well thought-out review process accompanied by well-defined roles, timelines, and expectations can assist in this.
Recall that if your goal is to write effective code and solve business problems, the above countermeasures will be golden for you. But if your goal is to get things done around your house, create code that doesn’t really solve problems, and overall take more time to yourself, you would be well advised to avoid the countermeasures like an F16 avoids a surface-to-air missile.
Conclusion
Every company that recruits software developers will advertise a work-life balance. Time to put it to the test! If you can execute the tactics above successfully while dodging the countermeasures, you should be well on your way to a clean home and a clear mind.