Posted by walterbell 4 days ago
I'm so sick of it. Comunication is a tango. 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.
By the way, since you all non-engineer people are so good at communicating, why are you not communicating effectively your needs?
Bring on the down votes.
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.
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 ...
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.
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.
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.
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.
> 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.
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.
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?
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.
That's what the 400k/yr is for.
I think it's a mistake that such people often stop even listening to those who are less well-read or less experienced in a subject; they prefer to adopt the position of the 'source of truth' and the teacher. Although, it seems to me that people who are less 'biased' by extensive reading often come up with original—perhaps unpolished, but original ideas. To hear those ideas, you have to know how to listen and extract thoughts rather than suppress them."
1. Can u add X 2. Can u change Y
Without understanding cost of doing all this. Yes, i can do all and everything you ask for, but each action has a cost, which you fail to understand.
We cannot do everything if we need to launch a reliable product.
The customer doesn't need to understand how the solution works, as long as they can understand that it would solve their problem (in the case of the power plant: producing "clean" energy) and any potential drawbacks or limitations (in the case of the power plant: the waste byproduct).
The point here is that as a "tech person", it's your job to help the customer understand the cost of what they're asking, and come up with a satisfactory solution based on your understanding of their needs.
> We cannot do everything if we need to launch a reliable product.
Agreed, otherwise it would be Turing complete Excel/Email clone.
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 them, but (sigh) I guess that's just more "engineering" getting in the way.
I've been doing this for long enough to realize there's no substitute for experience. It's basically the opposite of all the popular advice. If you're serious about any successful long-term career, you can't avoid looking foolish and having lots of difficult discussions. There are no shortcuts. There is no "higher path" you're missing out on. If you're going to grind it out, at least save face by working at the "shitty places" with bad reviews on glassdoor where you can safely fail without damage to your ego or reputation. When you finally get hired somewhere nicer mid-career, you can just bury all that in your mind and pretend it never happened. Nobody cares anyway.
If we're going to be judgy, I gotta say some of the worst people I've ever worked with never got out of that phase. It's that simple.
First, the author is not assuming bad faith. They are saying that judging people is common pitfall. And the "hating or dismissing people for misunderstanding the thing you documented badly" is something I have seen done so many times, that yep, it exists.
But second unrelated thing is, sometimes there is a bad faith. Refusing to accept that bad faith situation can happen just makes it massively harder to solve the issue. It empowers the person acting in bad faith.
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.
Especially for interns within large multifunctional companies- I have seen a hundred times over how some very bright engineers will start to sniff out who they have decided is or isn't technical and try to avoid the non-technical team members. You might get some kudos from other engineers but it won't compare to the praises analysts will sing when they finally get the technical attention they have needed for a year or more.