"Think before you speak."
Don’t point out something wrong immediately
21–30 of 180 posts
Re: Don’t point out something wrong immediately
#22Earlier quoted context omitted.
Even with a code review, though, you might want to wait until you’ve digested the rest of the review instead of firing off a comment. Maybe it makes sense in context. Or maybe there are bigger fish to fry and it’s not worth quibbling over small things.
> Or maybe there are bigger fish to fry and it’s not worth quibbling over small things. I've taken this approach with one of our engineers, and now we have a huge pile of "small things" that has created some pretty serious technical debt. My perception is that they don't try to understand what I'm pointing out, and come up with rational for how they have it. I think I have a lot to learn.
I definitely have a list of things I've let go just to be nice that have caused production outages, consistent poor performance, time-consuming technical debt, etc. It's great to have a good relationship with your team, but at the end of the day, the things that you "let go" can become reasons not to buy your product or why new engineers won't be productive on the codebase. It's very easy to be the person that never says "no" to something, but at the same time, it's also easy to be the reviewer that doesn't advance the reviewee's career. A reviewer should ask themselves; "by not commenting on this, am I making the reviewee a better programmer?"
Something I've noticed is that acquaintances will be nice to you universally, but actual friends know when to broach subjects that may not be considered "pleasant" or "nice". Don't give your friends "acquaintance-level" code reviews.
Re: Don’t point out something wrong immediately
#23Eh, this is so contextual though. In the context of a code review, as in the article: no, please point out an issue if you see it, don't hold back. But raise it once, be willing to let it go, and respect that your colleagues don't have to act on your advice. The golden rule will get you far.
Even with a code review, though, you might want to wait until you’ve digested the rest of the review instead of firing off a comment. Maybe it makes sense in context. Or maybe there are bigger fish to fry and it’s not worth quibbling over small things.
This is a tooling problem. Github reviews vs. Bitbucket reviews will show this. In Github you can write your comments and send them all at once. Until you submit the review, you can just edit your comments and undo them or whatever.
Re: Don’t point out something wrong immediately
#24Eh, this is so contextual though. In the context of a code review, as in the article: no, please point out an issue if you see it, don't hold back. But raise it once, be willing to let it go, and respect that your colleagues don't have to act on your advice. The golden rule will get you far.
Even with a code review, though, you might want to wait until you’ve digested the rest of the review instead of firing off a comment. Maybe it makes sense in context. Or maybe there are bigger fish to fry and it’s not worth quibbling over small things.
This is why I am so grateful for GitHub reviews; Being able to group comments to fire off all at once has saved me from this multiple times as I continue reading, realise something, and remove a previous comment.
In fact you reminded me of the technique right now to check the responses and make sure nobody else had already said this!
Re: Don’t point out something wrong immediately
#25> "feel sad" -> "eat chocolate" -> "feel good" cycle. > For engineers, the cycle is "see a problem" -> "spot flaws" -> "feel good". Maybe I'm missing some aspect of the text? AFAIK, "feel sad" and "eat chocolate" are different things (with a cause and effect relationship) and "see a problem" and "spot flaws" are the same thing expressed in different words, so what's the cycle here?
I think the second example is probably meant more as ‘point out flaws’.
Having someone point out flaws, while sometimes an important ingredient in actually fixing flaws, can just as or more often be about as useful in really solving something as eating chocolate can be in addressing why someone is feeling sad.
Aka, not much.
Re: Don’t point out something wrong immediately
#26I’d even suggest shedding the thought that things can be “wrong”
“Wrong” is a subjective outlook and usually is not a helpful conclusion. Especially if the system is already active.
Better to discuss in detail the benefits of an alternative.
Re: Don’t point out something wrong immediately
#27> "feel sad" -> "eat chocolate" -> "feel good" cycle. > For engineers, the cycle is "see a problem" -> "spot flaws" -> "feel good". Maybe I'm missing some aspect of the text? AFAIK, "feel sad" and "eat chocolate" are different things (with a cause and effect relationship) and "see a problem" and "spot flaws" are the same thing expressed in different words, so what's the cycle here?
You are overthinking it. An alternative to “spot flaw” here would be “point out flaw”. The author is just giving an example on how engineers have a habit of pointing out flaws
Re: Don’t point out something wrong immediately
#28Earlier quoted context omitted.
Even with a code review, though, you might want to wait until you’ve digested the rest of the review instead of firing off a comment. Maybe it makes sense in context. Or maybe there are bigger fish to fry and it’s not worth quibbling over small things.
This is why I am so grateful for GitHub reviews; Being able to group comments to fire off all at once has saved me from this multiple times as I continue reading, realise something, and remove a previous comment. In fact you reminded me of the technique right now to check the responses and make sure nobody else had already said this!
On the other hand, someone coming after you might read the code in the same order and have the same wtf moment. They may even never find that later piece you saw in the review. So at the least it should still be a signal to the Author that it appears strange.
Re: Don’t point out something wrong immediately
#29One thing you also have to be very careful of is pointing out a problem or inefficiency that exists only because of work you or your company has done.
I have a very problematic supplier of business critical bespoke software that we can't move away from, and the devs there have a nasty habit of pointing out flaws in our processes, talking down our other suppliers and making snarky comments, when those flaws are usually either workarounds to deal with the shit system they have developed or persist because while we would like to do things in a more modern way we can't as we can't rely on them to even implement an address validator that works. Frankly the only reason they're still alive and I have a job is Covid and remote working.
Re: Don’t point out something wrong immediately
#30Point it out immediately. And work to create a culture that understands we all share the same goal of building more robust software. If you sense feelings are hurt, explain the common goal and point out wins the other person has had in the past. But I’d recommend against preemptive caution because it will add significantly to your workload and to friction during collaboration. It may also create an atmosphere of over abundant caution - which is kind of awful if you’ve ever experienced it.