This is why speculation needs to come with a warning label in advance, or people retreat to their corner and start attacking to defend.

A student pilot is hyper aware of the economics of aviation. It's frigging expensive. The only thing cheap and plentiful is the opinion of another pilot.

The tweet author's shot gun spray of possible things to blame other than software, is fine speculation, because aviation accidents are rarely simple. Likely more than one thing happened. But the author rapidly falls into a trap of making claims that are not yet in evidence.

Alpha sensor failure? There's a categorical statement the sensor failed? How? Was it transient? What was the range of the readings? How did the software interpret it? Could the sensor data be corrupted in between the sensor and the interpreting software, i.e. in the communication pathway?

Author says Lion Air pilots weren't informed of MCAS. Southwest Airlines pilots weren't informed either. I haven't heard for sure whether AA pilots were informed. Of the pilots who were informed, what exactly were they told?

If the pilots had correctly and quickly identified the problem and run the stab trim runaway checklist, they would not have crashed.

It is not a fact in evidence they failed to do this. We have no idea what the position of the stab trim switches were, or the autopilot, and we don't know when they got into that position, or in what sequence.

Central to troubleshooting system failures in-flight is buying time. And buying time means stabilizing the plane. Uncommanded behavior can have dozens of causes. It's supreme hubris and insulting to propose pilots did something wrong without evidence, to propose they were incompetent, without evidence. To assume the failure should have been recognized, without evidence.

What will cause a consistent uncommanded roll? Could be a powerplant failure, could be control surface failure (could be any of several or a combination). Could you get a control surface failure that will kill you before you know what failed? Absolutely. Your job is to rely on training to manage the failure with a reaction that will stabilize the airplane, to buy a little extra time so that you can figure out what's failing so you can properly mitigate the failure. The proper mitigation will inevitably be different than the initial stabilizing reaction.

What happens when the failure is intermittent? That means you can't trust your stabilization routine, and therefore you haven't bought time, and therefore you're switching from death defying reaction to having to think critically. Both are being perturbed, panic is likely. The normal behavior of MCAS nose down is not described as consistent if you're not aware of it in advance; you might need a few minutes to recognize the pattern. Is this for sure recognized as runaway trim? We have circumstantial evidence that it may not be.

Nowhere in here is there a software problem. The computers & software performed their jobs according to spec without error.

That's a concluding statement for which there's insufficient evidence. It's a reasonable assumption, because computers and software are expected to be deterministic, in particular in industrial applications. Obviously the code is not changing on the fly. And this had to be demonstrated for certification. But it's still an assumption until all the facts are available, and we have a high confidence explanation for all of the facts.

Further, the author totally ignores public statements from Boeing and the FAA that a software "fix" or update, is expected for MCAS, the software routine under discussion, by the end of April. If there's no software problem, why update it? Perhaps it's a work around for some other design deficiency. But could it be fixing a non-deterministic software bug, however unlikely?

This is the folly of speculating on airplane crashes.