3 ms·

On the flip side, though, I think it's important for the code that you send to other engineers for review to be at least kind of polished, because otherwise you

by ketzo 5y ago

On the flip side, though, I think it's important for the code that you send to other engineers for review to be at least kind of polished, because otherwise you risk just wasting other people's time. If you get feedback on your code that you already knew about, you wasted someone's time, and I think that's inefficient and a little bit disrespectful. But I definitely agree that code review is very much a drafting process. It's just that you need to walk a line.

nightpool 5y ago
I get where you're coming from, but if a friend asks me to look over an important email that they're planning on sending to their boss, I don't think of it as "wasting my time" if the email has a bunch of grammatical errors in it. Instead, I'm happy that I'm able to help them by applying a fresh pair of eyes to the problem, since they've probably spent a really long time working on the actual content of the email and haven't had the opportunity to step back and consider . It's just an efficient division of labor. In the same way, code review is a great opportunity to let someone who wasn't involved in the actual writing of the code approach the problem & solution space with fresh eyes, now that you've done the hard work of translating the solution into something that actually works. And code reviews are even more collaborative then that. When I'm looking over my friend's email, it's still ultimately their email and there are types of feedback that it would be inappropriate to give. But when you're contributing to a shared codebase, it's more like a novel that's been co-written by multiple different authors—obviously you want everybody on the team to be able to have input and feedback into what the "collective style" of the project is going to be.
- shkkmo 5y ago
  > they've probably spent a really long time working on the actual content of the email and haven't had the opportunity to step back and consider Before you ask someone to proof read anything, you should generally take the effort to step back and try to proof read it yourself. The same goes with code reviews. I think there is absolutely value in soliciting feedback throughout the process, but would consider those earlier feedback stagea to be design and/or implementation reviews (which depending on feature size should happen with varying degrees of formality.) It is useful to be explicit about the types of review because the types feedback that are useful vary throughout the process. If you are looking for design feedback and someone complains about unimplemented tests, that generally isn't very helpful. If you are looking for a final code review for polished code and you get feedback about the underlying design, then you really needed to get that feedback earlier in the process.

by ketzo 5y ago

nightpool 5y ago

I get where you're coming from, but if a friend asks me to look over an important email that they're planning on sending to their boss, I don't think of it as "wasting my time" if the email has a bunch of grammatical errors in it. Instead, I'm happy that I'm able to help them by applying a fresh pair of eyes to the problem, since they've probably spent a really long time working on the actual content of the email and haven't had the opportunity to step back and consider . It's just an efficient division of labor. In the same way, code review is a great opportunity to let someone who wasn't involved in the actual writing of the code approach the problem & solution space with fresh eyes, now that you've done the hard work of translating the solution into something that actually works. And code reviews are even more collaborative then that. When I'm looking over my friend's email, it's still ultimately their email and there are types of feedback that it would be inappropriate to give. But when you're contributing to a shared codebase, it's more like a novel that's been co-written by multiple different authors—obviously you want everybody on the team to be able to have input and feedback into what the "collective style" of the project is going to be.

shkkmo 5y ago
> they've probably spent a really long time working on the actual content of the email and haven't had the opportunity to step back and consider Before you ask someone to proof read anything, you should generally take the effort to step back and try to proof read it yourself. The same goes with code reviews. I think there is absolutely value in soliciting feedback throughout the process, but would consider those earlier feedback stagea to be design and/or implementation reviews (which depending on feature size should happen with varying degrees of formality.) It is useful to be explicit about the types of review because the types feedback that are useful vary throughout the process. If you are looking for design feedback and someone complains about unimplemented tests, that generally isn't very helpful. If you are looking for a final code review for polished code and you get feedback about the underlying design, then you really needed to get that feedback earlier in the process.