The flight was uneventful, until its final minutes. It started to go wrong when a pitot tube - an instrument for measuring airspeed - froze over, causing the autopilot to turn off. In retrospect, it's clear that the junior pilot, Bonin, flying at the time signalled his experience when he exclaimed "I'm in Take-Off Go Around, right?" at 37,500 feet above the Atlantic. The rest of the crew only realised when the Captain had returned to the flight deck and told the crew to pull up, and the pilot responded, "But I've been pulling up the whole time!". Bonin said, a few moment later, "But what's happening?" It was the last thing he said before AF-447 slammed into the ocean, killing everyone on board.
I'm a little worried about our industry, and it's not because we have inexperienced developers writing code. After all, Bonin was not exactly inexperienced as things go - he had 807 hours on the aircraft type at the time, and nearly 3,000 hours as a pilot.
No, what worries me is that Bonin had no experience in manually handling the aircraft at altitude, had done next to no manual flying of light aircraft in his career, and so predominately flew either take-off and landings or else was operating the aircraft via an autopilot. In other words, he had no experience of the fundamentals. This meant that his reaction to the aircraft losing 10,000 feet per minute was to pull back further and further - the plane was pointing up at 41.5 degrees.
I know plenty of really impressive developers who don't know any assembler, or who don't understand how virtual memory works. I'm seriously amazed by developers who don't understand the difference between a non-blocking and a blocking call, or who can't write their own event loop. It's not that anyone needs to write an event loop (even I don't, and I'm a systems programmer). I haven't touched ASM in at least a couple of decades, and I feel much better for it.
But when I started coding - yes, I'm being a grumpy old man, bear with me - one had to learn about these things because we really had no choice. My first "real" programming had to involve a bit of machine code out of necessity - that's entering hex codes directly, not even an assembler to be seen! When I started trying to do event-driven programming, I had to write an event loop myself because there were no libraries to do it for me. This isn't boasting; this is just me being in my mid-forties. If I were only a little older, then there would be no higher-level languages in my early years at all. Also, it were up hill both ways.
Most of the time, this misspent youth at the bottom end of the stack is of no use to me. But when things go wrong, a little understanding and experience of the underlying technologies gives me a really useful background. By way of illustration - and because of my bizarre fixation with air crashes - I'd like to present the story of Air Canada Flight 143, in 1983.
Flight 143 got into trouble due to a somewhat bizarre collection of events that left both a non-functional fuel gauge and insufficient fuel, yet a crew convinced that the aircraft was both fully fuelled and cleared to fly.
The Captain and First Officer of '143 were both insanely experienced - they had over 22,000 hours between them - and handled the situation with aplomb. Initially, they thought that a fuel pump had gone, and prepared to divert to Winnipeg. Next, they correctly guessed that the loud "bong" followed by complete loss of power meant that all the engines were out (due to fuel exhaustion) and deployed the wonderfully-named Ram Air Turbine, or "rat".
The First Officer, Quintal, then identified an old Royal Canadian Air Force base he'd once served at nearby. Once called RCAF Station Gimli, what Quintal didn't know was that it was by then known as Gimli Motorsports Park. Captain Pearson then proceeded to calmly glide a 767 to an unfamiliar airstrip.
Shortly before landing, the crew realised that they would have no flaps or slats to slow the aircraft, and they were coming in too high and too fast - Pearson carried out a gliding manouevre called a Forward Slip, and landed the aircraft safely - in the middle of a racing day. Take another look at that header photo:
A ground crew team drove from Winnipeg to discover the state of the airframe. In the most ironic coincidence ever, their van ran out of fuel on the way.
Captain Pearson was never trained in how to glide a 767. Standard training didn't cover flying with all engines out, and the crew had never even heard the warning sound before, even in simulator training. However, he was an experienced light aircraft and glider pilot, and could reapply that experience to handle the situation.
Not only was nobody injured (10 people were injured in the evacuation subsequent to landing), and the aircraft was repaired and flew for another 25 years.
Fundamental knowledge is a valuable thing in emergencies - and lack of it can really hurt.
Oldest comments (5)
I have a couple questions:
Do you think a front-end web or mobile developer needs learn some of this more fundamental stuff?
What if that front end developer first learns how to put together a UI with some interaction, then later in their career develops an interest in figuring out how virtual memory and more advanced topics work?
I understand your argument, but I want to unwrap the possible different order of things.
Now that's an interesting point. And no, it's not as if I think people should start with logic circuits, move through flip-flops up to counters and then finally consider assembler. It's more that as people can't completely neglect the lower level stuff.
If you're a Javascript programmer, for instance, you might want to look at Phil Robert's talk on the event loop:
Loupe
It's thankfully very easy to ignore a lot of low-level stuff, these days - but it's still useful, and occasionally vital, to learn about.
I'm a newbie in the field, and I've never been taught about what I usually think of as "low level stuff", during formal education. I've watched several video and read blog posts on things like virtual memory, interrupts, how I/O is handled, etc.but because I've never had to actually apply this stuff, the details never really stick. If you have experience with online tutorials that teach the fundamentals, which includes practical exercises, I might give that a try.
Also, I enjoyed the airplane crash stories (weird to say that about a crash, I know), but I think it'd be good to include an actual dev story where knowing the fundamentals came in handy. This way, the need to know the fundamentals becomes more clear
Lastly, I think you have a typo at "Not only was nobody was injured ..."
Air crashes are more interesting than computer crashes. Most serious computer system failures are similar in nature - not one single fault, but a set of cascading faults which might well start with a minor issue but result in a disaster. (An example would be a broken RAM module in an Amazon datacentre which resulted in a hefty chunk of AWS dropping a few years ago).
As far as trying to learn these things - write a webserver. I used to write webservers in all sorts of languages, to learn things. I wrote one in TCL (not recommended), I wrote one in C using threading, then another when I realised I'd got threading all wrong. They're simple enough things to write at a basic level - you might want to restrict yourself to HTTP/0.9 - but just complicated enough to experiment with all sorts of architectures.
And well done for spotting my deliberate typo.
I've got to put a plug in here for a computer game called TIS-100. It is described as "the assembly language programming game nobody asked for." After completing puzzles like (parallel) sorting/filtering lists with (hardware) stacks in an assembly language with maybe a dozen instructions, I have to tell you I am extremely grateful for
List.filterand the like.I think the subtext here is that you want people to care enough or be curious enough to go deep in their craft. Unfortunately, not everyone is going to do that or even be in a place to understand why they should. I think that's okay -- that person can still be a benefit to the team and experience personal growth in the right position. In the wrong position, well, the opposite. As a side note: if you find a place with good management (who can recognize and respond to this situation), plant yourself there. Managers who care about their craft are hard to find too. :)