3 ms·
A "why aren't you doing it this other way?" comment is appropriate when: - You understand both options. - You understand the tradeoffs between them. - You ha
by closeparen 8y ago
A "why aren't you doing it this other way?" comment is appropriate when:
- You understand both options.
- You understand the tradeoffs between them.
- You have a reasoned argument for favoring one approach.
- You suspect that the other person is missing some of this information.
I love getting comments that teach me about a language, API, design patterns, or potential bug, and make my code better. Even if I'm going to stay the course in this particular case, I'm happy to have received the comment, and always try to let the commenter know that. An okay code review gets my code landed fast, a good code review is one I learn from.
But I can't fucking stand defending and explaining perfectly normal and reasonable choices to engineers who just don't know and are curious, or have weird taste, or are otherwise putting me through the exhausting exercise of fighting for every little choice without providing value in return.
- tomlagier 8y ago> But I can't fucking stand defending and explaining perfectly normal and reasonable choices to engineers who just don't know and are curious, Often times when I'm reviewing code, I'm learning as well. If I ask a question because I don't know and am curious, I'd think that's a good opportunity for knowledge transfer. Why can't you fucking stand it? edit: it occurs to me that this comment is extremely meta, hah.
- deleted 8y ago[deleted]
- closeparen 8y agoCode quality is an aesthetic sense. It's easy to look at some code and render an opinion. With a certain level of maturity, you can intuitively come up with code that feels right. But offering a rational explanation for each minor decision between mostly-equivalent alternatives is disproportionately hard. Usually there isn't one. Trying to get more experienced engineers to knowledge-transfer the decision trees they're following is a seductive but wrong model for getting better at software engineering. If such trees even exist they are subconscious. Observe, reflect, try stuff out, solicit feedback. Run that cycle with the highest quality and quantity inputs you can find. It's absolutely your senior colleagues' duty to help you develop the aesthetic sense, but the higher quality and more cost effective way to do that is by giving feedback on your work.