The Pull Request Culture
How programmers has become artists, failure is embraced and contributions should no longer be measured by the hour.
In Seth Godin’s latest book, The Icarus Deception, he challenges us to become artists, disobey the fear and ship!
Artists are not only painters, musicians, filmmakers and writers, but increasingly also entrepreneurs, programmers and architects.
“An artists is someone who uses bravery, insight, creativity, and boldness to challenge the status quo. And an artist takes it (all of it, the work, the process, the feedback from those we seek to connect with) personally” — From the back cover of The Icarus Deception
These are my thoughts on what I selfishly call ‘The Pull Request Culture’, a view of how programming can be viewed as art (if carried out with passion), how it requires failure to teach and how it replaces time with value.
Programming demands art
The pull request culture demands art. It requires you to autonomously seek out inspiration, execute and deliver your bold, brave and creative ideas.
It is the programmer’s chance to say ‘this might not work’, and it demands approval or rejection both of which moves you and the project forward.
The technical form of a pull request is not what’s essential. It is the way it embraces, or actually requires, connections to be made and collaboration to take place.
Art is required in the connection economy. Companies like GitHub and Valve are built upon it — without art, they were nowhere.
It would be impossible to run a large, distributed team using spreadsheets, planning and deadlines — independence and responsibility and freedom is what inspires us to create.
A culture that embraces art, is what we need.
Embrace failure
“Nobody has ever been fired at Valve for making a mistake.
It wouldn’t make sense for us to operate that way. Providing
the freedom to fail is an important trait of the company—
we couldn’t expect so much of individuals if we also penalized people for errors. Even expensive mistakes, or ones
which result in a very public failure, are genuinely looked at
as opportunities to learn. We can always repair the mistake
or make up for it.”
— From the Valve Employee Handbook (page 20)
The notion of ‘take what I made’ vs. follow the spec and deliver on time opens up all sorts of organisations to the firehose of ideas and responsibility that otherwise would be hidden and burned inside the people who forever chose to comply and obey the ‘rules’.
But it’s not for those seeking to reduce risk, and make safe bets. Valve embraces failure, because it moves them forward. It’s a relief to cut off a path, an idea or a concept as not feasible — as long as it has been proved to be so.
Screwing up is one of the best ways to learn. You get immediate feedback, it’s always crystal clear when something goes wrong and it should be shared with co-workers, a community or anyone who cares to listen.
How many blog posts about something not working, and how to fix it have you not read?
You can never deliver the best possible result, without failing, or being wrong a couple of times. Fail fast, and fail often, and you’ll only get better and faster.
As GitHub puts it:
A Pull Request doesn’t have to be merged
Pull Requests are easy to make and a great way to get feedback and track progress on a branch. But some ideas don’t make it. It’s okay to close a Pull Request without merging; we do it all the time.
— How we use Pull Requests to build GitHub
Contributions provide value, not time
When you enable yourself to judge a contribution, you’ll automatically think ‘how much value does this provide’. This has nothing to do with hours, lines of code or commit count.
Measuring productivity is practically impossible, so why even try?
I’m not saying the number of accepted pull requests should be the metric to judge programmers against, I’m merely arguing that the ability to see the actual changes, testing and delivering continuously is a way better method for visualising the output of individual people, or teams.
The loop of programming, integrating, testing and delivering code is becoming shorter and shorter. Continuous Integration has been complemented by Continuous Delivery, which makes it possible to ‘cherry-pick’ features for deployment based on value, quality and need, instead of planning for weeks, programming for months and failing at the ever growing big bang integrations that follow the weeks of ‘crunch time’ and all-nighters.
As MixPanel puts it:
We always ship code the moment it is better than what is live on our site – no matter what.
— From MixPanel’s jobs site
My experience
When you set people free, let them do what they want, an let them fail in the spirit of ‘this might not work’ — that’s where remarkable hides, and it has been lying around forever, waiting to be unlocked.
