16 ms·

Don’t point out something wrong immediately

371 points by uvdn7 5y ago

arvinsim 5y ago
I emphatize with people who point out flaws immediately. Because some people have the habit of dominating discussions or steering discussion away that paints them in a negative light.
foreigner 5y ago
Even harder for me is to remember that someone telling me about their problem is not a request for me to help solve it.
draw_down 5y ago
joseph8th 5y ago
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 5y ago
  I appreciate the sentiments. i think the cert for https://cieloconnects.com/ https://cieloconnects.com/ is expired.
  - jodrellblank 5y ago
    It isn’t expired, look more closely at it. (And, cough, see thread topic)
    - boldslogan 5y ago
      Maybe saying something like hey we’re you aware the browser throws this error NSURLErrorServerCertificateUntrusted To point out the issue but maybe not say exactly what was wrong?
    - fjorde 5y ago
      take your own advice. i noticed a cert was invalid or broken and mentioned it to a person who might care or know how to deal with it appropriately. In the meantime the site is less secure than it could presumably be. i'm not a paid consultant for the site so i didn't bother digging in and finding out which policy violation triggered a browser warning, but since you did, you can share it here or you can continue to add zero-value comments.
      - jodrellblank 5y ago
        How did you even find that site in the first place? It's not in their profile, it's not in the top duckduckgo results for "CIELO Enterprise Solutions". How long were you digging around to find something, anything, to try and pwn them about their high engineering standards comment?
        fjorde 5y ago
        Perhaps there is a language or nuance barrier. I "thanked" the parent commenter for sharing their view, did an "internet search" for their publicly listed company to see what kind of jobs they might have available, and then was warned about certs visiting their site... Now I'm having a terrible conversation with you for some reason, but I hope this helps dispel your confusion. Please feel free not to reply at all with anything.
        deleted 5y ago
        [deleted]
  - joseph8th 5y ago
    Ah look at that! Nice catch. Yes, I can see that something is done to fix that, though I'm not on that team (I'm backend). And to address the debate below, I do in fact appreciate risk-averse and focused engineers. The 'don't say no' thing I think has merit when interfacing with business. But within the team, as long as you're in your own lane I appreciate it very, very much when my coworkers help me find flaws. Most of this comes up in planning anyway, when we're spit-balling best approaches. If the problem is difficult enough, someone will get a research spike to discover best practices and form a set of initial proposals and alternatives. ETA: and yes this is my public profile. I don't mind. I'm proud of my work at CIELO.
gmfawcett 5y ago
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 5y ago
  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 5y ago
    > 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.
    - jka 5y ago
      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.
      - hinkley 5y ago
        > Can this technical decision be reversed easily? One of the most exhausting failure modes that I've had to deal with is deciding not to decide. Some people will build elaborate Rube Goldberg machines so that they "can change their minds later" but in fact what they've done is decided that choices are now everybody else's problems. There's a whole hell of a lot of rewards to having the maturity to be able to say "I was wrong" and move on. Writing code in a way that you could rework it to use a different library to accomplish the same thing is making a reversible decision. Creating a rules engine to let a config file make the choices and leaving a cartesian product of states (75% of which are invariably illegal, which you are just supposed to know) is definitely, definitely not. Just pick something, man.
kodah 5y ago
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 5y ago
  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.
  - sitkack 5y ago
    One has to be very careful with socratic techniques, they can quickly become trite, patronizing and segue nicely into splaining. They are extremely useful and help give space to the state of things, but if the people you are interacting with ever felt like they are being led down a garden path, it can feel like a big setup to getting owned. This advise comes from working on teams where the socratic method was used as a setup for being made a fool.
- rocqua 5y ago
  Empathy applies in two ways. Firstly in realizing that saying 'you are wrong' is hurtful and can be damaging to relationships. Secondly in realizing that other people might already know your objection, but had reasons for proceeding this way anyway.
  - kodah 5y ago
    I'd argue that "you are wrong" can be hurtful, rather than is. It's all about delivery, the culture/environment you're in, and how receptive a person is to negative feedback. The second point is a great way to encourage silencing dissent. Interrogating why people made decisions is part of both science and engineering. Assuming they made all the right choices sounds odd to me.
the_duke 5y ago
This 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.
- johnwalkr 5y ago
  I’m always surprised at “refusal to work together.” The entire point of a company is to organize people to work together, how do workers like that get promoted?
  - pavs 5y ago
    This happens so often, I am surprised that anyone gets surprised by this at all. The entire point of a company is to make money, with the people/resources they have. More often then not what they want is not the best available to them. Most people are horrible, managing a bunch of highly egotistic but talent people is hard.
  - 0x008 5y ago
deleted 5y ago
[deleted]
rav 5y ago
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!
- hinkley 5y ago
  Coherent But Wrong is a known failure mode for architecture. All of the parts make sense when taking in context of all of the other parts, but when you step out of the system the whole thing seems a little nuts. It's basically the Echo Chamber (circular reasoning) condensed into code.
hyperpallium2 5y ago
Chesterton's Fence https://wiki.lesswrong.com/wiki/Chesterton%27s_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
- stellar_rocket 5y ago
  The Chesterton Fence AKA an undocumented obstacle from the perspective of anyone new. Of course we need to understand the system before changing it. But we shouldn't browbeat those wanting to improve the stuff we left no guidance about.
- SpaghettiX 5y ago
  What's the difference between this and "don't change things you don't understand". It would make it clearer that this is a type of approach rather than a law. Sometimes, that legacy system or class is replaced without fully understanding it, because it's cheaper to reimplement it's interface than fix it.
  - yxhuvud 5y ago
    What happens then though, is that the replacement take a lot longer than expected, because it turns out that the complexity in the old system had more motivation than expected and had a lot more problems it solved than was obvious. Fixing these issues then make the new system into almost as big of a problem as the old one, with the only difference in that now you at least have some people that understands it. For a while until enough people have left to again forget the workings of the system. Sometimes the easiest way for a company to relearn about a problem space is to rewrite it though, so it is not necessarily a bad thing to do. It can also be that the market has shifted and some of the complexity in the old system was no longer necessary, so the new system ends up easier. In any case, spending time understanding the existing system (including developers that point out corner cases and nonobvious cases) make the end result so much easier than adjusting a solution to handle a complication angle that wasn't part of the original plan.
  - hyperpallium2 5y ago
