Instead, it was an entire article that not once acknowledged that you could be wrong, nor what it looks like when you do acknowledge it. It detailed about how, actually, you're not usually wrong.
This article appears to underscore the accusation.
When I’m wrong I just say “oh you’re right, good point” and move on. It’s very easy to do.
Sadly I don't have much to share in the way of insight.
Have you considered that being comfortable admitting fault is a skill which some people never learned while growing up, regardless of gender? And can you imagine a world where men do the same thing, but you don't gripe about it because you're not in a relationship with them?
And, tbf, "the wife is never wrong" encodes some wisdom, same as does the saying "Happy wife means happy life" or, from White Men Can't Jump, "Always listen to the woman".
Let's take the React checkout example that you gave. Your self-illusion is that you were engaged in holistic thinking. And, in fact, you couldn't even see the whole for the first irrelevant detail that caught your attention. This is the opposite of holistic thinking!
First, it is not your job to make that kind of technology decision. You can offer advice, but it is your manager's job. Your job is to make sure that your manager is well-informed. You failed at that job.
If you believe otherwise, then you're wrong. You probably believe you are better equipped to make that decision than your manager. You may well be right about that. (Though, as a rule, we tend to think that we are smarter than we are, and our managers are stupider than they are. But that is a side point.) But you are still wrong about the important point. Which is that it is still your manager's responsibility to make that decision.
You wanted to frame the entire conversation around, "Does this checkout form have a concrete problem that needs fixing?" Your manager's thinking is going to be about very different looking questions. Such as:
- Will switching to React make hiring and training future developers easier?
- Do my existing programmers have the necessary skills to test this technology out?
- Will this technology choice make future projects faster to develop? (For example, do we get wins from a better toolchain, etc.)
- Will this be an interesting project that helps me keep existing employees motivated?
- Are the other claimed wins in the blog post actually going to work out that way?
Your manager needs to think about these things. You may dismiss them as bullshit, but they are not. Companies live and die on such considerations.
Your manager learned absolutely nothing about these things. Your manager may have come away with the impression that you have no idea if there is a problem with the checkout page. But by misunderstanding your role and responsibility, you failed to carry out your actual responsibility within the team. And wound up so upset about it that you wrote a blog post with a strong undertone of, "Here is the kind of stupid I have to deal with at work."
And that AGAIN puts you in the wrong. It literally takes under a minute to go from your blog to your name to where you work. Any coworker who recognizes the blog now knows you're unhappy. Which poisons your work atmosphere. And if this comes to your manager's attention, your manager has to now deal with the fallout from THAT.
Yes, yes. You consider it bullshit. But it is bullshit that can easily get you fired. For good cause. And the fact that you do this AGAIN puts you in the wrong. And your considering it bullshit DOESN'T STOP YOU FROM BEING WRONG. It just means you won't admit it was a mistake.
Err, no: "A manager came to me asking if we should rewrite the checkout of our E-Commerce platform using React [...]"
> You wanted to frame the entire conversation around, "Does this checkout form have a concrete problem that needs fixing?" Your manager's thinking is going to be about very different looking questions.
This is literally their first question: "Is our checkout page not performing well?". The manager should have simply said "the problem is not performance, but X" instead of assuming that the developer is rejecting their idea.
> You may dismiss them as bullshit, but they are not.
It is interesting that you, like the manager, assume that they dismissed the idea.
> And that AGAIN puts you in the wrong.
I disagree. If the manager is not able to clarify the specifics of their question (remember, it was a question of whether they should do X) they are in the wrong.
This in no way contradicts what I said. This is a normal way of asking for opinions on a decision that needs to be made. And organizationally the decision IS the manager's. In practice a wise manager will take (and usually follow) advice from their developers. But still it is the manager's call.
> This is literally their first question: "Is our checkout page not performing well?". The manager should have simply said "the problem is not performance, but X" instead of assuming that the developer is rejecting their idea.
Based on my personal experience of people on the spectrum, I doubt that things happened as described. My best guess is that it was exactly what dusted described in https://news.ycombinator.com/item?id=32410505.
Namely, early in the conversation, the person on the spectrum got caught up on some irrelevant point. That they couldn't let go of. Which they kept going back to explain how right they were. Eventually the conversation got derailed having gotten no further. And, rather than dropping it, the person went on the internet to explain to the whole world how right they were.
I've been part of such conversations. (Thankfully minus the whole world bit.) The first few times you can hope that a simple clarification will get the conversation back on track. After a while you learn otherwise.
As a parent, what I've found most useful is to set a rule that the person on the spectrum is not allowed to argue that they are right. Ever. Even attempting to make the argument gets shut down. If breaks are needed to finish the conversation, then OK. This resulted in a lot less arguments, and a lot more moments of, "Oh...."
> It is interesting that you, like the manager, assume that they dismissed the idea.
No. I was doing something rather different.
The thread to this point brought up the importance of learning how to play social games. With the poster saying that they had learned to do so, were good at it, and didn't bother any more.
My experience of people on the spectrum says that the poster didn't learn nearly as much about social rules as they think, and they discount the impact more than they should. Since the factors that I described did not occur to the poster, and several focused on social rules, there is a good chance that they seem like BS.
> I disagree. If the manager is not able to clarify the specifics of their question (remember, it was a question of whether they should do X) they are in the wrong.
It takes 2 to communicate. There clearly was a communication failure here. While that failure could be the manager's fault, the odds really are in favor of it being the fault of the person with a condition that makes communication hard (autism), rather than the person whose got promoted into a job that is all about communication skills (the manager).
And yes, it really sucks for autistic people that a failure to communicate by default gets blamed on them. What sucks even harder is that it is true. Which is why it is doubly important for them to work on their communication skills.
And guess what simple change most improves communication skills for most people on the spectrum?
Hopefully you figured it out. It is to stop arguing that they are right. Ever. Not because they are usually wrong. But because they tend to wind up arguing that they are right when they are missing something basic, and the fact that they are arguing makes it impossible to figure out what they are missing.
This is surprisingly hard advice to take. And it is harder for people on the spectrum than neurotypical people. But it makes a huge difference.
> The problem is that you come across as ...
> And the fact that you do this AGAIN ...
> My experience of people on the spectrum says that the poster ...
I do not know precisely when, but it seems that at some point you started ranting to your child.
However there is a long path from first getting the idea of a rewrite to actually undertaking it. And the conversation in question happened because the manager had just read an article about such a rewrite, so it was very early in that journey.
> - Will this technology choice make future projects faster to develop? (For example, do we get wins from a better toolchain, etc.)
> - Will this be an interesting project that helps me keep existing employees motivated?
> - Are the other claimed wins in the blog post actually going to work out that way?
But... These are (or can be framed as) concrete problems.
> - Do my existing programmers have the necessary skills to test this technology out?
If you can't produce a single concrete reason why to try a new framework, why should I discuss about testing it?
(this as someone who may be on the spectrum and for whom the original article hit a bit too close..)
As for not producing a single concrete reason to try the new framework, there is no reason to believe that the manager didn't. According to the article the manager had just read a blog post on it, that caught the manager's attention enough to spark a conversation. SURELY there was SOMETHING in that article about why it might be a good idea to try React?
We aren't told what points were made, likely because they seemed irrelevant. But I'd bet good money that some were made.
The second question is quite literally just a "Have you experience with React?" which doesn't require additional questions for clarification. The manager would be expecting a "yes/no, but ..." type of answer. Honestly your questions would be asked in a meeting with as many developers and even non developers as possible to save time, not in a one to one conversation.
Honestly this whole topic is way too similar to the Dilbert comic where Dilber asks his boss what colour he wants his database in, to test whether he understands what a database is.