I’ve read that they run so well in Norway because the goo they put on the power lines doesn’t get scraped off because they have two sets of rails, one for each direction.
It doesn’t bother me personally, I live inside the city so I typically walk or bike to work, so I haven’t followed the evolving scandal too much.
As someone that's worked around banking and finance a fair amount in the last few years, I'd say this is not universally true. I've never worked in the medical sphere, but I have worked on everything from tiny payment systems at SMEs to massive compute systems at banks in the top handful of the fortune 500, to quasi-governmental inter-bank communications bodies, and really I've not seen any more focus on qualifications, nor reliance on 'hard' coding interviews than I've seen elsewhere in software.
Maybe medical is different, AFAICT finance and banking ain't.
But some banks (Starling in the UK) seemed to be able to work around that and have a decent CI/CD story, and as you say - it doesn't usually make the software any better, just adds bureaucracy.
The only people who I have met who turn the interview process into a gamut of algorithm puzzles, are people who happen to be very good at them. These also don't tend to be the people running things at banks, let alone large ones.
The problem with "artisanal developers" is that they tend to overestimate their proximity and underestimate how much of a "system" they actually should build. Most of the time they lack domain knowledge, too.
If you can identify the cross-cutting interactions that will result in the biggest risk for the project, and put how to handle those in a design that is communicated well, you can leave freedom how to do the rest and the craftsmen will be appeased. But that needs a good deal of domain (and people) knowlege.
I also think it depends on how you define quality. In terms of medical my qualification criteria is based around a 0 deaths or 0 failure rate over a lifetime, not so much what it was build with. Some people would likely disagree with that.
But for who gets in the door for implementation work, it's still tech conversations and a bit of "who you know" that count over qualifications and hard tests, in my experience.
A tram
This is why I both agree and disagree with the article. Because anyone can frankly build a house, and a lot of people around the world, not only do so themselves, they do so poorly. At the same time there are a lot of parts of software that are inaccessible to most software developers.
Banking and medical software developers tend to care quite a lot about your qualifications and even the modern coding interview is sort of there because our profession lack the “trade skill approval” seal that builders and electricians get.
On the flip side of this I live in the city of Aarhus. Some years ago we got a new form of public transportation called Letbanen, which is a street level metro (I’m not sure what they are called in English). It was sort of a standard product that my city bought and it runs in both Norway and Switzerland during their winters that are worse than hours. Last week it was cancelled 5 days out of 7 because the electricity lines were frozen. I love the thing and I don’t mean to complain about it or pretend to know why my city can’t make it work when a city in Norway can, but the fact is that it doesn’t work and tens of thousands of commuters haven’t been able to rely on it for a couple of winters now.
It’s CEO hasn’t changed.
This is a standard product that was build by certified people that keeps people from getting to their jobs without having a car (in Denmark it’s common not to need a car in our larger cities), and yet, there hasn’t been a lot of consequences for it failing the same way for several years.