4 ms·

Not all contributors to a project know all aspects of that project equally well. People also come from a variety of different backgrounds that lends them differ

by swift 9y ago

Not all contributors to a project know all aspects of that project equally well. People also come from a variety of different backgrounds that lends them different insights into the code. Beyond that, it's easy for even experts to make mistakes that they don't recognize in their own work - we've all had the experience of coming back to a piece of writing after a day or two and noticing errors and typos that we couldn't see during the writing process. Waiting for code review is frustrating sometimes (and for that reason, it's important to have a culture of prioritizing code review) but it really helps produce higher quality code, which is a major time-saver in the long run. It also has the side effect of keeping other team members informed about what you're doing, which is important for the overall effectiveness of the team. I agree with you, though, that knowing if things are likely to cause problems is an important skill. If you asked me to give you some examples, not requiring code review would be at the very top of the list. =)

toast0 9y ago
> Not all contributors to a project know all aspects of that project equally well. People also come from a variety of different backgrounds that lends them different insights into the code. Beyond that, it's easy for even experts to make mistakes that they don't recognize in their own work - we've all had the experience of coming back to a piece of writing after a day or two and noticing errors and typos that we couldn't see during the writing process. I expect contributors who are working on an aspect that they're not familiar with to ask for a review; my policy isn't zero reviews, but just like zero reviews is crazy, I find 100% reviews crazy. Experts will make mistakes too, and sometimes a review would have caught it, but you have to think about the cost to the organization for reviewing all changes, along with the cost of mistakes and consider the amount of mistakes that would be found with pre-push reviews. It really depends on the organization, what the cost of mistakes is: I wouldn't be such a cowboy if I were developing self driving cars instead of communications software; it also helps that there are constant failures beyond our control, that need to be handled -- proper handling of those failures often also handles failures within our control, reducing the impact. > I agree with you, though, that knowing if things are likely to cause problems is an important skill. If you asked me to give you some examples, not requiring code review would be at the very top of the list. =) Well, we'd order our lists differently, and have different content in it, but at least we have the same title on our list ;)

by swift 9y ago

toast0 9y ago

> Not all contributors to a project know all aspects of that project equally well. People also come from a variety of different backgrounds that lends them different insights into the code. Beyond that, it's easy for even experts to make mistakes that they don't recognize in their own work - we've all had the experience of coming back to a piece of writing after a day or two and noticing errors and typos that we couldn't see during the writing process. I expect contributors who are working on an aspect that they're not familiar with to ask for a review; my policy isn't zero reviews, but just like zero reviews is crazy, I find 100% reviews crazy. Experts will make mistakes too, and sometimes a review would have caught it, but you have to think about the cost to the organization for reviewing all changes, along with the cost of mistakes and consider the amount of mistakes that would be found with pre-push reviews. It really depends on the organization, what the cost of mistakes is: I wouldn't be such a cowboy if I were developing self driving cars instead of communications software; it also helps that there are constant failures beyond our control, that need to be handled -- proper handling of those failures often also handles failures within our control, reducing the impact. > I agree with you, though, that knowing if things are likely to cause problems is an important skill. If you asked me to give you some examples, not requiring code review would be at the very top of the list. =) Well, we'd order our lists differently, and have different content in it, but at least we have the same title on our list ;)