|
|
|
|
|
by maerF0x0
1120 days ago
|
|
> low self esteem from ... non-constructive or overly harshly presented critique ok firstly Comments about the individual in a CR is way out of line. There is a massive difference between "This code will fail in <a certain way>" and "You failed <, again, like you always do>" ... The latter is out of line and should be addressed head on with a manager present or a person who will enforce it's toxicity. Now that said, criticism of code should always been allowed. It either has certain properties or it does not. A discussion of economics (scope/timelines/applicability) are a middle ground. But either the code has a race condition or it doesnt. It's easily read (which is best judged by the reader, not the writer)... It's missing some property that is desirable. If one takes a criticism of code as a criticism of self, that is ego crossing over to where it doesn't belong. I like to remember The bridge will either hold the load or not regardless of how one feels about it. "This wont hold 1 ton" is better information than "Have you considered what happens if you put 1 ton on this?" .. The former informs you of something that must change, the latter leaves uncertainty and obscurity where infact the answer is already known. |
|
Being direct and being polite aren't mutually exclusive, and direct criticism doesn't have to leave out any information at all. Saying "This approach won't work under peak load because" in a code review conveys the same exact message as "Your code will collapse like a popsicle stick bridge the second we hit peak load because" during a meeting.