parados

Second this. Canonical is currently winning the race to the bottom for tech interviews (I'm speaking with a couple of decades of experience on both sides of the table). They use lots of AI on their side (of course, none allowed on your side). A strange focus on your school years. Dark patterns in technical questions with no opportunity to get clarity. Ghosting afterwards. Interviews always involve some asymmetry but Canonical exploits that to the maximum.

I think that you are confusing ACARS messages (those transmitted from the aircraft via airband radio or satellite) with ECAM messages (those that are displayed to the pilots). The former are mainly for operational reasons, for example so that ground engineers get forewarning of a failing component. ECAM messages are flight safety critical messages requiring pilot action and they are organised by priority.

ECAM messages are recorded by the DFDR/CVR but are not normally transmitted via ACARS. Pilots were not normally aware of ACARS messages (see MH370).

Your point is a fair one though. In the case of AF447 the crew, against their training, made no attempt at all to work their way through the multiple ECAM messages with the appropriate checklist so they died. The final report on QF32 shows what a high workload this can be.

Since AF447 was lost for nearly two years the ACARS messages were all that the investigators had to go on until they found the wreckage and the DFDR and CVR. Incidentally, one problem with those ACARS messages was that they are only timestamped to the minute and may arrive out of order which makes the interpretation of them more difficult.

For sure, it is on my TODO list. It takes a lot of work to explore each new Python C API and I'll get around to it when I can.

True, and I agree, but from their report they do seem to be doing Root Cause Analysis (RCA) even if they don't call it that.

RCA is a really bad way of investigating a failure. Simply put; if you show me your RCA I know exactly where you couldn't be bothered to look any further.

I think most software engineers using RCA confuse the "cause" ("Why did this happen") with the solution ("We have changed this line of code and it's fixed"). These are quite different problem domains.

Using RCA to determine "Why did this happen" is only useful for explaining the last stages of an accident. It focuses on cause->effect relationships and tells a relatively simple story but one that is easy to communicate - Hi there managers and media! But RCA only encourages simple countermeasures which will probably be ineffective and will be easily outrun by the complexity of real systems

However one thing RCA is really good at is allocating blame. If your organisation is using RCA then, what ever you pretend, your organisation has a culture of blame. With a blame culture (rather than a reporting culture) your organisation is much more likely to fail again. You will lack operational resilience.

Got it. Thanks.

> and my recent hyper-fixation (seems to spark up again every few years), the sinking of the Titanic.

But the rest of your comment reveals nothing novel other than anyone would find after watching James Cameron's movie multiple times.

I suggest you go to the original inquiries (congressional in the US, Board of trade in the UK). There is a wealth of subtle lessons there.

Hint: Look at the Admiralty Manual of Seamanship that was current at that time and their recommendations when faced with an iceberg.

Hint: Look at the Board of Trade (UK) experiments with the turning behaviour of the sister ship. In particular of interest is the engine layout of the Titanic and the attempt by the crew, inexperienced with the ship, to avoid the iceberg. This was critical to the outcome.

Hint: Look at the behaviour of Captain Rostron. Lots of lessons there.

Former UK manufacturing engineer here (1980s onwards).

The manufacturing industry in the UK at that time suffered from three serious problems:

- Low productivity workforce. There was a huge pool of skilled, low wage, workers that had little incentive (or will) to up-skill. There were few apprenticeship schemes or other education programs to train them for the modern world.

- Poor quality management. "Working in trade" had a low social status compared to working in, say, the Civil Service. So the best and the brightest were not interested in manufacturing.

- Lack of access to capital. Banks were very reluctant to lend to that sector which made modernisation really difficult. With the ever present threat of nationalization it was hard to raise capital from shareholders. Why invest in technology when you could be nationalised on a whim?

I don't believe that these were significantly contributory, from experience:

- Margret Thatcher: whilst I'm no fan of her, at most she just administered the needle to a sector that was already on end-of-life support.

- The unions: I worked for a large engineering company (fully unionised) that had not had a strike for 30 years. We also introduced modern automation without resistence. The reason? Good management.

UK manufacturing is what long term decline looks like. Apart from a few small examples the UK has not been a world beater in manufacturing for fifty years or more.

On the other hand the UK is particularly good at Finance, Insurance etc.

Got it. Thanks.

Those are your principles?

Would you care to share those principles?