SideburnsOfDoom 5y ago
> "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 5y ago
  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.
  - SideburnsOfDoom 5y ago
    > I think the second example is probably meant more as ‘point out flaws’. OK, that seems likely, but why use a word "spot" that does not mean "to point out" ? The distinction is clear here: https://dictionary.cambridge.org/dictionary/english/spot https://dictionary.cambridge.org/dictionary/english/spot Spot: "to see or notice someone or something, usually because you are looking hard" e.g. "If you _spot_ any mistakes in the article just _mark_ them with a pencil."
- financetechbro 5y ago
  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
  - arvinsim 5y ago
    > The author is just giving an example on how engineers have a habit of pointing out flaws It's strange that finding flaws is framed negatively. This ability is a positive trait in software development.
imwillofficial 5y ago
I’m super bad at this, great advice.
pavon 5y ago
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 5y ago
"Think before you speak."
emptybottle 5y ago
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 5y ago
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 5y ago
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.
sibeliuss 5y ago
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.
hughrr 5y ago
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.
jaimex2 5y ago
If you're not dealing with an adult sure. Not all grown up people are adults.
- draw_down 5y ago
the_duke 5y ago
M
donatj 5y ago
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.
- bfung 5y ago
  s/old/experienced/ It took a realization myself that my 20 year accumulated knowledge, insights, skills, mental models is not something most college grads can grasp (there are very, very few exceptions). And telling them verbally doesn’t help either. Ex: due to that experience, I can pick up any language & ecosystem and be productive in 3 days max (from js to c++ to haskell). I can’t expect that from a bootcamper or new grad.
- deleted 5y ago
  [deleted]
- eatonphil 5y ago
  Lucky for you both to have a good manager!
crisdux 5y ago
There certainly is a balance to giving feedback like this. It very much depends on team dynamic and the level of trust between team members. I have experienced lower levels of trust and worsen proficiency in giving and receiving feedback described in this article since the whole WFH thing started, especially as teams at my employer change and we bring on new team members. People are a lot more sensitive, everyone collaborates less and we are accepting a lot of bad code into our projects than ever before. We had about 1/3 of a crucial team leave recently. At their exit interviews they all described how one of the reasons they left is because the code base has turned into a pile of junk and no one wants to work on it. I recently agreed to join this team to help turn it around because I have a reputation for ensuring good engineering practices and giving feedback is a strength of mine. But boy, this environment is challenging with developers all working from home. I'm curious if this resonates with anyone else, specifically if others have similar experiences with wfh.
- nine_zeros 5y ago
  I have something similar. We have a "blameless" culture which is nice. Genuinely appreciate it because people do make mistakes. But our codebase has become progressively worse because nobody tells the truth about their experience. There are teams making bad choices which throw other teams off the cliff. Sometimes product managers come up with elaborate projects without due diligence only to waste 6 months of engineering time. Because of such activities, engineers lost faith in their team/org. They just coast or switch teams/companies or straight up lie to management. There is zero incentive for anyone to improve anything because pointing something out is bad for "optics".
zachrip 5y ago
I recall one of my interns telling me they would never sacrifice quality of code for anything else. When they left I asked them if they still felt the same. They said they had a new understanding for why that may not always be the case. Be like my previous intern.
giantg2 5y ago
I generally wait for the their thought to be completed, to see where they are going with it. I do this on the assumption that I could be wrong and they might know more than me.
ummonk 5y ago
I know that engineers aren’t the most socially adept bunch, but it’s still weird how someone can go this long before having to realize that personal feedback needs to be delivered appropriately because people have emotions and aren’t just programs to be dissected like in a line by line code review.
- simongray 5y ago
  While I recognise that engineers do this a lot, other people certainly do it too. Whenever I present any GUI work to other people (future users) they rarely consider the big picture, but just nitpick some tiny things in a stream-of-consciousness way because it makes them feel like they contributed to the process somehow. Building a UI that pleases most people is challenging and people do not appreciate the hard work (design and engineering) that goes into it, I find, preferring to turn user feedback sessions into nitpicking sessions every time. Usually they are plain wrong too, for the same reasons outlined in this article (e.g. there is a requirement they did not consider).
unnouinceput 5y ago
Pointing wrongs is for noobs. An expert hoards them like CIA/NSA hoards zero days and you deliver them on the day of performance review.
- sgjohnson 5y ago
  But this benefits absolutely nobody. Not even the manager doing that. I know that in my workplace a manager would get chewed out for that, as this practice is explicitly banned by policy. Any issues should be raised the moment they are discovered. Even without the said policy, it doesn’t benefit the business, because if it’s a problem employee, you’re pointlessly keeping them on a payroll, and it doesn’t benefit the employee, because if you hit them with everything at once, little of it will resonate with them.
  - xxs 5y ago
    I guess the comment (GP) was sarcastic (you can tell but the opening phrase alone)
kashkhan 5y ago
And that's why Challenger blew up. Don't work with people who cant handle being wrong and fixing it.
- quicksnap 5y ago
  It's not about people not handling being wrong, but about introspecting on how we deliver feedback. If people cannot take feedback or accept flaws in their work, that certainly is a problem. But this article is just asking us to think about the human relationships in our work, and to hold back on knee-jerk feedback.
  - deleted 5y ago
    [deleted]
idiotie 5y ago
https://kg.dev/thoughts/i-love-you-hn-but-youre-toxic https://kg.dev/thoughts/i-love-you-hn-but-youre-toxic Related
- oars 5y ago
  This is a fantastic post, thank you. I tend to do this in my everyday life and realised it recently. I hope I can slowly change and get rid of this trait.
