Hacker News Reader

> First, it is not your job to make that kind of technology decision. You can offer advice, but it is your manager's job.

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.

> Err, no: "A manager came to me asking if we should rewrite the checkout of our E-Commerce platform using React [...]"

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.

It seems that this is an issue that is close to your heart ("As a parent ...") so I apologize if this comes off as harsh: you should take a closer look at the assumptions you are making about @larve, a person whom you have never met.

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

No competent manager would undertake a rewrite without new functional requirements at hand. Feature parity may well be the first milestone, but without an idea of what future projects might be, it's impossible to choose the best tools to facilitate them. Commercial companies are there to serve customers, make a living for employees and generate returns for owners/shareholders, not for funsies, save that for a hobby github project. Any managers not willing to listen to engineering concerns / articulate their own and any coworkers who expect others at work to be happy about every single aspect of their employment need help.

Obviously true.

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.

You misunderstand. The author _laments_ that the conversation got hung up on the first question. The points you raise (e.g. "do my existing programmers have the necessary skills", "will this make future projects faster to develop") fall squarely into the categories the author mentions reasoning in (e.g. "teams", and "feedback loops", respectively).

> - Will switching to React make hiring and training future developers easier?

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

Yes, these can be framed as concrete problems. But people usually don't start with much clarity in their thought, so it is unlikely that they will be handed to you in such a way.

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.

Let's be serious for a second. If the manager has those questions why did he ask about an unrelated rewrite of existing software into react?

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.

https://dilbert.com/search_results?terms=Database%20Mauve

Thank you for posting this.