[deleted]
Don’t point out something wrong immediately
11–20 of 180 posts
Re: Don’t point out something wrong immediately
#12Eh, 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.
> Or maybe there are bigger fish to fry and it’s not worth quibbling over small things.
This was my excuse to not be thorough when giving feedback in code review, when I was last in a position to do so, while on the Windows accessibility team at Microsoft. I told myself I was on a mission to make Windows more accessible, and there was no time to delay new features or fixes over inconsequential things like coding style or even code organization, as long as it worked.
Edit: At least I didn't use that excuse when responding to coworkers' reviews of my PRs.
Re: Don’t point out something wrong immediately
#13When "something is wrong" in a large system, it might not be straightforward to say which detail is wrong exactly.
One of the reasons that you shouldn't "point out something wrong the moment you see it" is because there might be multiple candidates for the "wrong" thing that needs to be addressed, and addressing any of them is enough to make the system as a whole "not wrong" (or at least, less wrong).
If a colleague says something that sounds immediately wrong, try to let them finish what they're saying and try to figure out why it doesn't immediately seem wrong in their own eyes - it might be that what they're saying is only wrong in the context of a larger system, and the colleague simply has a different understanding of the larger system from you, which causes them to not immediately think that it's wrong. Sometimes the "actually wrong" thing might be somewhere else in the system, and if your colleague hadn't been allowed to finish their thought, no one would have realized where the "actually wrong" thing is!
Re: Don’t point out something wrong immediately
#14Chesterton's Fence https://wiki.lesswrong.com/wiki/Chesterton%27s_Fence
reforms should not be made until the reasoning behind the existing state of affairs is understoodRe: Don’t point out something wrong immediately
#15Earlier 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'm still learning too, but I think that something I'm trying to develop is a sense for the longer-term costs and implications of apparent defects.
- Is this a component that every engineer is going to interact with and that will stay with the company for decades?
- Can this technical decision be reversed easily? Either in the sense of an individual commit revert, and/or in terms of a series of code changes?
- Is this change likely to remain isolated to this part of the codebase, or will the pattern infect or be copied to other locations widely?
It's super challenging -- and also intellectually rewarding when you can master it and gather team consensus and alignment.
Re: Don’t point out something wrong immediately
#16> "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?
Re: Don’t point out something wrong immediately
#17We had a DevOps engineer who was brutal this way. Personally I found it only occasionally annoying, but our PM almost fired him several times. I talked him down by pointing out that risk aversion is a good quality in an engineer. When we interview for engineers, we always ask candidates if they are risk-taking multi-taskers, because those are desirable qualities... In some other field.
I appreciate the sentiments.
i think the cert for https://cieloconnects.com/ is expired.
Re: Don’t point out something wrong immediately
#18I’m super bad at this, great advice.
Re: Don’t point out something wrong immediately
#19This is the hardest lesson I had to learn in my consulting work. It is is especially important if you are not familiar with the full context - which is almost never the case. The main insight for me was that yes, things can be "wrong" due to lack of knowledge or incompetence. Sometimes. But more often than not there is a good reason. Like: * we know this is stupid, but we had immense time pressure and this was the on…
Stealing this workflow! Thanks
Re: Don’t point out something wrong immediately
#20The hardest part about this for me is that I often feel like that is the only time I will get to chime in. If I give myself time to think about it - whether it is important enough to discuss, and if so how to do so productively - the conversation will have moved on. The other party will take lack of objection as agreement, and I'll either forget about it until the concern becomes an actual problem (or nothing bad happens), or I'll constantly be that guy dragging up issues that were already "settled".