4 ms·
Agreed. In these cases, the reviewer should always aim for learning as much as teaching (if not more so). I've gone into code reviews where my reaction began w
by organsnyder 7y ago
Agreed. In these cases, the reviewer should always aim for learning as much as teaching (if not more so).
I've gone into code reviews where my reaction began with, "ugh, this is terrible", but evolved into, "well, I probably would have done it differently, but this approach handles an edge case I hadn't considered".
- makapuf 7y agoCompletely agree with all of this. Some say be hard with the code, soft with the coder. Also don't nitpick and be nice. Simple.
- filoleg 7y agoIn cases like this, I explicitly preface it with "nit: <text here>", explain how I would do it myself instead and why, and then (also explicitly) say that this is more of a preference thing and that they should feel free to leave it as is. It might turn out they like my approach more and change the code, but if not, it is still totally cool with me, as they learned of just one more way to do the same thing that might come useful later.
- just_myles 7y agoSame. I've heard it all. From "terrible", "You don't know what you're doing", "does it work?", to "ok, I see why you did it so try this way instead because X". It's honestly who you are working with.