Notifications: A Story About Time and Space
Writing code as a single developer is one of the easier parts of being a programmer. There are no meetings to attend, no meta-work. Simply, pure unadulterated flow. One’s mind is free to build complex domain concepts, plucked from from the very depth of the Rube Goldberg machine that is their brain.
This part of programming is by far one of the main draws to the trade. However, it’s normally the smallest portion of an engineer’s time. A much larger part is reading other people’s code, namely in code reviews. Code reviews, are handy ways to allow other folks on the team to bare witness to the changing state of code that everyone is responsible for. These reviews often times manifest as requests from a centralized code repository. For us at Glossier, this is GitHub.
GitHub, while a wonderful product, has one Achilles heel: its gratuitous amount of notifications! Many folks use it to manage their side hustles, learn the newest OCaml inspired framework, and interact with open source maintainers. After a few open source contributions, and a day job rife with multiple repositories, the amount of notifications in one’s inbox would make any mortal human cry.
This leads to developers turning these off, enacting some kind of inbox rule to remove them automatically, or just ignoring them completely as they ‘select all and delete’ their way to inbox zero. However, these folks are missing out on the power of notifications and how they can supercharge async interactions between team members. The following are a small sampling of ways to get to that async nirvana by taming the torrent of notifications.
- Email Drops
Notifications, although loud, are a great way to keep on top of things in GitHub. This sole feature is likely why GitHub continues to keep them around. The trick to making them actionable is to get them out of your email and into a relevant inbox. For some folks this could be Omnifocus, TickTick, Things, or Todoist. Many of these task managers have a way to email TODOs straight into a Getting Things Done (or ‘GTD’) style ‘inbox.’ This could even be automated with rules in Apple Mail, Gmail or Fastmail.
Once these messages are out of an email inbox, it’s fairly easy from here to delete the notifications that aren’t important and move the ones that are into their corresponding folders or projects to be checked off later. If there is any tactic that one incorporates from all of these, this is by far the easiest. It has the lowest friction and is the most effective at never letting a specific pull request or code review drop by the wayside.
There are also a few other ways to accomplish this by removing the need of a productivity focused ‘TODO application’. Hey.com and Apple Mail’s VIP lists allow the whitelisting of certain email addresses to be more ‘top of inbox’ than say a new JavaScript newsletter. Having these notifications in a separate and important inbox can give people who like to have an email tab open all day, the same power as a task manager.
With these two small tweaks to categorizing notifications through email, there is no way a code review or pull request comment will slip through these filters!
- Notification’s Home Page
GitHub recently re-worked their entire notifications UI. This part of GitHub can be found at: https://github.com/notifications . This is a fairly unknown portion of GitHub’s offering due to it being really only accessible through a ‘bell icon’ on a user’s homepage. There isn’t even any text to the icon to inform users what it is meant for. Regardless, it itself is an inbox with a host of ways to slice and dice information from every repository that one follows.
GitHub themselves offers the user some predefined filters like ‘team mentioned’: for when someone mentions a team you are on (more about this later) or reviews requested! They even include handy ways to unsubscribe to pull requests that don’t interest you and ways to designate that you are done with the immediate notification but, would like to continue to be informed as the pull request changes and grows.
If email and task management isn’t your cup-of-tea, then the GitHub notifications UI and even the mobile UI for iOS is a very good substitute. There are even several browser extensions that will pipe the count of notifications from GitHub’s UI directly into an icon on your browser’s toolbar. While, perhaps a little annoying, it does allow a developer a way to stay on top of their notification load while ignoring their emails.
- Via Your Editor.
Notifications are likely the most common way that developers will find out that they have been asked to code review a peer’s code. If the web and email isn’t your thing (you are just hardcore like that), then perhaps within your IDE! That’s right, VSCode has a plugin for almost everything, including pull request notifications.
GitHub themselves manages an extension for working with your pull requests and issues. All without ever having to leave the comfort of VSCode. The extension brings everything that one can do on a pull request page (comment on the pull request, checkout code, add a review, request a review, etc) directly into the VSCode UI.
The extension segments pull requests in a repository and displays those that are assigned or created by the developer. It even displays a listing of reviews that are being waited on by the user. If anyone on the team utilized the request review function in GitHub’s UI, then these pull requests will be listed right within VSCode as well! No hunting through email, task management, or the browser. Since VSCode also has a Slack extension, someone who was requested as a code reviewer could synchronously ping the developer who wrote the code and start up a pairing session right then and there. All without leaving the cushiony confines of VSCode.
Not a huge VSCode user? No worries, GitHub also has you covered with their new CLI tool (which recently hit a 1.0 milestone). Through any terminal emulator, one can explore what repositories and specific pull requests include them as requested code reviewers.
The CLI even gives a developer a quick way to submit simple code reviews and clone branches that are affiliated with code reviews to their local machine.
These tactics are aimed at speeding up the time to code review for developers requesting a review, making sure these reviews stay top of mind for developers, and make the overall code review process a bit less cumbersome. Due to this, it allows teams to move at a much quicker pace, producing smaller pull requests, shipping more often and likely producing more maintainable code. Writing well and taming the stream of notifications are key to expediting and making the code review process, for both parties, a fun and empowering process.
