As we enter November, I’ve ticked over the five month mark at the Government Digital Service.
This feels as good a time as any to reflect on how I got here, and how my first almost-half-year has gone.
Serving the public
It took a while for the reality of what I’m working on to really sink in. The nature of the work in my previous job was very infrastructure-related - our users were the other development teams and the worst thing we could break would probably have been networking.
It still feels a bit unreal that my day-to-day is dealing with actual identities that belong to actual people who use them to do actual things, like self-assess for tax or claim from the government.
The “Keanu Reeves” moment was when we published the expression of interest for consuming passport data on GOV.UK - this was my team, and we’re doing stuff, and it’s on the actual government site. Aaaaaaa!
Behaving like a civil servant
One of the biggest new things when moving into the civil service was having to behave appropriately in situations where I could be perceived as a civil servant rather than a private individual.
For example, I need to ensure I’m adhering to the civil service code when I’m on Twitter - somewhere I spend a lot of my time.
I also spend a non-trivial amount of my spare time volunteering as part of Democracy Club, and being able to continue doing this is something I explicitly asked about during my interview process. I still need to be careful as a civil servant involved in electoral “stuff”, even though it is explicitly non-partisan.
Agile is Agile
The planning processes at GDS were striking in that they weren’t different at all. Facetiously, there’s a board with cards, that move from “Backlog”, to “Doing”, to “Done”.
We have retrospectives, we test-drive code, we plan in roughly week-long cadences.
I’ve particularly enjoyed working as a multidisciplinary team since we’ve been here. In one day I’ll be pairing with a technical writer on some documentation content, then I’ll work with a content designer, then I’ll pair with a developer on a bit of functionality.
Pull-Requests over Trunk-Based development
This was the hardest thing for me to get used to.
I don’t like pull requests - I think they’re a bad way of communicating design ideas, and code reviews get bogged down in the visuals and syntax rather than the semantics.
It requires a lot of discipline to make a pull-request easy to review.
- They should be small, whether lines of code or number of files changed. Large PRs are a drain to review.
- They should change a single thing, rather than bundle changes together. Large PRs are riskier.
- They should represent one “card” on the board, rather than a number of them. Multi-card PRs increase the cycle time.
If you follow these steps, you arrive at the unavoidable problem with code reviews - they require overhead and context-switching. This incentivises fewer, larger PRs which are more risky.
However, there’s a need for “two-eyes” to approve a change (who aren’t the original PR creator) and an audit trail to prove it. In light of this, using pull-requests with signed commits and using GitHub to enforce reviews before merge isn’t a bad way to enforce these requirements.
I will endeavour during my time here to extol the virtues of trunk-based development as much as possible, through ephemeral branches - in my ideal world a branch lasts for no longer than one day, which is the ideal size of a story.
Doing something useful
I joined GDS because I wanted to put my skills to use doing something that’s beneficial for the wider public, and I have to say that I’m enjoying it so far. I have a lot of excellent colleagues from whom I can learn a LOT of stuff. Bring on the future!
November is National Blog Posting Month, or NaBloPoMo. I’ll be endeavouring to write one blog post per day in the month of November 2019 - some short and sweet, others long and boring.