DevOps and other issues by Yurii Rochniak (@grem1in) - SRE @ Preply && Maksym Vlasov (@MaxymVlasov) - Engineer @ Star. Opinions on our own.
We do not post ads including event announcements. Please, do not bother us with such requests!
Post #2886
1.82K
Do you trust your colleagues?
An article Stop Using Pull Requests from the same author as the previous article in the channel, argues that they may be not ideal.
The core argument is that pull requests were originally created for low trust open source environment, in which contributors may have never seen each other, and often do not know each other at all. Development teams in the corporate world operate on another set of assumptions.
It's interesting that this article also builds up on the ideas of Thierry de Pauw. IIRC, I already posted his talk "Non blocking Pull Requests" on the channel, but in any case, I can do it again.
The main premise of the article is that you need to adopt T*D practices: test-driven development, trunk-based development, and another made-up T*D practice that basically means pair-programming.
From my experience I can say, that eliminating pull requests is probably not something you can do in a short run, but measuring the waiting time before PRs are merged is a good practice. Another good practice is to team-up on tasks or projects. So, basically pair-programming, but several people can still work on different tasks within a project, share context on this project, and thus be able to review each other's work almost immediately without much context switching.
T*D practices are also nice. Honestly, I have an impression that the majority of people are using the trunk-based merge model and continuous deployment these days. Also, it's interesting how AI can facilitate test-driven development: spec (by human) => test (by a machine) => tests review (by humans) => coding (by a machine).
#culture #programming
Substack Stop Using Pull Requests Your team’s code review process is probably an expensive illusion of quality. Here’s what the evidence says, and what to do instead. An article Stop Using Pull Requests from the same author as the previous article in the channel, argues that they may be not ideal.
The core argument is that pull requests were originally created for low trust open source environment, in which contributors may have never seen each other, and often do not know each other at all. Development teams in the corporate world operate on another set of assumptions.
It's interesting that this article also builds up on the ideas of Thierry de Pauw. IIRC, I already posted his talk "Non blocking Pull Requests" on the channel, but in any case, I can do it again.
The main premise of the article is that you need to adopt T*D practices: test-driven development, trunk-based development, and another made-up T*D practice that basically means pair-programming.
From my experience I can say, that eliminating pull requests is probably not something you can do in a short run, but measuring the waiting time before PRs are merged is a good practice. Another good practice is to team-up on tasks or projects. So, basically pair-programming, but several people can still work on different tasks within a project, share context on this project, and thus be able to review each other's work almost immediately without much context switching.
T*D practices are also nice. Honestly, I have an impression that the majority of people are using the trunk-based merge model and continuous deployment these days. Also, it's interesting how AI can facilitate test-driven development: spec (by human) => test (by a machine) => tests review (by humans) => coding (by a machine).
#culture #programming
- 🤨 8
- 😐 2
- ❤ 1