lr4444lr 5y ago
I just don't agree. Much better to set a culture where people are encouraged to put their ego aside and accept being corrected immediately and politely. The repetition and fast iteration is good for learning.
- chernevik 5y ago
  This. Let's please not make engineering another field where our first concern is whose feelings are hurt. There are, of course, better and worse ways to raise concerns. "Why did you do it this way? It seems to me that . . . " leaves the conversation open to the possibility that there is good reason for something you don't understand. And if there are major problems, it might be better to privately approach someone (and/or their supervisor?) rather than torching them in public. But if there is a problem, you aren't doing anyone any favors by keeping quiet.
  - whatshisface 5y ago
    If you're talking to workers from another company, they're going to be bound by what I can only call "loyalty" to not tell you why it happened (what are they going to say, "we think our boss is dumb and he made us do this?") and instead will make up reasons, doubling down on it and starting an argument where one side has a duty to be disingenuous. It's a mess, don't start it.
  - HWR_14 5y ago
    Whether someone's feelings are hurt should be a primary concern. That doesn't mean you cannot correct people making errors, you definitely should. But if you're hurting people's feelings regularly you are bad at providing feedback. I notice the only "softening" of the message you suggest is to allow pushback if you happen to be wrong. It seems you are more likely to cause persistent fixes by treating people as people and correcting them in a way that doesn't hurt their feelings. I guess what I'm saying is that "hurt feelings" is most often a result of how feedback is provided, not what feedback or even how much feedback.
    - alexashka 5y ago
hinkley 5y ago
A particular flavor of this I've become familiar with over the last few years deals with how you enumerate problems rather than bringing up a single one. It is, I think, a variant of Burying the Lede where you start out with the serious issue, but then you keep going on and on for so long that eventually everyone forgets that the first point you brought up was "The building is on fire." Sometimes the lede should go at the end, be repeated at the end, or you should keep your comments to what can fit comfortably into short term memory. No flooding.
- whatshisface 5y ago
  When you're burying something, the dirt gets shoveled on after it's put in the hole, so what you're describing might actually still be described as "burying" the lede.
