I think I know the real reason we aren’t allowed to push our changes.. they don’t trust us. Doesn’t that bother you?
Heroine Maxine — In Unicorn Project, gets this epiphany while she was waiting for approval. She was breaking her to head to answer “Why the developers aren’t allowed to push to production?”. And then she realises the real reason is lack of trust. You can imagine how hard it is to work when you recognise that the management or the team don’t trust you.
I hope many of us are not working in a similar situation — restricted privileges because of lack of trust. But many times, I felt the main reason behind feature branches are lack of trust. I understand the Open Source world —article the Cathedral and the Bazaar is appropriate here.
At Good Karma, we hire freelancers or consultants at times to help us move faster. Whenever we hire someone new, two things surprise them. Anyone can commit to master. And the pipeline pushes every successful build to production.
I do review the code. It is always better to have multiple eyes for the code. The pair programming does this beautifully with the roles — Driver and Navigator. A review is also good because I have a better handle on the codebase and the preferred patterns.
But I am very much comfortable reviewing the code after the push. We hired people for delivering value faster to our customers. And delaying delivery for code review never made much sense to me.
I hear deployments delayed due to PRs review even from teams with 2–3 programmers. Do two programmers working together for years need review before deployments? Using code review as a gated process for deployment — is that worth?
We should ask the question — why do we need PRs? Is it for improving the code together? If yes, can we make those improvements after we push the changes?
Or will the team member find one day — similar to Maxine’s epiphany — that they are not trusted. That doesn’t seem like a good situation.