If you're a GitHub user, you are well acquainted with the humble Pull Request. If you are asking yourself what on earth a Pull Request is, like I was when I
joined DVELP this week, fear not: When a developer wants feedback on some code they've created they create a Pull Request. This gives their team a chance to review and make comments before the current master version (branch) of the software is updated.
How on earth could what is essentially a technical code review have anything to do with shaping culture? As I've learned in the past couple days, quite a bit. But first, a little more context on how Pull Requests are used at DVELP.
Pull requests are used for two things: code changes and company methodology documents. Although not mandatory, almost all code and documentation goes through the same Pull Request. We have repositories for both our development projects and the publicly available DVELP Cookbook, our growing knowledge base for how we work.
Pull Request authors are encouraged to ask counterparts from across the organisation to review their work. Reviewers leave their comments for the author, changes are made and the request is reposted iteratively until the reviewer has no further comments. The code or document can then be merged.
This all sounded like a technical change management approach up front, until the team - and Bruce Johnson over at Fullstory (albeit indirectly via an excellent post!) - showed me the unexpected benefits.
Using Pull Requests for all of our code AND company methodology breaks down barriers between individuals and helps flatten hierarchies. Awesome new techniques can be admired, applauded and learned by others
and company methodology is shaped by the entire organisation.
As a remote-first company, we have to work extra hard on our teamwork and communication to keep DVELP humming. Pull Requests create opportunities for
personal interactions that wouldn't have come about had everyone worked alone.
By tapping people working on different projects for code reviews, everyone can keep up on what is going on outside their work bubble. The result is a culture where collaborating on difficult problems and asking for help is not only accepted, but actively encouraged.
Knowledge is shared in real time across projects, rather than being dumped somewhere to be dusted off for the occasional training session or, worst case, simply forgotten.
Double checking code means bugs are found much earlier in the development process, saving countless hours undoing collateral damage on production. Peer review in the form of a Pull Request gives everyone a role in quality assurance and promotes common styles and processes so that our work can be easily understood
by others. We love consistency and we love Pull Requests!
Knowing someone will need to make sense of your work heightens the need for good descriptions of what you are doing and why, making it easier to play detective down the line. The changes tracked via the Pull Request functionality on GitHub mean we can see exactly how documents have evolved over time. In a year we'll be able to dig through and see how our BHAG's have evolved. The Pull Request acts as a kind of historian in residence, from the smallest code change to the company constitution.
Coming from a more top-down corporate background, the empowering and democratising effect of the Pull Request is refreshing. Admittedly, it can also be a bit intimidating having your work laid bare for anyone to scrutinise. Embracing that has been an opportunity for personal growth and will help me be better in the long run. I'm excited to look back on the next year and see how far we've all come...