Some processes can't be efficiently sped up by more people in the room like debugging or research. Some people work at different speeds and with different daily efficiency distributions. Some people find it easier to write rather than talk. This means that group programming introduces a lot of restrictions while selecting team members. What this talk inspired me to try are group code review sessions. This would keep most of the benefits described in the video and minimizes the problems described above.
Absolutely fantastic discussion and makes you think. So here are my thoughts ... with adequate tests using tdd + pair programming + solid & super fast deployment processes .. why do you need PRs? some sort of audit related thing? When I see forced PRs I think this company requires them for compliance or they don't trust their test or deployment processes or etc which scares me.
You need PR's as pair programming sucks and TDD is not a guarantee that there will not be issues, "I have added unit tests to prove my bugs work as expected", a set of eyes from the person who knows the systems well will always have benefits
I have seen code covered with lots of tests that still had dozens of bugs and design flaws. If you don't really understand what's required for your feature, you won't be able to write adequate tests for it.
@@igelineau Would this not come down to cognitive load? Assuming someone is having a hard time understanding the code and how to implement the requirements, would this not indicate that the service grew to be too large and needs to rework fracture planes? I find pair programming and using co-authored commits to have almost the same reliability as a PR. However, I find that PRs cause more harm than good because reaction to PRs is slow, communication overhead is high, and congestion occurs in deployment. Once congestion sets in it becomes miserable. Our deployment velocity is rather high and I find the best way to reduce cognitive load is to create more fracture planes
@@alexdarby9392 you’re assuming that the person/people doing the work do not understand the system well. In this scenario you have knowledge siloing, and I don’t know a better way to remedy that than through the same approaches Dragan outlined in the talk. Why would you have someone working on something that doesn't understand the requirements or the system? Everybody doing the work should have the knowledge to do it.
It's odd that the talk only focuses on the throughput, while completely ignores the benefits from the async code reviews. Obviously by letting people work at their own schedule may increase the wait time (this is why it's async!), especially without proper prioritization. Writable forms of feedback also has the benefit of being searchable and scannable which builds the invaluable context for future maintainers (including original authors), so you trade the initial boost of speed for the slowdown in the maintenance in the future, similar to what happens with the tech debt. Perhaps the balance is somewhere in between, where with pair programming you can eliminate most of the obvious shortcomings, assumptions and quality issues, while async review enables larger group of people to verify that the communication introduced in a PR is clear and unambiguous.
Leave a sync reviews for context like OSS, where there is no trust between contributors, and embrace co-creation patterns and CI for company context. You will be astonished. 😊
Be honest, how many times have you gone to a PR to see feedback to maintain a software? If you need to go to a PR and search the comments to understand the software you're working on, maybe you have another problem to solve, maybe you don't understand the problem space enough so the code doesn't make sense to you, or maybe the code design sucks and doesn't reflect the problem it solves (the code doesn't reveal its intent). In all cases, it is not a comment in a PR that will solve the problem. In my experience of more than 10 years developing software of different complexities, working with continuous code review and pair programming has a direct positive impact on the design of the code and consequently on its maintainability. Furthermore, people share knowledge, learn together and master the problem space, which in the long term, positively impacts the business and customer satisfaction.
Having someone sitting next to me does not automatically makes them available to review my code immedietly unless they are forced to multitask. I stop their work to review my. Now they have to deal with context switching problem. On paper many things might seem to work and colored dots would connect but this kind of approach "because he sits near me he is available" is bad, it would just burn out the developers
It's not about sitting next to me in a literal sense, but a figurative one (working on the same thing as me at the same time, i.e., pair/mob programming). No context switching if we're working on the same thing.
This has downsides as well though. 1. You're locking up multiple developers on the same problem. 2. It's exhausting to do pair/mob programming all day for introverts. 3. People have different meetings, which means they will have to drop out sporadically throughout the programming sessions.
I think for bullet 1 you should view this as a positive. You're encouraging deeper knowledge share around your team. I have lots of anecdotal evidence of people approving PRs without fully understanding the changes.
@@struggopuggo I understand the benefits. And you're right that it might be beneficial in some cases. But I don't think it's a good idea to switch to 100% pair programming. Spending one day per week doing pair programming is more than enough to spread such knowledge imo.
@@WorstDeveloper Try it out for some time (both pair and mob programming) and see if it works for you. We often think we know how something feels like while thinking with the mindset shaped by the opposite way of working.
@@WorstDeveloper 1. That's actually an advantage because you get things done sooner. That's the whole point of the talk. 2. Regular breaks (e.g. pomodoro technique) are very important in order to have a sustainable pace. You don't have to pair/mob the whole day (that's not the point). I met so many introverts (me being one of them) that enjoy working this way, but YMMV. An episode from the Mob Mentality Show on this topic is interesting to check out if you haven't already. 3. Mob helps with that resiliency, where people are free to drop and join when they want. It also helps with reducing work in process, which also lowers the number of meetings on (too many) different topics. That's _my_ experience and experience of people I had a chance to work with in this way.
Some processes can't be efficiently sped up by more people in the room like debugging or research. Some people work at different speeds and with different daily efficiency distributions. Some people find it easier to write rather than talk. This means that group programming introduces a lot of restrictions while selecting team members.
What this talk inspired me to try are group code review sessions. This would keep most of the benefits described in the video and minimizes the problems described above.
Great insight. Well presented. Thank you for sharing.
Absolutely fantastic discussion and makes you think.
So here are my thoughts ... with adequate tests using tdd + pair programming + solid & super fast deployment processes .. why do you need PRs? some sort of audit related thing? When I see forced PRs I think this company requires them for compliance or they don't trust their test or deployment processes or etc which scares me.
You need PR's as pair programming sucks and TDD is not a guarantee that there will not be issues, "I have added unit tests to prove my bugs work as expected", a set of eyes from the person who knows the systems well will always have benefits
I have seen code covered with lots of tests that still had dozens of bugs and design flaws. If you don't really understand what's required for your feature, you won't be able to write adequate tests for it.
@@igelineau Would this not come down to cognitive load? Assuming someone is having a hard time understanding the code and how to implement the requirements, would this not indicate that the service grew to be too large and needs to rework fracture planes?
I find pair programming and using co-authored commits to have almost the same reliability as a PR.
However, I find that PRs cause more harm than good because reaction to PRs is slow, communication overhead is high, and congestion occurs in deployment. Once congestion sets in it becomes miserable.
Our deployment velocity is rather high and I find the best way to reduce cognitive load is to create more fracture planes
@@alexdarby9392pair programming sucks? 😅
@@alexdarby9392 you’re assuming that the person/people doing the work do not understand the system well. In this scenario you have knowledge siloing, and I don’t know a better way to remedy that than through the same approaches Dragan outlined in the talk. Why would you have someone working on something that doesn't understand the requirements or the system? Everybody doing the work should have the knowledge to do it.
It's odd that the talk only focuses on the throughput, while completely ignores the benefits from the async code reviews. Obviously by letting people work at their own schedule may increase the wait time (this is why it's async!), especially without proper prioritization. Writable forms of feedback also has the benefit of being searchable and scannable which builds the invaluable context for future maintainers (including original authors), so you trade the initial boost of speed for the slowdown in the maintenance in the future, similar to what happens with the tech debt. Perhaps the balance is somewhere in between, where with pair programming you can eliminate most of the obvious shortcomings, assumptions and quality issues, while async review enables larger group of people to verify that the communication introduced in a PR is clear and unambiguous.
Leave a sync reviews for context like OSS, where there is no trust between contributors, and embrace co-creation patterns and CI for company context. You will be astonished. 😊
Be honest, how many times have you gone to a PR to see feedback to maintain a software?
If you need to go to a PR and search the comments to understand the software you're working on, maybe you have another problem to solve, maybe you don't understand the problem space enough so the code doesn't make sense to you, or maybe the code design sucks and doesn't reflect the problem it solves (the code doesn't reveal its intent). In all cases, it is not a comment in a PR that will solve the problem.
In my experience of more than 10 years developing software of different complexities, working with continuous code review and pair programming has a direct positive impact on the design of the code and consequently on its maintainability. Furthermore, people share knowledge, learn together and master the problem space, which in the long term, positively impacts the business and customer satisfaction.
Having someone sitting next to me does not automatically makes them available to review my code immedietly unless they are forced to multitask. I stop their work to review my. Now they have to deal with context switching problem. On paper many things might seem to work and colored dots would connect but this kind of approach "because he sits near me he is available" is bad, it would just burn out the developers
It's not about sitting next to me in a literal sense, but a figurative one (working on the same thing as me at the same time, i.e., pair/mob programming). No context switching if we're working on the same thing.
This has downsides as well though.
1. You're locking up multiple developers on the same problem.
2. It's exhausting to do pair/mob programming all day for introverts.
3. People have different meetings, which means they will have to drop out sporadically throughout the programming sessions.
I think for bullet 1 you should view this as a positive. You're encouraging deeper knowledge share around your team. I have lots of anecdotal evidence of people approving PRs without fully understanding the changes.
@@struggopuggo I understand the benefits. And you're right that it might be beneficial in some cases. But I don't think it's a good idea to switch to 100% pair programming. Spending one day per week doing pair programming is more than enough to spread such knowledge imo.
@@WorstDeveloper Try it out for some time (both pair and mob programming) and see if it works for you. We often think we know how something feels like while thinking with the mindset shaped by the opposite way of working.
@@kobac8207 I know what it's like because I do it every week at work.
@@WorstDeveloper 1. That's actually an advantage because you get things done sooner. That's the whole point of the talk.
2. Regular breaks (e.g. pomodoro technique) are very important in order to have a sustainable pace. You don't have to pair/mob the whole day (that's not the point). I met so many introverts (me being one of them) that enjoy working this way, but YMMV. An episode from the Mob Mentality Show on this topic is interesting to check out if you haven't already.
3. Mob helps with that resiliency, where people are free to drop and join when they want. It also helps with reducing work in process, which also lowers the number of meetings on (too many) different topics.
That's _my_ experience and experience of people I had a chance to work with in this way.
The way he pronounces `variable` :D :D