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

Stop trying to engineer your way out of listening to people

ashley.rolfmore.com

Post reply on HN
Print view View original

91–100 of 305 posts

Re: Stop trying to engineer your way out of listening to people

#91

Post by exmadscientist »

atoav wrote: post #65
monegator wrote: post #48

Earlier quoted context omitted.

> about the same thing yes. I have to keep telling my colleagues "about what?" for about 4-5 times in a row, at least twice daily, until they finally realize they have to tell me which client, feature, product or whatever else they are referring to. Even if i know exactly what yhey are talking about.

If there is a tech-person problem it is this one. I constantly have to interrupt collegues when they try to explain a thing as their explaination attempts are usually way too low level or even bordering on being self-referential. So they explain the concept by using other concepts the listener won't understand either. In my opinion it all boils down to a lack of ability to remember how one felt before understanding a…

When I taught I often thought of it as explaining in a spiral: first I must go around the concept, before I can dive in to the concept. Going around gives boundary and definition to what I'm talking about, allowing people to place it in the proper spot in their mental framework and to relate it with other nearby things. It also gives some motivation for what this thing is and why they should care. Then when that is done (and it does not take long), the details can be discussed, and they're easier to communicate because people are primed to receive them.

Re: Stop trying to engineer your way out of listening to people

#92

Post by lelanthran »

nomel wrote: post #32
onion2k wrote: post #17

You assume what they say is the same as what they are thinking The converse is also true. People saying something assume that people listening are understanding and thinking about the same thing. This is why it's important to write things down in details and as-unambiguous-as-you-can forms. If you're in a meeting and someone puts up a slide deck with a 6 word bullet point that 'explains' what they want, that is a sig…

You also need to force them to justify their requirements, since asking for something way beyond what you actually need is an easy way to hide the fact that they don't understand what they actually need. In my experience, people like that asking for 10x the actual requirement is fairly usual. But, every once in a while you hear someone say "we should buy the best, so we don't have to worry about it in the future" (wh…

> You also need to force them to justify their requirements, since asking for something way beyond what you actually need is an easy way to hide the fact that they don't understand what they actually need.

I've had a lot of success by shortcutting the refinement/request sessions with clients by simply asking "What is it you need to do?".

Due to an esclation from a client, I joined a meeting with a dev and a client to try and figure out why a single report is taking over a month to deliver. Dev reported (privately) to me that the client keeps changing their mind about what needs to be in the final report.

When I finally asked the client my magic question, it turns out they may not even need that specific report anyway - they're just not sure what can be retrieved, so they wanted one single report for every single thing they may want to do, now and in the future, attempting to squish hierarchical data and tabular data from SQL queries into a single gigantic report.

There's no way the dev was ever going to have a finished report for them. I broke it down into several simpler reports, some of which already exist, which turned a very frustrated client into, well, not exactly happy, but at least they are less frustrated now. They have some of the data generated daily now, and we can do the other stuff as and when they see a need for those reports.

Re: Stop trying to engineer your way out of listening to people

#93

Post by lelanthran »

serial_dev wrote: post #59
generic92034 wrote: post #55

Earlier quoted context omitted.

> This is why it's important to write things down in details and as-unambiguous-as-you-can forms. While that might be a prerequisite for a deep shared understanding, I have made the experience in the last few years that the number of people really reading more than the starting sentence of any message/ticket/email is consistently decreasing. I often have to feed them the information in very small and easy to digest p…

Nobody reads the docs, tickets, or comments under a task, nobody really checks the code they are reviewing, and nowadays thanks to AI, some people don’t even read the code they “write”. People love to ask for documentation, as long as it doesn’t exist. It lets them off the hook, “oh I would have known what to do, I wish we had this documented”. Then you point it out that you have it documented with video walkthrough,…

> Managers ask detailed questions about the IC’s tasks and priorities

I've told the various teams that I wouldn't have to phone anyone if they updated the ticket. When I see a ticket that has not been updated for 2 months, there's no way I'm not phoning the assigned person.

Problem is that, even when I was a f/time IC, we hardly ever update the ticket unless we feel we have made progress. An update saying "Chased bug with no success $TODAY, requested $SENIOR to consult with me on this" feels like a worthless ticket update, but from the client's PoV, this is valuable info - it means that it hasn't dropped off our radar, we haven't forgotten about it, etc.

Re: Stop trying to engineer your way out of listening to people

#94

Post by sublinear »

layer8 wrote: post #60
sublinear wrote: post #7

> 8. You judge people You know, I was actually hoping for a good listicle of things to watch out for in meetings. The author should take their own advice. Assuming bad faith immediately kills all productivity, so there's no point in finishing reading this. I agree with the general notion that there are often knowledge gaps getting in the way of better planning and execution. I was hoping for techniques to overcome th…

