upvote
> 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 better product and earn more money".

> By the way, since you all non-engineer people are so good at communicating, why are you not communicating effectively your needs?

They are good at socialising, blurting out words at each other and they think it's good communicating (it's emotional reassurance of eachother, not a technical facts exchange, but it's still their valid need), but when you say that to them, they are upset and don't want to buy a product from you. Don't tell that to their faces. Of course, if you want to do something and don't want people to buy it, do follow on what you wrote.

reply
The thing is, neither the software engineers nor the users know wtf should be done completely. Communication across domains is hard.

Let's try a physical items example: have you ever ordered a piece of furniture or other home improvement thing, got exactly what you asked for, professionally done... and then later found out there were better ways to do it (at similar cost) that you hadn't even imagined?

Was it because you didn't know what to ask for? Was it because the experts in home improvement didn't volunteer that there are other options? Was it because they sell one thing and didn't even know there are other options? Did you even ask what options you have or did you just order the thing?

Communication is damn hard, again.

reply
> Communication is damn hard, again.

Yes, but it is necessary to achieve better results.

> Was it because you didn't know what to ask for? Was it because the experts in home improvement didn't volunteer that there are other options?

That's bad communication from both sides. Having good information on each of the sides leads to better communication. Client with better communication will have better results for himself. Seller having better communication will give better results to his clients. Worse than his average to clients with bad communication, better than his average to clients with better communication. But his average will be higher than average of seller with bad communication.

Sellers with better communication will provide better service and will attract customers. Sad corollary: he will also attract a lot of customers with bad communication.

> Was it because you didn't know what to ask for?

Yeah, when I don't know what to ask for, I search for expert who will know what I should ask and will help me with expanding my knowledge of the options.

> Let's try a physical items example: have you ever ordered a piece of furniture or other home improvement thing, got exactly what you asked for, professionally done... and then later found out there were better ways to do it (at similar cost) that you hadn't even imagined?

Yes, I speak from experience of such moments.

> The thing is, neither the software engineers nor the users know wtf should be done completely.

It's easier and more effective to educate a small group of software engineers than a lot of users, that's why engineers SHOULD try to communicate better.

> Communication across domains is hard.

It is. But the expert has typically to communicate across one domain, his own against "no_domain". User would have to learn to communicate better or become domain expert in a lot of different domains.

reply
> Yeah, when I don't know what to ask for, I search for expert who will know what I should ask and will help me with expanding my knowledge of the options.

> Yes, I speak from experience of such moments.

And did you actually look for an expert or did you just get something from Ikea? Do you even know how to identify an expert furniture designer?

One of my points is we think we're damn unique but we aren't. And my example has us as customers.

Real world example: I was in $RANDOM_HOTEL last month. Now I want to redo the attachment system for all my curtains in the house because theirs was smarter than what I knew to ask for.

reply
> And did you actually look for an expert or did you just get something from Ikea?

Sorry, but I don't see the point of your comment.

I looked for an expert who helped me with expanding my options. Expert != "will sell his exact product he is trying to sell in the place he is working at". Sometimes as an expert you even have to advise a client against your product, because he will try to use something not designed for him.

> I was in $RANDOM_HOTEL last month. Now I want to redo the attachment system for all my curtains in the house because theirs was smarter than what I knew to ask for.

But did you look for an expert? Expert might suggest a better alternative than you currently have, but you gained information yourself by accident. If not for that happy accident and you being observant, you wouldn't know.

reply
Yes to everything you said and also to what i said :) You just took it personally.

The whole idea is I'm trying to place the "expert" software engineers in a position where they're not the experts to make them understand their clients better.

> and you being observant

OT: How many other great home improvement ideas have i missed because i wasn't observant enough?

Edit: or is it really off topic? Will the customer of the software engineer research, say, all possible database solutions or, even assuming great communication with the engineers, just pick a good enough one from their combined knowledge?

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

reply
Well, you are right. I conflated "engineers" with "experts". UX people, product management, analysts should improve their communication skills. Engineers (like me) too.

Engineers should have better communication skills, but if the whole weight of communication is put on engineers instead of people hired to actually be responsible for this, engineers will be burned out.

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

Thank fucking god someone who understand it. Sometime I feel an alien listening people bitch about engineers. A product is not just the result of engineers.

reply
> UX problem, blame the engineer. [...] Documentation problem, blame the engineer.

I see UX and usable documentation as among my responsibilities as a developer. It's not that I "blame" myself if the documentation is confusing for a user, it's that I say "oh, that's a documentation bug". And it's my job to fix bugs.

reply
That's what I started doing in my company, encouraging the use of AI to polish prototypes and communication before handing it to the tech team smooths out alot of issues while exloring the solution space.
reply