cespare 5y ago
Another problem with reflexively pointing out something wrong is that it's easy to be mistaken when you're hasty. Then you have the walk back the criticism and admit you were wrong. (Or double down and quibble about what exactly you meant, if you're that kind of asshole. Dealing with these folks is very tiresome.) This is a big reason why batch-based code review systems are great. I can quickly work through a pull request and point out every little thing that I notice because it's all a draft. Then I go back through and review my review. Sometimes things that I thought were problems are just things I didn't understand yet. Sometimes things I pointed out initially aren't even worth bringing up. And for the remaining points I can check that my feedback has the right tone and will come across well. I really miss this cycle when I need to use something like google docs as a feedback mechanism, where all the comments I leave are immediately mailed out. Slack is another system that encourages hasty responses. My critical feedback is better when I'm writing up an email and not participating in a realtime conversation.
kazinator 5y ago
Never point out something is wrong immediately. Immediately set off to work on a secret rewrite, and then point out what is wrong in a big commit sent to the review system 17 weeks later!
TedShiller 5y ago
This advice is wrong
darepublic 5y ago
What matters is you have fun and play nice
boulos 5y ago
I don't remember if it's a quote from Kahneman or Tversky, but I always liked the idea of asking "Hmm. That's not right, but what is it true of?" instead. [IIRC, it's mentioned in Thinking, Fast and Slow].
_9omd 5y ago
Yes, please don't be that guy. I was a lead at the last startup I was at, and we hired a guy who loved to point out everything we were doing "wrong". Literally weeks into the job and he's already writing up huge docs about everything we need to improve, with having almost no context for why we made certain decisions. The majority of things he assumed to know better on we also knew better about, but there simply wasn't enough time and man power to do things in the "right" way. He also pointed out some things that we were unaware of, but he had already tarnished his reputation by being so abrasive about the critique while putting so little time into understanding. Now the twist in this story, is that through this interaction, I reflected on a past job and realized that I had been that guy once! That sure was a moment of personal cringe. It's cemented into my brain how important it is to ask questions to fully understand the context decisions are made in before chiming in to say how wrong they are.
- ad-astra 5y ago
  There needs to be between 3 months to 1yr of onboarding before going in & trying to change everything. I always remind myself of this when starting new roles. One time my old team hired a hotshot in the gaming industry that came in trying to change everything in the first 2 weeks. It rubbed everyone the wrong way. He had a habit of interrupting one of the women on our team way more often than any of the men on the team. We ended up letting him go. If he would have just shut up and listened, he’d probably end up being a fine addition to the team (assuming he wasn’t actually sexist). What always sticks with me is that in retrospect, most of the changes he was advocating for were good ideas…
- mhitza 5y ago
  I've been that engineer at a particular time in my career. And saw others be that person as well, since. In my view, commonality between I and others I've known with that behavior was that we came from a long multi-year project. After experiencing daily maintenance of big projects for a couple of years, you tend to have a strong opinion of things you don't want to see again when moving for greener pastures. It just seems to disappear with time. Maybe because at some point people accept that telling others what to avoid is pointless, people tend to learn only from their own mistakes.
- 5y ago
drbojingle 5y ago
Ought to be in the junior developers handbook.
Melatonic 5y ago
Instead of pointing out why I think something is wrong I just starting asking questions dancing around the subject. A lot of times it comes down to just getting to "What problem are we trying to solve here?" Many times the original person might have made some small assumption and then that filters down and causes the current situation to be "wrong". Or maybe I am making the wrong assumption and I simply need to understand what the problem is, at its simplest, that we are all working together to find a solution for.
deleted 5y ago
[deleted]
ridaj 5y ago
Yes. My tips for this * Say yes first. Acknowledge everything and say what you agree with. * Use the phrase "tell me more." Use this to get context in a nonconfrontational way (as opposed to "why" which can get people in defensive mode). * Avoid using "but". People don't like to hear it and it makes them forget the past before it. Everytime you want to use but, see if you can use "and" or "at the same time", or nothing, and almost always the result is better.
buu700 5y ago
This seems like a complementary idea to "Willingness to look stupid": https://news.ycombinator.com/item?id=28942189 https://news.ycombinator.com/item?id=28942189 Rather than jump to calling out something as wrong, it can be helpful for mutual understanding to first ask questions framed in the terms of the apparent misconception, even if it sounds wrong to your mind or risks making you look stupid. Sometimes you'll find that there was actually no mistake, and other times you may make a positive contribution in a way that's more collaborative than adversarial.
philsnow 5y ago
This "blue tape walkthrough" approach is one concrete way of introducing the delay between stimulus (hearing/seeing something obviously wrong) and response ("correcting" them on it): https://randsinrepose.com/archives/the-blue-tape-list/ https://randsinrepose.com/archives/the-blue-tape-list/ > It’s a surprise when a month passes, and you review your blue tape list and discover how items that seemed urgent at the time now seem entirely irrelevant.
- hguant 5y ago
  I, like a lot of other nerds, play Magic the Gathering[0], specifically cEDH[1]. This process really speaks to my deck building process - after coming up with my archetype, color pie [2], and win conditions, I grab everything that I think could be applicable, and throw it in a pile. Then, on my first pass, I sort into yes, no, and maybe. Invariably, I end up throwing out all of the cards in the maybe pile, but the process of taking it aside, considering it, thinking "this could work", then coming back with fresh eyes struck me as similar to this process you've described. [0] for those of you who don't know, MtG is a card game for two or more players who have a 'library' of cards they draw from, and play. It has a very simple premise - win the game by reducing your opponent's life total to 20, removing all the cards from their library, or playing a card that says that you win the game - and an insane amount of complexity; for example, one of the standard variants is provably Turing complete using the base rule set. [1] One of the reasons for the longevity of MtG (been going strong since 1993) is that there are many variants of the standard rules that allow for a wide variety of play. Standard uses only the most recently released card lists, while Vintage lets you play with (almost) any card ever printed. cEDH stands for competitive Elder Dragon Highlander, which is a format where you have a 100 card library that has no repeating cards ("there can only be one!"), and they all have to share colors with a chosen 'commander'. [2] MtG mechanically uses cards called 'lands' to produce a resource called 'manna'. Manna is used to pay for spells, which when resolved have some effect on the game state. Spells have color - 3 blue, for example - which can only be payed for by appropriately colored manna. There are 5 colors of manna, and each color is associated with different types of spells. Red is fast and aggressive, green is ponderous but mighty, etc.
accountLost 5y ago
I can't agree with that. If there is something wrong, it must be dealt with as soon as possible. We engineers must learn to be professional and not let our ego get in the way. Maybe it is a cultural thing ? I worked once in Germany and thought at first that the error pointing was brutal. But you get used to it and learn not to involve your self esteem. And retrospectively I found it to be a fair and effective work environment.
- jen729w 5y ago
  It depends on the context. Just yesterday I was doing a data centre audit with a colleague, who is many years my junior, and I am her manager, and she has hardly been in a data centre. She’s also amazing by the way. So when I see her doing a few things that I wouldn’t have done, I could have just reacted and pointed it out and told her how it should be done. For sure I wanted to, I’m an engineer! Or I can have a bit of trust that, given a minute and a few more repetitions, she’ll get it. Which she did. And now she’s learned something, and now I’m not “that guy”, and now we have a better relationship, and so on. I appreciate that this might not be the sort of thing you had in mind. If there’s an error in code that isn’t going away if someone doesn’t say something then, sure, say something.
  - accountLost 5y ago
    Yes, when possible it is better to give people time to figure out things by themselves. That's how you learn. The question is why pointing out something wrong would have automatically damaged your relationship with her ? Everyone can agree that making mistake is natural. Can't people learn not to get upset when being told they made one ? One way is by exposure in an environment where the feedback is factual and without drama.
    - jen729w 5y ago
      I would have had no problem pointing the wrong thing out if she hadn't 'got it' herself, but I knew she would. The thing to avoid here is being the know-it-all who tells everyone how things should be done when, given just a second, those people would figure it out anyway. Nobody likes that guy.
barrenko 5y ago
Most human systems would rather fail together than succeed. Most systems are built for nothing but subsequent failure (even if it's 300 years into the future). Think about that.
- csouza-f 5y ago
  Where did you got that? Is some reference? Did you mind to share?
abel_ 5y ago
Completely disagree. I agree that the _delivery_ is important, but the interval between when discovering a problem and announcing it should be minimal. There's a huge difference between maintaining the social etiquette of allowing your conversationalist to explain themselves fully, and waiting a little while before announcing a problem. Announcing right away in a respectful manner also let's you get a correction right away.
smbl64 5y ago
The TED talk referred to in the article is quite interesting: https://www.youtube.com/watch?v=-moW9jvvMr4 https://www.youtube.com/watch?v=-moW9jvvMr4
sAbakumoff 5y ago
Right, real freedom is the ability to pause between stimulus and response, and in that pause, choose.
Kaze404 5y ago
It's also important to realize when you shouldn't point it out at all. Sometimes you just have to make that text blue on a yellow background.
svilen_dobrev 5y ago
the more stupid it sounds.. the deeper it goes. https://journals.biologists.com/jcs/article/121/11/1771/30038/The-importance-of-stupidity-in-scientific-research# https://journals.biologists.com/jcs/article/121/11/1771/3003...
lukaslalinsky 5y ago
Just be careful, because, as a manager, you can easily lose your best people, if they constantly have to review bad code from "productive" junior developers, need to manage how/when to deliver the review and then they are expected to work on the same code-base. This needs to be balanced.
roeles 5y ago
One of the better lessons I had to learn at work was: sometimes small things have to go wrong in order to make big things go right.
IMAYousaf 5y ago
Letting people make mistakes is a charitable thing to do if you're in a good environment. It's also a tactical thing to do in an adverse one. Understanding the balance of those two will help you gamify your own value more.

371 points by uvdn7 5y ago

I emphatize with people who point out flaws immediately. Because some people have the habit of dominating discussions or steering discussion away that paints them in a negative light.

foreigner 5y ago

Even harder for me is to remember that someone telling me about their problem is not a request for me to help solve it.

draw_down 5y ago

joseph8th 5y ago

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 5y ago
I appreciate the sentiments. i think the cert for https://cieloconnects.com/ https://cieloconnects.com/ is expired.
- jodrellblank 5y ago
  It isn’t expired, look more closely at it. (And, cough, see thread topic)
  - boldslogan 5y ago
    Maybe saying something like hey we’re you aware the browser throws this error NSURLErrorServerCertificateUntrusted To point out the issue but maybe not say exactly what was wrong?
  - fjorde 5y ago
    take your own advice. i noticed a cert was invalid or broken and mentioned it to a person who might care or know how to deal with it appropriately. In the meantime the site is less secure than it could presumably be. i'm not a paid consultant for the site so i didn't bother digging in and finding out which policy violation triggered a browser warning, but since you did, you can share it here or you can continue to add zero-value comments.
    - jodrellblank 5y ago
      How did you even find that site in the first place? It's not in their profile, it's not in the top duckduckgo results for "CIELO Enterprise Solutions". How long were you digging around to find something, anything, to try and pwn them about their high engineering standards comment?
      - fjorde 5y ago
        Perhaps there is a language or nuance barrier. I "thanked" the parent commenter for sharing their view, did an "internet search" for their publicly listed company to see what kind of jobs they might have available, and then was warned about certs visiting their site... Now I'm having a terrible conversation with you for some reason, but I hope this helps dispel your confusion. Please feel free not to reply at all with anything.
        deleted 5y ago
        [deleted]
- joseph8th 5y ago
  Ah look at that! Nice catch. Yes, I can see that something is done to fix that, though I'm not on that team (I'm backend). And to address the debate below, I do in fact appreciate risk-averse and focused engineers. The 'don't say no' thing I think has merit when interfacing with business. But within the team, as long as you're in your own lane I appreciate it very, very much when my coworkers help me find flaws. Most of this comes up in planning anyway, when we're spit-balling best approaches. If the problem is difficult enough, someone will get a research spike to discover best practices and form a set of initial proposals and alternatives. ETA: and yes this is my public profile. I don't mind. I'm proud of my work at CIELO.

gmfawcett 5y ago

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 5y ago
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 5y ago
  > 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.
  - jka 5y ago
    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.
    - hinkley 5y ago
      > Can this technical decision be reversed easily? One of the most exhausting failure modes that I've had to deal with is deciding not to decide. Some people will build elaborate Rube Goldberg machines so that they "can change their minds later" but in fact what they've done is decided that choices are now everybody else's problems. There's a whole hell of a lot of rewards to having the maturity to be able to say "I was wrong" and move on. Writing code in a way that you could rework it to use a different library to accomplish the same thing is making a reversible decision. Creating a rules engine to let a config file make the choices and leaving a cartesian product of states (75% of which are invariably illegal, which you are just supposed to know) is definitely, definitely not. Just pick something, man.

kodah 5y ago

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 5y ago
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.
- sitkack 5y ago
  One has to be very careful with socratic techniques, they can quickly become trite, patronizing and segue nicely into splaining. They are extremely useful and help give space to the state of things, but if the people you are interacting with ever felt like they are being led down a garden path, it can feel like a big setup to getting owned. This advise comes from working on teams where the socratic method was used as a setup for being made a fool.
rocqua 5y ago
Empathy applies in two ways. Firstly in realizing that saying 'you are wrong' is hurtful and can be damaging to relationships. Secondly in realizing that other people might already know your objection, but had reasons for proceeding this way anyway.
- kodah 5y ago
  I'd argue that "you are wrong" can be hurtful, rather than is. It's all about delivery, the culture/environment you're in, and how receptive a person is to negative feedback. The second point is a great way to encourage silencing dissent. Interrogating why people made decisions is part of both science and engineering. Assuming they made all the right choices sounds odd to me.

the_duke 5y ago

This 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.

johnwalkr 5y ago
I’m always surprised at “refusal to work together.” The entire point of a company is to organize people to work together, how do workers like that get promoted?
- pavs 5y ago
  This happens so often, I am surprised that anyone gets surprised by this at all. The entire point of a company is to make money, with the people/resources they have. More often then not what they want is not the best available to them. Most people are horrible, managing a bunch of highly egotistic but talent people is hard.
- 0x008 5y ago

deleted 5y ago

[deleted]

rav 5y ago

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!

hinkley 5y ago
Coherent But Wrong is a known failure mode for architecture. All of the parts make sense when taking in context of all of the other parts, but when you step out of the system the whole thing seems a little nuts. It's basically the Echo Chamber (circular reasoning) condensed into code.

hyperpallium2 5y ago

Chesterton's Fence https://wiki.lesswrong.com/wiki/Chesterton%27s_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

stellar_rocket 5y ago
The Chesterton Fence AKA an undocumented obstacle from the perspective of anyone new. Of course we need to understand the system before changing it. But we shouldn't browbeat those wanting to improve the stuff we left no guidance about.
SpaghettiX 5y ago
What's the difference between this and "don't change things you don't understand". It would make it clearer that this is a type of approach rather than a law. Sometimes, that legacy system or class is replaced without fully understanding it, because it's cheaper to reimplement it's interface than fix it.
- yxhuvud 5y ago
  What happens then though, is that the replacement take a lot longer than expected, because it turns out that the complexity in the old system had more motivation than expected and had a lot more problems it solved than was obvious. Fixing these issues then make the new system into almost as big of a problem as the old one, with the only difference in that now you at least have some people that understands it. For a while until enough people have left to again forget the workings of the system. Sometimes the easiest way for a company to relearn about a problem space is to rewrite it though, so it is not necessarily a bad thing to do. It can also be that the market has shifted and some of the complexity in the old system was no longer necessary, so the new system ends up easier. In any case, spending time understanding the existing system (including developers that point out corner cases and nonobvious cases) make the end result so much easier than adjusting a solution to handle a complication angle that wasn't part of the original plan.
- hyperpallium2 5y ago

SideburnsOfDoom 5y ago

> "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 5y ago
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.
- SideburnsOfDoom 5y ago
  > I think the second example is probably meant more as ‘point out flaws’. OK, that seems likely, but why use a word "spot" that does not mean "to point out" ? The distinction is clear here: https://dictionary.cambridge.org/dictionary/english/spot https://dictionary.cambridge.org/dictionary/english/spot Spot: "to see or notice someone or something, usually because you are looking hard" e.g. "If you _spot_ any mistakes in the article just _mark_ them with a pencil."
financetechbro 5y ago
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
- arvinsim 5y ago
  > The author is just giving an example on how engineers have a habit of pointing out flaws It's strange that finding flaws is framed negatively. This ability is a positive trait in software development.

imwillofficial 5y ago

I’m super bad at this, great advice.

pavon 5y ago

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 5y ago

"Think before you speak."

emptybottle 5y ago

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 5y ago

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 5y ago

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.

sibeliuss 5y ago

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.

hughrr 5y ago

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.

jaimex2 5y ago

If you're not dealing with an adult sure. Not all grown up people are adults.

draw_down 5y ago

the_duke 5y ago

donatj 5y ago

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.

bfung 5y ago
s/old/experienced/ It took a realization myself that my 20 year accumulated knowledge, insights, skills, mental models is not something most college grads can grasp (there are very, very few exceptions). And telling them verbally doesn’t help either. Ex: due to that experience, I can pick up any language & ecosystem and be productive in 3 days max (from js to c++ to haskell). I can’t expect that from a bootcamper or new grad.
deleted 5y ago
[deleted]
eatonphil 5y ago
Lucky for you both to have a good manager!

crisdux 5y ago

There certainly is a balance to giving feedback like this. It very much depends on team dynamic and the level of trust between team members. I have experienced lower levels of trust and worsen proficiency in giving and receiving feedback described in this article since the whole WFH thing started, especially as teams at my employer change and we bring on new team members. People are a lot more sensitive, everyone collaborates less and we are accepting a lot of bad code into our projects than ever before. We had about 1/3 of a crucial team leave recently. At their exit interviews they all described how one of the reasons they left is because the code base has turned into a pile of junk and no one wants to work on it. I recently agreed to join this team to help turn it around because I have a reputation for ensuring good engineering practices and giving feedback is a strength of mine. But boy, this environment is challenging with developers all working from home. I'm curious if this resonates with anyone else, specifically if others have similar experiences with wfh.

nine_zeros 5y ago
I have something similar. We have a "blameless" culture which is nice. Genuinely appreciate it because people do make mistakes. But our codebase has become progressively worse because nobody tells the truth about their experience. There are teams making bad choices which throw other teams off the cliff. Sometimes product managers come up with elaborate projects without due diligence only to waste 6 months of engineering time. Because of such activities, engineers lost faith in their team/org. They just coast or switch teams/companies or straight up lie to management. There is zero incentive for anyone to improve anything because pointing something out is bad for "optics".

zachrip 5y ago

I recall one of my interns telling me they would never sacrifice quality of code for anything else. When they left I asked them if they still felt the same. They said they had a new understanding for why that may not always be the case. Be like my previous intern.

giantg2 5y ago

I generally wait for the their thought to be completed, to see where they are going with it. I do this on the assumption that I could be wrong and they might know more than me.

ummonk 5y ago

I know that engineers aren’t the most socially adept bunch, but it’s still weird how someone can go this long before having to realize that personal feedback needs to be delivered appropriately because people have emotions and aren’t just programs to be dissected like in a line by line code review.

simongray 5y ago
While I recognise that engineers do this a lot, other people certainly do it too. Whenever I present any GUI work to other people (future users) they rarely consider the big picture, but just nitpick some tiny things in a stream-of-consciousness way because it makes them feel like they contributed to the process somehow. Building a UI that pleases most people is challenging and people do not appreciate the hard work (design and engineering) that goes into it, I find, preferring to turn user feedback sessions into nitpicking sessions every time. Usually they are plain wrong too, for the same reasons outlined in this article (e.g. there is a requirement they did not consider).

unnouinceput 5y ago

Pointing wrongs is for noobs. An expert hoards them like CIA/NSA hoards zero days and you deliver them on the day of performance review.

sgjohnson 5y ago
But this benefits absolutely nobody. Not even the manager doing that. I know that in my workplace a manager would get chewed out for that, as this practice is explicitly banned by policy. Any issues should be raised the moment they are discovered. Even without the said policy, it doesn’t benefit the business, because if it’s a problem employee, you’re pointlessly keeping them on a payroll, and it doesn’t benefit the employee, because if you hit them with everything at once, little of it will resonate with them.
- xxs 5y ago
  I guess the comment (GP) was sarcastic (you can tell but the opening phrase alone)

kashkhan 5y ago

And that's why Challenger blew up. Don't work with people who cant handle being wrong and fixing it.

quicksnap 5y ago
It's not about people not handling being wrong, but about introspecting on how we deliver feedback. If people cannot take feedback or accept flaws in their work, that certainly is a problem. But this article is just asking us to think about the human relationships in our work, and to hold back on knee-jerk feedback.
- deleted 5y ago
  [deleted]

idiotie 5y ago

https://kg.dev/thoughts/i-love-you-hn-but-youre-toxic https://kg.dev/thoughts/i-love-you-hn-but-youre-toxic Related

oars 5y ago
This is a fantastic post, thank you. I tend to do this in my everyday life and realised it recently. I hope I can slowly change and get rid of this trait.

lr4444lr 5y ago

I just don't agree. Much better to set a culture where people are encouraged to put their ego aside and accept being corrected immediately and politely. The repetition and fast iteration is good for learning.

chernevik 5y ago
This. Let's please not make engineering another field where our first concern is whose feelings are hurt. There are, of course, better and worse ways to raise concerns. "Why did you do it this way? It seems to me that . . . " leaves the conversation open to the possibility that there is good reason for something you don't understand. And if there are major problems, it might be better to privately approach someone (and/or their supervisor?) rather than torching them in public. But if there is a problem, you aren't doing anyone any favors by keeping quiet.
- whatshisface 5y ago
  If you're talking to workers from another company, they're going to be bound by what I can only call "loyalty" to not tell you why it happened (what are they going to say, "we think our boss is dumb and he made us do this?") and instead will make up reasons, doubling down on it and starting an argument where one side has a duty to be disingenuous. It's a mess, don't start it.
- HWR_14 5y ago
  Whether someone's feelings are hurt should be a primary concern. That doesn't mean you cannot correct people making errors, you definitely should. But if you're hurting people's feelings regularly you are bad at providing feedback. I notice the only "softening" of the message you suggest is to allow pushback if you happen to be wrong. It seems you are more likely to cause persistent fixes by treating people as people and correcting them in a way that doesn't hurt their feelings. I guess what I'm saying is that "hurt feelings" is most often a result of how feedback is provided, not what feedback or even how much feedback.
  - alexashka 5y ago

hinkley 5y ago

A particular flavor of this I've become familiar with over the last few years deals with how you enumerate problems rather than bringing up a single one. It is, I think, a variant of Burying the Lede where you start out with the serious issue, but then you keep going on and on for so long that eventually everyone forgets that the first point you brought up was "The building is on fire." Sometimes the lede should go at the end, be repeated at the end, or you should keep your comments to what can fit comfortably into short term memory. No flooding.

whatshisface 5y ago
When you're burying something, the dirt gets shoveled on after it's put in the hole, so what you're describing might actually still be described as "burying" the lede.

cespare 5y ago

Another problem with reflexively pointing out something wrong is that it's easy to be mistaken when you're hasty. Then you have the walk back the criticism and admit you were wrong. (Or double down and quibble about what exactly you meant, if you're that kind of asshole. Dealing with these folks is very tiresome.) This is a big reason why batch-based code review systems are great. I can quickly work through a pull request and point out every little thing that I notice because it's all a draft. Then I go back through and review my review. Sometimes things that I thought were problems are just things I didn't understand yet. Sometimes things I pointed out initially aren't even worth bringing up. And for the remaining points I can check that my feedback has the right tone and will come across well. I really miss this cycle when I need to use something like google docs as a feedback mechanism, where all the comments I leave are immediately mailed out. Slack is another system that encourages hasty responses. My critical feedback is better when I'm writing up an email and not participating in a realtime conversation.

kazinator 5y ago

Never point out something is wrong immediately. Immediately set off to work on a secret rewrite, and then point out what is wrong in a big commit sent to the review system 17 weeks later!

TedShiller 5y ago

This advice is wrong

darepublic 5y ago

What matters is you have fun and play nice

boulos 5y ago

I don't remember if it's a quote from Kahneman or Tversky, but I always liked the idea of asking "Hmm. That's not right, but what is it true of?" instead. [IIRC, it's mentioned in Thinking, Fast and Slow].

_9omd 5y ago

Yes, please don't be that guy. I was a lead at the last startup I was at, and we hired a guy who loved to point out everything we were doing "wrong". Literally weeks into the job and he's already writing up huge docs about everything we need to improve, with having almost no context for why we made certain decisions. The majority of things he assumed to know better on we also knew better about, but there simply wasn't enough time and man power to do things in the "right" way. He also pointed out some things that we were unaware of, but he had already tarnished his reputation by being so abrasive about the critique while putting so little time into understanding. Now the twist in this story, is that through this interaction, I reflected on a past job and realized that I had been that guy once! That sure was a moment of personal cringe. It's cemented into my brain how important it is to ask questions to fully understand the context decisions are made in before chiming in to say how wrong they are.

ad-astra 5y ago
There needs to be between 3 months to 1yr of onboarding before going in & trying to change everything. I always remind myself of this when starting new roles. One time my old team hired a hotshot in the gaming industry that came in trying to change everything in the first 2 weeks. It rubbed everyone the wrong way. He had a habit of interrupting one of the women on our team way more often than any of the men on the team. We ended up letting him go. If he would have just shut up and listened, he’d probably end up being a fine addition to the team (assuming he wasn’t actually sexist). What always sticks with me is that in retrospect, most of the changes he was advocating for were good ideas…
mhitza 5y ago
I've been that engineer at a particular time in my career. And saw others be that person as well, since. In my view, commonality between I and others I've known with that behavior was that we came from a long multi-year project. After experiencing daily maintenance of big projects for a couple of years, you tend to have a strong opinion of things you don't want to see again when moving for greener pastures. It just seems to disappear with time. Maybe because at some point people accept that telling others what to avoid is pointless, people tend to learn only from their own mistakes.
5y ago

drbojingle 5y ago

Ought to be in the junior developers handbook.

Melatonic 5y ago

Instead of pointing out why I think something is wrong I just starting asking questions dancing around the subject. A lot of times it comes down to just getting to "What problem are we trying to solve here?" Many times the original person might have made some small assumption and then that filters down and causes the current situation to be "wrong". Or maybe I am making the wrong assumption and I simply need to understand what the problem is, at its simplest, that we are all working together to find a solution for.

deleted 5y ago

[deleted]

ridaj 5y ago

Yes. My tips for this * Say yes first. Acknowledge everything and say what you agree with. * Use the phrase "tell me more." Use this to get context in a nonconfrontational way (as opposed to "why" which can get people in defensive mode). * Avoid using "but". People don't like to hear it and it makes them forget the past before it. Everytime you want to use but, see if you can use "and" or "at the same time", or nothing, and almost always the result is better.

buu700 5y ago

This seems like a complementary idea to "Willingness to look stupid": https://news.ycombinator.com/item?id=28942189 https://news.ycombinator.com/item?id=28942189 Rather than jump to calling out something as wrong, it can be helpful for mutual understanding to first ask questions framed in the terms of the apparent misconception, even if it sounds wrong to your mind or risks making you look stupid. Sometimes you'll find that there was actually no mistake, and other times you may make a positive contribution in a way that's more collaborative than adversarial.

philsnow 5y ago

This "blue tape walkthrough" approach is one concrete way of introducing the delay between stimulus (hearing/seeing something obviously wrong) and response ("correcting" them on it): https://randsinrepose.com/archives/the-blue-tape-list/ https://randsinrepose.com/archives/the-blue-tape-list/ > It’s a surprise when a month passes, and you review your blue tape list and discover how items that seemed urgent at the time now seem entirely irrelevant.

hguant 5y ago
I, like a lot of other nerds, play Magic the Gathering[0], specifically cEDH[1]. This process really speaks to my deck building process - after coming up with my archetype, color pie [2], and win conditions, I grab everything that I think could be applicable, and throw it in a pile. Then, on my first pass, I sort into yes, no, and maybe. Invariably, I end up throwing out all of the cards in the maybe pile, but the process of taking it aside, considering it, thinking "this could work", then coming back with fresh eyes struck me as similar to this process you've described. [0] for those of you who don't know, MtG is a card game for two or more players who have a 'library' of cards they draw from, and play. It has a very simple premise - win the game by reducing your opponent's life total to 20, removing all the cards from their library, or playing a card that says that you win the game - and an insane amount of complexity; for example, one of the standard variants is provably Turing complete using the base rule set. [1] One of the reasons for the longevity of MtG (been going strong since 1993) is that there are many variants of the standard rules that allow for a wide variety of play. Standard uses only the most recently released card lists, while Vintage lets you play with (almost) any card ever printed. cEDH stands for competitive Elder Dragon Highlander, which is a format where you have a 100 card library that has no repeating cards ("there can only be one!"), and they all have to share colors with a chosen 'commander'. [2] MtG mechanically uses cards called 'lands' to produce a resource called 'manna'. Manna is used to pay for spells, which when resolved have some effect on the game state. Spells have color - 3 blue, for example - which can only be payed for by appropriately colored manna. There are 5 colors of manna, and each color is associated with different types of spells. Red is fast and aggressive, green is ponderous but mighty, etc.

accountLost 5y ago

I can't agree with that. If there is something wrong, it must be dealt with as soon as possible. We engineers must learn to be professional and not let our ego get in the way. Maybe it is a cultural thing ? I worked once in Germany and thought at first that the error pointing was brutal. But you get used to it and learn not to involve your self esteem. And retrospectively I found it to be a fair and effective work environment.

jen729w 5y ago
It depends on the context. Just yesterday I was doing a data centre audit with a colleague, who is many years my junior, and I am her manager, and she has hardly been in a data centre. She’s also amazing by the way. So when I see her doing a few things that I wouldn’t have done, I could have just reacted and pointed it out and told her how it should be done. For sure I wanted to, I’m an engineer! Or I can have a bit of trust that, given a minute and a few more repetitions, she’ll get it. Which she did. And now she’s learned something, and now I’m not “that guy”, and now we have a better relationship, and so on. I appreciate that this might not be the sort of thing you had in mind. If there’s an error in code that isn’t going away if someone doesn’t say something then, sure, say something.
- accountLost 5y ago
  Yes, when possible it is better to give people time to figure out things by themselves. That's how you learn. The question is why pointing out something wrong would have automatically damaged your relationship with her ? Everyone can agree that making mistake is natural. Can't people learn not to get upset when being told they made one ? One way is by exposure in an environment where the feedback is factual and without drama.
  - jen729w 5y ago
    I would have had no problem pointing the wrong thing out if she hadn't 'got it' herself, but I knew she would. The thing to avoid here is being the know-it-all who tells everyone how things should be done when, given just a second, those people would figure it out anyway. Nobody likes that guy.

barrenko 5y ago

Most human systems would rather fail together than succeed. Most systems are built for nothing but subsequent failure (even if it's 300 years into the future). Think about that.

csouza-f 5y ago
Where did you got that? Is some reference? Did you mind to share?

abel_ 5y ago

Completely disagree. I agree that the _delivery_ is important, but the interval between when discovering a problem and announcing it should be minimal. There's a huge difference between maintaining the social etiquette of allowing your conversationalist to explain themselves fully, and waiting a little while before announcing a problem. Announcing right away in a respectful manner also let's you get a correction right away.

smbl64 5y ago

The TED talk referred to in the article is quite interesting: https://www.youtube.com/watch?v=-moW9jvvMr4 https://www.youtube.com/watch?v=-moW9jvvMr4

sAbakumoff 5y ago

Right, real freedom is the ability to pause between stimulus and response, and in that pause, choose.

Kaze404 5y ago

It's also important to realize when you shouldn't point it out at all. Sometimes you just have to make that text blue on a yellow background.

svilen_dobrev 5y ago

the more stupid it sounds.. the deeper it goes. https://journals.biologists.com/jcs/article/121/11/1771/30038/The-importance-of-stupidity-in-scientific-research# https://journals.biologists.com/jcs/article/121/11/1771/3003...

lukaslalinsky 5y ago

Just be careful, because, as a manager, you can easily lose your best people, if they constantly have to review bad code from "productive" junior developers, need to manage how/when to deliver the review and then they are expected to work on the same code-base. This needs to be balanced.

roeles 5y ago

One of the better lessons I had to learn at work was: sometimes small things have to go wrong in order to make big things go right.

IMAYousaf 5y ago

Letting people make mistakes is a charitable thing to do if you're in a good environment. It's also a tactical thing to do in an adverse one. Understanding the balance of those two will help you gamify your own value more.