4 ms·

The thing is, at least in the first example, the way I read it isn't "autistic people can't admit when they are wrong". From your own telling of the story it se

The thing is, at least in the first example, the way I read it isn't "autistic people can't admit when they are wrong". From your own telling of the story it seems like a manager asked you "Should we rewrite the checkout page in React?", and you responded with "Should we rewrite the checkout page in React?". You failed to realize that all of the questions you asked them are the question they were asking YOU. They've been reading articles about technical teams gaining things they don't really understand from switching to React. Maybe increased velocity (they know what velocity is but don't know how React increases it), reduced bundle sizes (what's a bundle? why do I care?), faster rendering times (faster is a good thing, right?), etc. But they don't have the knowledge to judge if React will do this for them. Answers to this question might be "No, we already use Angular which provides similar benefits to React", "Yes, switching to React from MooTools (I'm old) would simplify the design, increasing our velocity and probably resolve some annoying rendering bugs", or even "I'm not sure. Perhaps we should meet and discuss the weaknesses of that page and figure out if React is the right tool to resolve them". Instead they got back the questions they were hoping you'd answer for them. Many long years ago the CIO at a company I worked for asked if we could use machine learning to improve our data analytics. I responded with "I don't know, what kinds of questions are you hoping to answer?". We went back and forth on this several times, with me insisting you couldn't just throw machine learning at data without some idea of what your hoping to get back. This wasn't resolved until they brought in a vendor claiming to provide turnkey machine learning solutions, they ran it against our data and came up with the stunning insight that the biggest predictor of dollars sold was.... units sold. To be fair they did provide other data points, but it was all things we either already knew, or didn't care about and if we ever did could find out quickly. I failed to recognize that the question I was asking was a big part of what I was being asked. If I had realized this and provided some insight into the kinds of questions machine learning could answer, and why we didn't need sophisticated machine learning algorithms for the ones the business cared about I could have saved everyone some time. Instead I kept rephrasing the question back at him, with neither of us having the insight to realize we were actually asking the same question.

larve 4y ago
The questions you bring up are really the questions I am asking? What do they think the weaknesses of the page are? Do they think rewriting the checkout will solve these problems? How much of the technical tradeoffs do they understand or care about? To recap: Is our checkout page not performing well? Will a new checkout solve our problem? Why do they think a technology change is a solution? Do they understand the implications of such a switch? Otherwise I won't be able to assess if react makes sense or not. It makes sense for some reasons, not for others. If I don't know why they think we should consider it, I can't provide a valuable answer. These are exactly the points you are bringing up as well: I don't know, and I need your input to clarify what we are trying to do. I understand there is a communication problem, but I'm most definitely not refusing to accept I am wrong. I haven't even stated anything that could be wrong. And because I have fully put the blame on myself, after this particular interaction, the fact that I am able to work perfectly fine at a very strategic level with other stakeholders in my new job shows me that it's not just about me.
- Volundr 4y ago
  Obviously I wasn't there and am going by your accounting of the conversation, but from the way you laid it out, the questions I brought up are the questions your manager thought they were asking you. Hence the confusion, followed by frustration. From my interpretation of the conversation, you thought the question was: "Should we rewrite the checkout page in React, yes or no?" And responded with "Why do you want to rewrite it in React?" (paraphrasing) Meanwhile the manager thought they were asking: "Please discuss the reasons why we should and should not rewrite the checkout page in React, including your recommendation on a course of action" And you responded with "Why do you want to rewrite it in React?" Spelled out like that it's hopefully a little clearer that the "why React" was part of the question. They don't know if the page is performing "well" or whatever that means (even from an engineering standpoint it's hard to define, render time? bandwidth? server CPU?). They might know if users are complaining about checkout being slow, but even then users tend to leave rather than complain. If you were to tell them that the checkout page was performing "poorly" and React could fix it, that's the kind of information they were hoping to obtain from this conversation. Similarly in my machine learning question, my CIO was actually asking me "how do you think machine learning can benefit this business?" And I responded with "how do you think machine learning can benefit the business?" He didn't know, he was asking me. He had just heard about the wonders of machine learning and was fishing for how it could benefit this business. Just like your manager had heard about React and was fishing for how it could benefit the business. If your manager were here replying to comments I'd advise them to remember that engineers in general (spectrum or not), tend to be the literal sort, and if you aren't getting the answers your looking for it's often useful to examine the words you used and ask if you are actually asking the question your hoping to get answered or relying on subtext. But for the engineer's side of this conversation, it's important to ask if the question your answering is actually what they are asking, or if you failed to parse their intentions.

larve 4y ago

The questions you bring up are really the questions I am asking? What do they think the weaknesses of the page are? Do they think rewriting the checkout will solve these problems? How much of the technical tradeoffs do they understand or care about? To recap: Is our checkout page not performing well? Will a new checkout solve our problem? Why do they think a technology change is a solution? Do they understand the implications of such a switch? Otherwise I won't be able to assess if react makes sense or not. It makes sense for some reasons, not for others. If I don't know why they think we should consider it, I can't provide a valuable answer. These are exactly the points you are bringing up as well: I don't know, and I need your input to clarify what we are trying to do. I understand there is a communication problem, but I'm most definitely not refusing to accept I am wrong. I haven't even stated anything that could be wrong. And because I have fully put the blame on myself, after this particular interaction, the fact that I am able to work perfectly fine at a very strategic level with other stakeholders in my new job shows me that it's not just about me.

Volundr 4y ago
Obviously I wasn't there and am going by your accounting of the conversation, but from the way you laid it out, the questions I brought up are the questions your manager thought they were asking you. Hence the confusion, followed by frustration. From my interpretation of the conversation, you thought the question was: "Should we rewrite the checkout page in React, yes or no?" And responded with "Why do you want to rewrite it in React?" (paraphrasing) Meanwhile the manager thought they were asking: "Please discuss the reasons why we should and should not rewrite the checkout page in React, including your recommendation on a course of action" And you responded with "Why do you want to rewrite it in React?" Spelled out like that it's hopefully a little clearer that the "why React" was part of the question. They don't know if the page is performing "well" or whatever that means (even from an engineering standpoint it's hard to define, render time? bandwidth? server CPU?). They might know if users are complaining about checkout being slow, but even then users tend to leave rather than complain. If you were to tell them that the checkout page was performing "poorly" and React could fix it, that's the kind of information they were hoping to obtain from this conversation. Similarly in my machine learning question, my CIO was actually asking me "how do you think machine learning can benefit this business?" And I responded with "how do you think machine learning can benefit the business?" He didn't know, he was asking me. He had just heard about the wonders of machine learning and was fishing for how it could benefit this business. Just like your manager had heard about React and was fishing for how it could benefit the business. If your manager were here replying to comments I'd advise them to remember that engineers in general (spectrum or not), tend to be the literal sort, and if you aren't getting the answers your looking for it's often useful to examine the words you used and ask if you are actually asking the question your hoping to get answered or relying on subtext. But for the engineer's side of this conversation, it's important to ask if the question your answering is actually what they are asking, or if you failed to parse their intentions.