[HN Gopher] Don't point out something wrong immediately
___________________________________________________________________
Don't point out something wrong immediately
Author : uvdn7
Score : 53 points
Date : 2022-02-16 03:56 UTC (1 days ago)
(HTM) web link (blog.the-pans.com)
(TXT) w3m dump (blog.the-pans.com)
| SideburnsOfDoom wrote:
| > "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?
| lazide wrote:
| 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.
| financetechbro wrote:
| 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
| kodah wrote:
| I'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?
| pjc50 wrote:
| Yes, this a very good approach - it gives people the
| opportunity to double check and spot it themselves, and it
| gives _you_ an out if you 're wrong. Bit of the old socratic
| dialogue.
| imwillofficial wrote:
| I'm super bad at this, great advice.
| the_duke wrote:
| This is the hardest lesson I had to learn in my consulting work.
| It's 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 stupid
|
| * 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
|
| * ...
|
| 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.
| sklargh wrote:
| I now use the discovery of something obviously stupid as a
| fairly reliable detection mechanism for either a broken
| system/process and/or a context queue that I am missing some
| larger, typically organizational, part of the picture.
|
| I also often use my internal voice to say "shut up and listen
| to myself," when I want to immediately engage in a
| conversation.
| imwillofficial wrote:
| Stealing this workflow! Thanks
| vmception wrote:
| The other side of this is how nearly every engineer is going to
| trash talk the prior coders, when they inherit a codebase.
|
| So I already know to ignore it.
| draw_down wrote:
| donatj wrote:
| This has been the hardest thing for me as I become more and more
| ... old. I want to be like "this is wrong" "do it this way" etc.
| For a while there before I realized I was burning bridges, I
| was... for lack of better phrasing actively an asshole. There's
| value in letting the juniors flounder a bit.
|
| I had a conversation with my manager about this just a couple
| weeks ago. One of our junior developers was having trouble
| getting his local dev environment working with a self-signed
| certificate, pretty obvious problem, easy fix, and my gut wanted
| to just remote control his desktop and fix it.
|
| My manager however was like "Let him figure it out on his own,
| it'll be good for him. If he asks questions, answer them, but let
| him work his way through it" - I think that's some pretty sagely
| advice.
| sibeliuss wrote:
| I was just about to do this, but then thought to myself: wait,
| see if they realize the error and fix it and then follow up. And
| then opened HN and saw this post! It was a nice confirming
| synchronicity.
| pavon wrote:
| The 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".
| clintonb wrote:
| "Think before you speak."
| [deleted]
| hughrr wrote:
| I haven't read the article to be honest because I'm lazy and
| slightly drunk but I have to agree with the title.
|
| You need to give people enough rope to hang themselves with so
| you have a tangible reference point in which to start an opposing
| argument. Broken down into an expenditure of effort consideration
| it's cheaper to say I told you so then sit in endless meetings
| convincing someone they're about to do something stupid.
| rav wrote:
| When "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!
| hyperpallium2 wrote:
| Chesterton'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 understood
| jaimex2 wrote:
| If you're not dealing with an adult sure.
|
| Not all grown up people are adults.
| draw_down wrote:
| joseph8th wrote:
| We 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.
| fjorde wrote:
| I appreciate the sentiments.
|
| i think the cert for https://cieloconnects.com/ is expired.
| gmfawcett wrote:
| Eh, 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.
| pimlottc wrote:
| 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.
| nomel wrote:
| > 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.
| jrockway wrote:
| 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.
|
| 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.
| jka wrote:
| 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.
| renewiltord wrote:
| 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.
| Lockyy wrote:
| 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!
| spockz wrote:
| 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.
| mwcampbell wrote:
| > 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.
| blacksmith_tb wrote:
| 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).
| TheOtherHobbes wrote:
| I think there are status plays, and there are quality plays.
| Which is which depends on the culture.
|
| The motivation is completely different - one is parasitic and
| narcissistic, one is constructive - but they can look and
| feel very similar, especially to those on the receiving end.
|
| I strongly suspect orgs tend towards a status culture unless
| carefully steered towards quality. I haven't worked out what
| the full secret is, but it may have something to do with
| strongly valuing and respecting skills and input outside of
| reviews, so specific criticisms aren't experienced as part of
| a consistent pattern of devaluation.
| jka wrote:
| 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.
| the_duke wrote:
| M
| emptybottle wrote:
| I'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.
| r_hoods_ghost wrote:
| One 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.
| mmaunder wrote:
| Point 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.
___________________________________________________________________
(page generated 2022-02-17 23:00 UTC)