It's taken a very different kind of team to build GOV.UK than the one most people picture when they think of web developers. Even within the tech industry, some stereotypes don't fit with the kind of people we've needed.
Unfortunately, there's a perceived template that developers need to fit when companies are looking for dev teams. People sometimes reckon that a CV needs to show that "the candidate"
- Must live and breathe code
- Spends all their spare time contributing to open source projects
- Can demonstrate expertise in one or two programming languages (and is happy to focus on those alone)
- Has a minimum of 3 years industry experience
- Feels comfortable referring to themselves as a 'rockstar', 'ninja', 'wizard' or in one of any number of elitist terms
The notion that having a team of 'rockstar' developers means you'll deliver quicker, better results is, in short, misguided. Working in a room with single minded, opinionated and difficult colleagues does not make a great team, or a better product; it makes a disaster.
Luckily at GDS, there isn't a single 'rockstar' in sight.
Collective intelligence > divas
What's been crucial to GDS so far is having a team of people with overlapping skillsets who are intelligent, fun to work with, and above all respectful.
I came to GDS from predominantly a Python background, with a few years of PHP. Yet during my time at GDS, I've worked on the core publishing platform in Ruby on Rails, helped sculpt the content API using the Sinatra framework, helped set up the initial use of our own font (which included a lot of Ops work), and I've tinkered with some of the frontend, including modifying some bits of Javascript.
I was able to work on all of those things because I wasn't doing it alone. Pair programming has been a fundamental linchpin of the way we work. It's a great way to learn on the job and learning things from people is more effective then spending hours alone reading dry documentation.
For example, we couldn't have gotten the new browse pages for GOV.UK released on time if we hadn't worked together. Myself and Jamie Cobbett (predominantly a backend developer) spent an hour brainstorming different approaches to processing the new categories, and how we'd update all the content to reflect the changes. From CSV upload to modifying the admin system, we weighed up the benefits and risks of each solution and chose the one that fitted the timescale.
We then discussed what we'd planned with the content designers, and made some additional tweaks to our approach to ensure it wasn't going to cause them too much pain. Powering the browse pages from this new data I then paired with James Weiner (predominantly design and frontend development) to make sure the implementation went as smoothly as possible.
Not only was working together a lot of fun, it meant that I could make changes to the backend quickly to adapt to the needs of the new design being built in the frontend. Each branch of our code was then submitted via a pull request in github, allowing other members of the team to review the code and give feedback. Fast, iterative and collaborative working ensured we delivered - hooray!
Test all the things
Testing has also been really important to how we code together. Writing tests not only helps to cut down on bugs, it helps you to break down a problem and not code yourself into a corner (we've all been there!). It also provides a clear indication of how you intended the code to work.
Regular code reviews, with friendly, respectful and constructive feedback ensures we can share each other's knowledge and prevents us from creating single silos of information.
Collaboration means we can continually deliver great code. It can't be about getting my idea coded, it's got to be about hitting the sweet spot and meeting a user's need. It also means we can use our collective intelligence to make judgements about what will work before we start writing code.
Users need us to develop things this way
How do user's needs relate to the way you build up a dev team? Well, a user doesn't want perfect code that'll never get delivered; they want services that work well, and they want them now. That means delivering code that people can return to and improve over time, rather than something that can only be edited by a single 'rockstar' developer.
That's why GDS relies on a team of developers that understand how to put users needs first, and will put aside their egos to do it.
2 comments
Comment by Tools over Content | Government Digital Service posted on
[...] The secret is to have a cross-functional (or cross-disciplinary) team. You need people who understand the needs, the users, the available tools and the creative possibilities. Those people need to be able to challenge one another and collectively refine the solution. If they can do that they will usually come up with something much better than any of them could have achieved alone. That’s been a big part of what we’ve been looking for when we’ve been hiring. [...]
Comment by Blogging for Queen and country « Matthew Sheret posted on
[...] post – on the day to day of being a developer at GDS – was probably a high point. Partly because there’s Lego in it. But also because (as [...]