Don’t point out something wrong immediately
blog.the-pans.com
Don’t point out something wrong immediately
1–10 of 180 posts
Re: Don’t point out something wrong immediately
#2No post body was provided.
Re: Don’t point out something wrong immediately
#3We 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.
Re: Don’t point out something wrong immediately
#4Eh, 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.
Re: Don’t point out something wrong immediately
#5Eh, 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.
Re: Don’t point out something wrong immediately
#6I've learned to ask questions instead of utilizing call-out culture. I can ask what some component is doing, strategy to scale, etc... That usually works very well in place of me saying that I perceive something is "wrong".
Example
I saw empathy in the tags. How does empathy apply to this post?
Re: Don’t point out something wrong immediately
#7Eh, 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.
Right, I think the title should be something closer to "Don't point out something wrong to make yourself feel valuable/smart/etc". Obviously in lots of contexts you do need point it out immediately (the server is down, your neighbor's house is on fire) but when it's just giving feedback, it's good to be helpful (even then there are times when tough love is required, I don't feel bad about pointing out when a mistake would have terrible consequences if it shipped).
Re: Don’t point out something wrong immediately
#8This 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 only way to get it done for the deadline; we never got the time to fix it
* external system constraints (like legacy applications, legal/certification requirements, ...)
* particular domain constraints that you might not be familiar with, and that only make sense if you know the details
* important senior engineer X designed this and no one had the guts to call it out as flawed
* the company paid a lot of money for product Y, so we just had to use it
* a manager read a blog post on how technique Z is awesome, so he made us do it this way
* political infighting between parts of an organisation (redundant work, refusal to work together, deliberate sabotage)
* ...
But you will usually not hear these reasons right away. And being critical can easily put others in a defensive stance and make it very hard to get that information at all.
So my best tip is: if you spot something "wrong", don't react immediately and don't interrupt. Let the other party finish. Make a note. Gather more information. Ask why it was done this way, who is responsible, if it has been effective or not, and whatever else could be relevant.
You can still be as critical as required later.
Re: Don’t point out something wrong immediately
#9Eh, 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.
There's so much nuance in code review communication. The way I'd interpret this article's advice in the context of reviews would be: don't begin adding comments about minor annoyances and details that you've noticed until after you've read through most/all of the changeset and raised any more important structural concerns first.
Re: Don’t point out something wrong immediately
#10Eh, 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.
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.