
Sully didn't do anything hard from a piloting standpoint. He made the right decision to ditch in the Hudson. Once that decision was made, it was just a long glide. Plenty of room. He had the full Airbus flight control system doing most of the work. Read "Fly By Wire", by Langewiesche, which goes into this in great detail.
The Ethiopian Air pilots faced a very tough problem. They were nosing down for an unknown reason, the standard recovery procedure didn't work, and they didn't have much altitude.
Airbus statement on sidesticks. [1]
Boeing position on sidesticks.[2]
This is a long-standing controversy. The F-16 fighter was the first aircraft produced with a sidestick. But that was so the pilot could control it during high-G maneuvers. Airbus's use of it has been controversial for years. For a good overview of the Airbus control system, read "Fly by Wire", by William Langewiesche.
But that wasn't the problem with Lion Air.
Airspeed. Attitude. Vertical speed. Altitude. If the pilot is operating on wrong information for any of those, they may lose control of the aircraft. All large aircraft have more than one of each of those. But when they disagree, or fail in a common mode, big trouble.
Whether some other data source like GPS or inertial should be used to back up those is an open question. GPS can and is jammed. Inertial systems drift. Both are complicated. The classic instruments are so simple. But they rely on tubes to holes in the aircraft skin, which might become plugged for a number of reasons - ice, maintenance covers, insects, or dirt.
[1] https://safetyfirst.airbus.com/app/themes/mh_newsdesk/docume...
This article discusses the other side of cockpit automation, in the context of the Air France 447 crash. The key point here is, as "Boeing’s Delmar Fadden explained, “We say, ‘Well, I’m going to cover the 98 percent of situations I can predict, and the pilots will have to cover the 2 percent I can’t predict.’ This poses a significant problem. I’m going to have them do something only 2 percent of the time. Look at the burden that places on them. First they have to recognize that it’s time to intervene, when 98 percent of the time they’re not intervening. Then they’re expected to handle the 2 percent we couldn’t predict."
This is a key problem in computing. Things are "user friendly", and don't require much understanding, until something goes wrong. Then they require vast amounts of understanding. This is OK (although tacky) for banal applications, but not OK for ones that can kill.
Automotive engineers sort of get this. Anti-skid braking systems, traction control, roll control, and air bags are all intended to work properly in emergencies with no user attention. During normal driving, they do nothing. That's as it should be.
"Internet of things" people do not get this at all. They're happy to hook a phone app to some actuator (probably via some "cloud") and let the end user worry about problems. This will be dangerous for "things" that have any real power.
The real miracle of that episode was that there were enough boats nearby, including large ferries, to rescue everyone before the aircraft sank.
And ironically, William Langewiesche (whose reputation for aviation is based, aside from being a pilot himself, on his father, Wolfgang Langewiesche) wrote a book on US Airways 1549: https://en.wikipedia.org/wiki/Fly_by_Wire
