Live data from Hacker News

Don’t point out something wrong immediately

blog.the-pans.com

41–50 of 180 posts

Re: Don’t point out something wrong immediately

#41
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…

When I was a strategy consultant there were only two important lessons to learn:

1. Be a manager. You are not there to be their friend. You are there because they are horrible and their leadership needs you to clean up the trash. If you are not there as some form of management with a title and ownership you will quickly become their bitch, which leads to my second learning.

2. Don't get sidelined. As an outsider operating under contract the problem people want you gone but cannot remove you. Their best weapon is to sideline you. If they cannot own you they will ignore you. They will rearrange their meeting schedules and ensure you are not invited. They will create and release prototypes and delivery plans without your involvement. They will write reports and opinions to their management with all kinds of complaints and fictions and you have nothing because you are out of the game.

Re: Don’t point out something wrong immediately

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

Re: Don’t point out something wrong immediately

#43
post #10
post #5

Earlier quoted context omitted.

Even with a code review, though, you might want to wait until you’ve digested the rest of the review instead of firing off a comment. Maybe it makes sense in context. Or maybe there are bigger fish to fry and it’s not worth quibbling over small things.

> Or maybe there are bigger fish to fry and it’s not worth quibbling over small things. I've taken this approach with one of our engineers, and now we have a huge pile of "small things" that has created some pretty serious technical debt. My perception is that they don't try to understand what I'm pointing out, and come up with rational for how they have it. I think I have a lot to learn.

I have found personally only pair programming with people regularly is the only way you can avoid adding lots of technical debt.

Technical debt isn't always avoidable, but I sure know the difference from when teams are heavily invested in pair programming vs not.

Good pair programming is hard to ingrain in a culture though.

Re: Don’t point out something wrong immediately

#44
post #42

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

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

Re: Don’t point out something wrong immediately

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

Re: Don’t point out something wrong immediately

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

Re: Don’t point out something wrong immediately

#48
post #39
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…

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 cue 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 or correction.

The problem with this heuristic is that every nontrivial piece of software contains something obviously stupid.

Which sounds like a refutation of the validity of this inference altogether, but—no, take heart: It still works, because it turns out every organization has a broken system or process or larger organizational dysfunction.

So in a sense yes, this logic works, but you can save yourself some steps.

Re: Don’t point out something wrong immediately

#49
post #28
post #24

Earlier quoted context omitted.

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!

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.

I also really like this feature of GitHub reviews and when deleting a comment as I continue reading I try to question whether to add a code comment so the next person doesn't get tripped up because they don't have the full context in their head.

Re: Don’t point out something wrong immediately

#50
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 practical way given the time we had and also it works" (kinda, if we don't count when it fails) argument, lure them in their teams, keep pushing out half baked solutions that they will then rewrite "to improve them" for karma points, wasting everybody's time and company money.

It works because there are always processes that are worse than bad software.

So bad software usually is not the worse thing you can find in a company and can always blame some other department for being horribly inefficient, everybody wins, salaries are paid every month and 2 years later nobody knows what "the thing" does and why.

But it's an excuse not not do better when it's possible.

a task that takes half an hour can't take 12 days and 6 meetings "so we can talk about it" they say, truth is they are simply pushing their view.

I get people are different and have different incentives, but we don't let people like me go into space just because we shouldn't point out a problem when we see it

Software development is about being as thorough as possible while also being flexible.

I always wonder why we keep asking people who see the problem to stay quiet while people causing them are encouraged to keep making them, so they can learn.

What if people doing the "wrong" thing start listening and do what they are told and if it doesn't work they can blame who said them they were wrong?

Saying no sometimes makes you the lonliest person in the office, but somebody gotta do it or nothing will ever change.

Post reply on HN