Avoiding Pull-Requests and Code Reviews

the Readers Feedback and my Conclusion

In the last two articles, I've covered common problems with complex systems and workflows that can and will overwhelm companies over time. I got a response, especially for the part "Avoid Pull-Requests & Code-Reviews to become Game-Stoppers."

Responses came from Slack groups, LinkedIn, and conversations at the conferences. I realized how deeply this topic is rooted in every software company.

It's a controversial topic, and I understand that the expected standard is to play safe. Still, companies face problems while scaling their business or need help transitioning to more modern software development.

Today, in this article, I want to wrap up this topic and go to a conclusion, especially regarding the feedback I got in the last months.

Adobe Stock ‭418856391‬

The feedback

The typical response was:

"My team isn't ready to use these practices."

Is this the case? I have learned that humans have a built-in mechanism called resistance (I refer to the definition by Steven Pressfield, The War of Art, here). Insecurity and doubts often keep us from changing to a more trustful environment where people can learn and grow. With that kind of culture, the entire process becomes better by itself.

Feedback: Pull-Request + Code-Review, the holy grail of collaboration

By avoiding branches and removing code reviews as a hard requirement, readers see a significant risk of losing too much communication during development.

By removing code reviews as a hard requirement, I wanted to move the communication part more into the development process itself. Code Reviews, especially those several days or weeks later, are asynchronous, and people involved often miss the original context. Late code reviews like those aren't collaboration at all. The older these PRs get, the less relevant they get; they fade out of context.

Embracing developers, ops, and QA to communicate and consult each other during development will improve communications and knowledge exchange. In addition, it will grow and foster a collaborative culture where people are open and willing to help each other to keep the flow flowing.

This approach adds a lot to the maturity level of the entire team and keeps the awareness of the overall solution high. 

Recurring review meetings are a great option to round up and manifest all learnings. But all changes, understandings, and issues will be way more present, and the entire team can participate in all the problems during the week, not isolating those in 1:1 sessions. This type of meeting is more like a retrospective; the work is already done.

This approach is like a daily Hackathon: pull your desks together and start working on your problems. 🚀