41–50 of 315 posts
Earlier quoted context omitted.
Causing a major fuck-up in production is probably also a sign that you need better release validation and deployment practices.
For many developers, people merge their branches directly to production so the pull request review is where that checking happens.
Earlier quoted context omitted.
Causing a major fuck-up in production is probably also a sign that you need better release validation and deployment practices.
For many developers, people merge their branches directly to production so the pull request review is where that checking happens.
He mentions "trust" a lot. Is that why we do code reviews, because we don't trust each other? I find this attitude problematic. We do code reviews because humans make mistakes. Requirements can be misinterpreted. Different work in progress can be in conflict with each other. Reviews are a good way to learn from each other and keep abreast of what work is occurring outside your own bubble. Not doing code reviews becau…
He mentions "trust" a lot. Is that why we do code reviews, because we don't trust each other? I find this attitude problematic. We do code reviews because humans make mistakes. Requirements can be misinterpreted. Different work in progress can be in conflict with each other. Reviews are a good way to learn from each other and keep abreast of what work is occurring outside your own bubble. Not doing code reviews becau…
The deciding factor was ownership and accountability tho - you maintained own code and if you done it crappily, you knew.
The code review is related to assumption that everyone can change everything - meaning all in all inconsistent mess. It is also related to unfortunate assumption that code review is how people learn system. They don't, unless they are original author. The rest of then knows pieces of it only.
He mentions "trust" a lot. Is that why we do code reviews, because we don't trust each other? I find this attitude problematic. We do code reviews because humans make mistakes. Requirements can be misinterpreted. Different work in progress can be in conflict with each other. Reviews are a good way to learn from each other and keep abreast of what work is occurring outside your own bubble. Not doing code reviews becau…
If something hit production and caused a major fuck-up because there was no peer review process, then in all the places I've worked at the first action item in the post-mortem would be "we should introduce peer review." Otherwise someone would ask how we could ensure it wouldn't happen again, and no one would be able to say "because we trust them," and leave it at that. It would sound more like "I trust you will neve…
One downside of code review is reduced velocity. There are teams out there who use code review so effectively that they never ship big fuck-ups to production. They never have to tell clients that they have bad practices. Instead, they struggle to get clients because they pay much more per line of code shipped and therefore don't deliver as good of a value as their competitors.
This where the argument needs to be: whether and how to have code reviews be a net positive.
Absolutely not. This is a recipe for disaster and a terrible example to set for any upcoming engineers that haven’t had much industry experience yet. Code reviews help me be more confident in my own work. Even if 90% of the time it’s fine, there’s always that 10% where a second pair of eyes catches a mistake or offers a suggestion that makes the code even better.
Testing is pretty awesome process to find bugs.
Absolutely not. This is a recipe for disaster and a terrible example to set for any upcoming engineers that haven’t had much industry experience yet. Code reviews help me be more confident in my own work. Even if 90% of the time it’s fine, there’s always that 10% where a second pair of eyes catches a mistake or offers a suggestion that makes the code even better.
Meh. If 90% of the time it's a mindless ritual there is probably a better way to achieve the same goal. Code reviews are a huge time sink, especially for unimportant style- and naming nits. Code review as mentoring can be great, if it's a directed 1:1 effort. Usually, it is not.
He mentions "trust" a lot. Is that why we do code reviews, because we don't trust each other? I find this attitude problematic. We do code reviews because humans make mistakes. Requirements can be misinterpreted. Different work in progress can be in conflict with each other. Reviews are a good way to learn from each other and keep abreast of what work is occurring outside your own bubble. Not doing code reviews becau…
If something hit production and caused a major fuck-up because there was no peer review process, then in all the places I've worked at the first action item in the post-mortem would be "we should introduce peer review." Otherwise someone would ask how we could ensure it wouldn't happen again, and no one would be able to say "because we trust them," and leave it at that. It would sound more like "I trust you will neve…
I think this would work really well for a small and experienced team, though where I work, we have a lot of developers fresh out of college, and I would be pretty nervous setting them loose without close review of their work.
The idea is not that everyone has to be omnipotent, it's that you trust people enough to send for review and ask for help when appropriate , instead of always. I.e. when you're new to the code base or language.
He mentions "trust" a lot. Is that why we do code reviews, because we don't trust each other? I find this attitude problematic. We do code reviews because humans make mistakes. Requirements can be misinterpreted. Different work in progress can be in conflict with each other. Reviews are a good way to learn from each other and keep abreast of what work is occurring outside your own bubble. Not doing code reviews becau…
The best code I have seen was on projects without code review. And projects with it were more mess - they were surface consistent but overall hard to comprehend. The deciding factor was ownership and accountability tho - you maintained own code and if you done it crappily, you knew. The code review is related to assumption that everyone can change everything - meaning all in all inconsistent mess. It is also related…
Ownership and accountability are workable as long as the same person sticks around long enough to fix all their mistakes. If that person leaves, the code becomes orphaned and it's up to one of their teammates to find out where the skeletons are buried.