Starting at the Government Digital Service

Aside from the fact that the day-to-day work is interesting and challenging and the
people are fantastic, there are a few things that particularly stick out to me as
brilliant about GDS.

Second line support

This seems quite polarising for developers, but I love it. Each week a different
developer pairs with somebody from the operations team to spend a week improving
infrastructure and responding to any production alerts and issues. I finished my
first rotation on second line as part of the operations team about a month ago.

It’s such a great learning experience. You learn a load about the GOV.UK infrastructure,
as well as an awful lot about hosting, monitoring and deployment. It’s also a great way
to work with people outside your normal team on a short-term basis.

It’s all out in the open

Almost every line of code that technically can be is hosted at www.github.com/alphagov
(obviously the passwords, keys and other fun stuff is elsewhere). British taxes pay for the
lights to stay on, so it’s only right that the public can see what GDS is up to as much as
possible. As with everything on this site, that’s my opinion and it may or may not be shared
by GDS. You’d have to ask someone who’s allowed to speak on behalf of the Cabinet Office.

In my team (I work on the Performance Platform), we’re making data
about transactional services available for service managers (the people who run, for example,
the passport application process as part of HM Passport Office). But it’s a nice side effect
that the data is there, online, for everyone to see. The same thought process as for the code
applies: you’re paying for those transactions to take place. You should be able to see how
they’re performing.

Informally we work off the idea that for every page we build, you should be able to pull the
data out yourself. For the Licensing “Form submissions” graph,
the JSON’s available. It’s not documented (yet), but you can use developer
tools in the browser to view the AJAX requests.

Once more: all my opinion, possibly (but definitely not necessarily) shared by GDS. I might
turn up to work on Monday and find out it’s all changing.

Fixing broken windows

Jamesmentioned the broken windows theory
after I made a change to one of our internal apps recently. When I
wrote about a company’s tools in April, that theory was exactly what I
was getting at - I just didn’t know it had a name. If you make it easy to fix problems, as
GDS does by giving all staff the ability to push changes to almost every repository, the
state of the code and the community constantly improves. I love tinkering with little bits
and pieces that keep things running along smoothly, and internal apps are a great place to do that.

The Service Manual is another great example. Because it’s so easy to
fix typos and reword badly written sentences, I’ve
committed to it far more than I would have expected. And that’s
mostly because I can do it in a couple of minutes when I’m bored. And even better than that,
making the repository public means that a load of people from outside government have submitted fixes too.

GDS isn’t perfect by any means, but the good outweighs the not-so-good by an absolutely huge margin.