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.

A professional pilots discussion on this accident [1] reorganised by subject matter [2].

[1] https://www.pprune.org/accidents-close-calls/663888-aa5342-d...

[2] https://paulross.github.io/pprune-threads/gh-pages/AA5342_DC...

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.

they documented what they thought should happen instead of what actually happened.

The other way around. For example the Python C documentation is full of errors and omissions where engineers described what they thought should happen. There is a documentation project that describes what actually happens (look in the index for "Documentation Lacunae"): https://pythonextensionpatterns.readthedocs.io/en/latest/ind...

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.

Hey, thank you so much for all your hard work on psutil, it is my goto import! And this looks like a really interesting development you have created to add to the available tools for detecting those tricky memory leaks.

I have done some work in this space as well such as how to write a Python C extension without leaks in the first place [0]. This also contains a section on memory leaks, using tools like your psutil [1] This also shows where the Python documentation for C extensions contains errors, omissions or is misleading. These errors can trap the unwary.

Also I developed a Python memory tracer, pymemtrace, that uses a variety of techniques (including using your psutil!) to track memory usage at different costs and levels of granularity [2].

Now psutil 7.2.0 is out I'll update both those projects.

Thanks again for all your hard work.

[0] Project: https://github.com/paulross/PythonExtensionPatterns Docs: https://pythonextensionpatterns.readthedocs.io/en/latest/ind...

[1] https://pythonextensionpatterns.readthedocs.io/en/latest/mem...

[2] Project: https://github.com/paulross/pymemtrace Docs: https://pymemtrace.readthedocs.io/

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.

A C preprocessor implemented in Python: https://github.com/paulross/cpip

Sort-of agree, but then I saw this code in the Visualiser[0]

    try:
        import matplotlib.pyplot as plt
    except Exception:
        plt = None
    
    class Visualizer:
    
        def animate_combined(
            # Stuff...
        ):
            # Stuff...
            try:
                import numpy as np
            except Exception:
                print("numpy is required for animation")
                return
            if plt is None:
                print("matplotlib not available - cannot animate")
                return

[0] https://github.com/sql-hkr/tiny8/blob/main/src/tiny8/visuali...

Got it. Thanks.

Those are your principles?

Would you care to share those principles?

Here is the original source for this article. Warning: it is a tough read, particularly section 3.c "Case Illustrations": https://www.postofficehorizoninquiry.org.uk/sites/default/fi...

On the Professional Pilots Rumour Network there are over 3000 posts on the accident to AI171. Here they are re-organised by subject and author to help better understand this accident.

Some discussion here by the engineers and pilots that worked with the Olympus 593 on this very subject: https://paulross.github.io/pprune-concorde/docs/Olympus_5930... https://paulross.github.io/pprune-concorde/docs/Rolls_Royce0...

They always used transistors[0]. Early models had analogue computers, some digital stuff crept in over its service life.

[0] https://paulross.github.io/pprune-concorde/docs/AICU_-Air_In...

That thread is re-mixed here, by subject, for your reading pleasure: https://paulross.github.io/pprune-concorde/docs/index.html

Accenture's approach to open-source ideas is mostly via a glossy brochure [pdf] [1].

[1] https://www.accenture.com/t20150523T115642__w__/us-en/_acnme...

Customary International Humanitarian Law has something to say about this[0]. The US military has its interpretation of rule 42[1].

[0] https://www.icrc.org/customary-ihl/eng/docs/v2_cha_chapter13...

[1] https://www.icrc.org/customary-ihl/eng/docs/v2_cou_us_rule42

Try CPIP in Python: http://cpip.sourceforge.net/

For example for writing Python C extensions using 'Pythonic' C: https://github.com/paulross/PythonExtensionPatterns/blob/mas...

I know Google interviews generate a lot of traffic on HN but I thought that I'd add something that I haven't seen covered, that is, the job itself.

I interviewed twice successfully for Google and the interview experience was impeccable (interviewers were great, HR was completely on the ball etc.). The first time there was a hiring freeze so that didn't go anywhere, the second led to offers in several countries in Googles empire. Most of these I could not accept for family reasons but one I could although Google were quite secretive about what the job was.

I accepted thinking that, well they know me well enough by now and what I can do. A mistake. Upon arrival it turned out to be writing an Android app which is completely the wrong end of the spectrum for me - I have never even written Java. I was been benchmarked against people who seem only to have done only that. The other thing that made me realise that I had no long term future in Google is that it was made clear to me that any experience of working for other software companies or other industries was neither interesting or useful. If you have a lot on your C.V. like I have this is problematic.

So I left after a few months.

Sure Google is a fabulous company, does some amazing stuff and has some great people (perhaps not as uniformly great as they'd like you to believe). If you fit the mould tightly enough you will have a lovely time.

TL;DR - They should not have hired someone like me, I should not have accepted.

The interim report was covered here before [0] but this final report has more detail.

[0] https://news.ycombinator.com/item?id=9026028

Here is another attempt to try and get health care systems to learn how to deal with fallibility. In this case a woman died unnecessarily during a minor operation, however her husband was an airline pilot and he is now trying to teach the UK National Health Service the lessons that airlines learned long ago: http://www.newstatesman.com/2014/05/how-mistakes-can-save-li...

A more wide ranging article: http://www.economist.com/news/science-and-technology/2165007...

This is exactly what we do where I work. We send them a small problem that any competent person can solve in 15-30 mins in Python/Java/C++. It is amazing what an effective filter this is and submitted results range from fully tested code, innovative O(1) solutions down to code submitted in MS Word that gives the wrong answer.

As a front line filter it is cheap, simple and revealing.

Well I am not sure about Facebook but a relevant comparison might be the British newspaper the News of the World[1]. It held an (assumed) unassailable position as one of the oldest and most widely read English language newspapers. It was shut down by the revelations that they (allegedly, and plausibly) hacked voicemails of a murdered teenager. A privacy issue.

[1] http://en.wikipedia.org/wiki/News_of_the_World