Judging people doesn’t imply bad faith. We are all judging people all the time. It takes constant effort trying to be self-aware of it and trying to compensate for it.

Oh the author continued by saying: "Stop assuming they are bad at their job or their lives".

This was too absurd and hostile for me to continue listening.

I asked myself whether I thought the author was bad at writing, and realized I fell into their trap.

I asked myself how lost and angry someone has to be to write crap like this, and realized I did it again.

Some people have a real knack for being so defensive and insecure that they invite their own pain. They unwittingly coerce people who meant them no harm into doing so. Everyone is a victim for trying to take this blog post seriously.

Re: Stop trying to engineer your way out of listening to people

#96

Post by UK-Al05 »

mixermachine wrote: post #33
heyalexhsu wrote: post #5

Or maybe we're spending too much time on communicating. If too much time is allocated then its hard to stay focused and there's always the next time that can be used to clarify. Cut all the unnecessary meetings and only allocate the minimum viable time to communicate. Then everyone will be listening.

In my experience in software architecture, drawing a diagram often saves you >60 minutes of discussion and potentially multiple meetings. This works even with a badly drawn but truthful one. Use an Ai agent + Mermaid.js for a quick scribble if you are in a remote meeting. Use white boards or pen + paper in a local meeting. Diagrams are so much clearer then words, especially if the concept or logic in question is not…

I have feedback in the past that people don't like diagrams upfront, because it presents a finished solution.

Re: Stop trying to engineer your way out of listening to people

#97

Post by grebc »

generic92034 wrote: post #87
grebc wrote: post #70

Earlier quoted context omitted.

I’ve been at it 18 years for different organisations and my experience and strategy is the same as yours. No one bothers to read/understand anything until the very last minute, then they realise “oh shit this won’t work in this scenario, and it’s always a showstopper”…

But what about my impression that it is getting worse? When I (as a developer) was trying to help customers with the product 20 years ago, about 50% (my guesstimate) of the people were actually reading what I wrote, at least to a good degree. These days I am lucky if it is 20% who are reading answers to their problems more than in a completely superficial way. I blame social media and smartphones.

I think the quality of comms is definitely getting worse, I work for myself now and I am very selective of clients now. So I don’t butt heads against it as much, but it still happens despite best efforts, especially when people move on or even go on vacation.

Literacy skills have been falling and it shows up in testing of a lot of different countries, and it basically lines up with the arrival of iPhone/Android(or real smart phones).

Re: Stop trying to engineer your way out of listening to people

#98

Post by watwut »

AdieuToLogic wrote: post #6
heyalexhsu wrote: post #5

Or maybe we're spending too much time on communicating. If too much time is allocated then its hard to stay focused and there's always the next time that can be used to clarify. Cut all the unnecessary meetings and only allocate the minimum viable time to communicate. Then everyone will be listening.

> Or maybe we're spending too much time on communicating. This is a phenomena I have yet to experience in the wild. > Cut all the unnecessary meetings and only allocate the minimum viable time to communicate. Most meetings are not about communication. They are usually prescriptive in form and dictatorial in nature. > Then everyone will be listening. Listening is a skill, one which is can be perfected if practiced. Ne…

> This is a phenomena I have yet to experience in the wild.

I have totally seen infinite meetings where nothing is achieved, nothing is really said, but someone socially isolate just talks and talks and talks because it is his only chance to interact.

Re: Stop trying to engineer your way out of listening to people

#99

Post by anilakar »

ferngodfather wrote: post #71
anilakar wrote: post #40

Earlier quoted context omitted.

What I say: This is not ready for production. What management hears: We can sell this to the customer for acceptance testing.

What I say: I want a pay rise. What management hears: We want more pizza parties.

Nah. Our CEO just fires everyone who asks for a raise because they're a liability now.

FWIW, this is in a country that supposedly has really strong unions and worker protections.

Re: Stop trying to engineer your way out of listening to people

#100

Post by watwut »

yetihehe wrote: post #81
rrgok wrote: post #77

I have better a idea, since everybody need an engineer to build the damn thing, how about we teach non engineer people to talk to engineer people. Why is it always our burden to learn and improve. UX problem, blame the engineer. Comunication problem, blame the engineer. Documentation problem, blame the engineer. I'm so sick of it. Comunication is a tango. If you - who need the product and are ready to pay for it - do…

> If you - who need the product and are ready to pay for it - don't take your damn time to effectively articulate what are your needs then you should go to school again and learn it. Instead they will go and buy a product that was made by engineers who asked them "what they actually need" and "how can we make it easier for you". It's not about "why should I always care, I have enough". It's about "who will make bette…

> Instead they will go and buy a product that was made by engineers who asked them "what they actually need" and "how can we make it easier for you".

That sort of decision making is not done by engineers. You are blaming engineers about product decisions made by management, product management, UIX design, analysts ...

Post reply on HN