|
|
|
|
|
|
by msluyter
2423 days ago
|
|
|
My variant on this tends to go: "It looks like this <code block/method/module> will cause XYZ to happen. Is that what you intended?" Simple example (Python): def foo(x):
print(x.lower())
"If x is None this will raise an exception. Is that an
expected outcome, and/or can we assume x is always non-None?"One thing I like about this approach is that it first describes your understanding of a particular code section, which helps illuminate any assumptions we might hold (and which might be incorrect). This is a good practice generally, IMHO, with or without the followup question. A guy I used to work with would make non-judgemental comments that just summarized his understanding of what was happening in the code, and it was helpful because when the comment was off, it illustrated a way in which the code was perhaps unclear or incorrect. |
|
|
Of all the variants proposed in this topic, this is the only one that puts any burden whatsoever on the speaker in the first place (in a good way).
Demonstrating that you've made an actual attempt to understand what your colleague is doing is far more genuine and likely to be received as such. Unlike the mealy-mouthed carefully-phrased examples that just communicate "I care more office politics than actually ensuring this code is high quality," your approach hits a trifecta of signaling respect, actually identifying the concerning behavior of the code, and inviting all the types of productive responses:
You allow the person to graciously admit an error without particularly losing face (they can simply say "nice catch, thank you" and fix it themselves). You provide an inroad to correcting your OWN potentially false assumption -- very helpful, for example, when a junior dev whose work is being reviewed is actually in the right, but politically might be unable to demonstrate that. And your question about the mechanics opens the door to a collaborative discussion in which both sides contribute to the final codebase.