Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Don’t point out something wrong immediately

blog.the-pans.com

Post reply on HN
Print view View original

111–120 of 180 posts

Re: Don’t point out something wrong immediately

#111

Post by arvinsim »

financetechbro wrote: post #27
SideburnsOfDoom wrote: post #16

> "feel sad" -> "eat chocolate" -> "feel good" cycle. > For engineers, the cycle is "see a problem" -> "spot flaws" -> "feel good". Maybe I'm missing some aspect of the text? AFAIK, "feel sad" and "eat chocolate" are different things (with a cause and effect relationship) and "see a problem" and "spot flaws" are the same thing expressed in different words, so what's the cycle here?

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

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

Re: Don’t point out something wrong immediately

#112

Post by [deleted] »

quicksnap wrote: post #56
kashkhan wrote: post #53

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

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]

Re: Don’t point out something wrong immediately

#115

Post by galaxyLogic »

peoplefromibiza wrote: post #50
the_duke wrote: post #8

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 on…

> if you spot something "wrong", don't react immediately and don't interrupt. Let the other party finish. Make a note. Gather more information The problem is that people doing the " wrong" thing (with varying degrees of wrong, which I did too and still do) will think they are right, they will usually do a presentation of their solution to people that are less knowledgeable than they are to win the "this was the only…

I think it is most often wrong to use the word 'wrong'. That implies there is the right way and the wrong way. But in fact there are only better ways and worse ways, to do things.

The "right way" somebody envisions to be THE right way can be worse than something even better.

So instead of saying "Hey you are definitely doing it wrong" you can say "I can see an alternative way of doing this which might be better in some cases, for some purposes, for some users".

Re: Don’t point out something wrong immediately

#116

Post by accountLost »

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.

Re: Don’t point out something wrong immediately

#117

Post by simongray »

ummonk wrote: post #47

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.

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

Re: Don’t point out something wrong immediately

#118

Post by ad-astra »

_9omd wrote: post #87

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'…

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…

Re: Don’t point out something wrong immediately

#119

Post by jen729w »

accountLost wrote: post #116

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 en…

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.

Re: Don’t point out something wrong immediately

#120

Post by logicallee »

hinkley wrote: post #51
the_duke wrote: post #8

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 on…

> we never got the time to fix it The older I get the more convinced I become that this is Learned Helplessness. "We didn't have time." is essentially the same dodge as "C'est le guerre" was in France. "We don't have time" is a conversation killer. "We are working on that bit by bit" is essentially the same statement once you've subtracted the helplessness. Nobody is ever gonna schedule time for you to have integrity…

I actually really like the linked article ( https://blog.the-pans.com/wrong/ ), I think it is supportive of ideation and prototyping. It really made me glad to read that.

When learning a new language or environment, there's no place to get an expert to pair program through it (or is there?) Baby steps always look wrong, especially when the baby keeps falling over. It's just part of growing up.

Case in point I recently sent someone a (let's say) figma prototype but I decided to cobble it out of a production language I never used. (So, not actually figma.) It sort of worked but wasn't close to being real. I did it while I was waiting for my laundry to finish. I'm trying to think of how I would apply your standard to the figma wireframe.

If I focus my efforts on doing what you find acceptable, how do you think I should invest my next 200 hours? I have these alternatives:

- I'd like to finish reading the book Pro Git as git is the sine qua non most important tool of the trade and mastery would be very nice. I'm on github and can do basic operations but I think I would benefit from being a master.

- Improve my code demonstration's efficiency. I have a code demonstration up on my github at https://github.com/robss2020/dictionarysequences - I can improve it by approx. 75% with a few lines of code. This will just take a few debugging sessions.

- Redo the above in C. This would be so much fun for me because instead of fake pointers based on Python strings I can use real genuine C pointers to actual memory. And I can implement a hash lookup table that is so much fun. The result would scream with speed it will be 40x to 100x faster than my Python demonstration and I know enough C and C++ to do it perfectly. It's just a straightforward translation of the efficient python code, except C doesn't have a built in hash lookup like Python does so I get to implement one myself. This will let me add a demonstration of one of the most valuable skills, I can potentially use it in high-frequency trading applications (the skill of being able to wrangle efficient data structures in C). It is a massive source of value for me to demonstrate my proficiency in C.

- launch a statistical project. I have a statistics side project I could put work into launching. Right now I have no useable side project online, just my potfolio web site ( https://taonexus.com )

- Finish a technical writing article I started. This would be my portfolio project for technical writing.

My plan was just to do all of the above. First, finish reading pro git but not properly just enough to make sure I can look up what I need to, second improve my code sample but also not properly, just add some breakpoints and putz around to see if I can add the code I'm thinking of, if it works push to my github otherwise just discard it, third, do the translation to C but just cobble together existing libraries for the hash, don't reimplement it myself, fourth launch the statistical project based on cobbled together code, reduce the scope until it's trivial, and as for the technical writing project, use screenshots I've been saving and my final results or impressions just based on the ultimate outcome. Don't make it into a 10,000 word article, don't do further market research etc.

For each of these things, I could put in more time.

How do you think I should budget my time? My ultimate goal is that I am trying to change to a new job as a technical product manager (my resume is on the bottom of my site). Given my goals, how should I budget my time to become a better candidate?

I can't do all my plans your way but I'd be curious to know your feedback about how and where to invest my time.

Post reply on HN