As a junior developer, I’m encouraged to spend 20% of my time at GDS building a project of my choice to support my learning needs - as long as it’s useful to the organisation.
As part of that, I decided to build a bot that would publish my team’s pull requests to our chat channel every morning, and highlight those pull requests that hadn’t been updated in over 2 working days.
Reviewing code needs two people
Reviewing code is important. At GOV.UK, any code a developer wants to deploy to the site is reviewed by their peers. This provides critical feedback and ensures the change improves the site, be it through better performance, additional features or higher quality code. Having that second pair of eyes really helps minimise bugs.
When a developer starts working on a user story, it’s their responsibility to ensure their code gets reviewed and to see it through to production. That review step can sometimes take a while. It can be hard finding the right person to review your pull request (also known as your code changes), as they need to have enough knowledge of the app you are working on to have the confidence to approve it. It’s also natural for a developer to start moving on to the next story while waiting for a review, and then their focus changes to the new task at hand. Stories that are left waiting for reviews mean users have to wait longer for the changes they need, and can create a bottleneck as we have limited deployment resources.
Creating a proactive review reminder
Currently, a stuffed seal acts as the reminder for a developer that code is still needing to be reviewed.
I thought there might be a more systematic way of proactively reminding developers about pull requests awaiting review. I called that app Seal, in reference to the previous method used.
The Seal app fetches a team’s pull requests from Github and publishes them every morning on Slack, our chat app of choice. Depending on how well the team is doing, the message is posted by a different seal:
-
- when there are recent pull requests to review, the Informative Seal lists them with a link to click through to them
-
- when no one updated a pull request for over 2 working days, the Angry Seal posts a message with a link to those PRs
-
- when there are no pull requests to review, the Seal of Approval posts a happy message that contains rainbows and other such celebratory emoticons
I launched Seal on three GOV.UK teams: core formats, custom and finding things. I wanted to make sure they found it useful by trying it with a small group and getting their feedback, which they did. They also gave me interesting ideas for additional features. These included ignoring pull requests that have “DO NOT MERGE” in the title, or showing whether pull requests had a thumbs up in the comments, which is one of the ways developers sign off on the code changes after review.
Open Sourcing means benefiting from the community
After the launch, I mentioned Seal as part of my Brighton Ruby talk on onboarding junior developers, which generated a few tweets. The next morning, I woke up to a great pull request to improve it, which came from a developer in Australia who had started using the app in his company. He refactored the code; pipeline refactoring, using the select or reject methods on an array instead of resorting to each followed by an ‘if’ statement, using an underscore to flag when an element of a Hash enumerator isn't used, and much more. He also kept contributing, adding features which I had mentioned in the ReadME were needed, such as getting the app to display how long ago a pull request was updated. He later posted Seal on Hacker News, which means more of the community are now engaged to help improve it on the GitHub repo.
Learning by doing
I learnt a lot by building Seal. I got much more comfortable with APIs, which was one of my learning goals - since GOV.UK has a micro services architecture, not a bad one to have - I used a yml config file for the first time, discovered how to stub an API gem and use the Heroku scheduler add-on. I also learnt from my mistakes; initially I tried to write the app in Rails, which made it very slow. On the wise advice of my mentor Paul Bowsher I ended up using a simple ruby script.
Do let me know if you have any thoughts or feedback on Seal - if you think it could be useful to your team, have a look at the ReadME instructions, it’s fairly straightforward. Pull requests welcome.
You can follow Tatiana on Twitter, sign up now for email updates from this blog or subscribe to the feed.
If this sounds like a good place to work, take a look at Working for GDS - we're usually in search of talented people to come and join the team.
