The line itself isn't being serviced, it is the station. UK-bound lines take up excessive space due to Brexit-related security controls, so there isn't enough space for both the security and the construction areas.
They're still running the line from London to Amsterdam, which is why the line is still running and why the trains have to deadhead back.
The UK was never part of Schengen, but it was part of the single market. So while passport/ID controls have always been performed on the UK border crossings with other EU countries, customs controls had not – until Brexit.
I am not aware that customs controls are made in the passport area, at least not between London and Paris. It is done at the exit of the terminal, in a non blocking way like in UK airports (and always was, they were already looking for illegal products before Brexit).
The only appreciable difference I see a need for a border guard to physically inspect and stamp passports, which I suspect slows things down. I guess EITAS checks in the future too.
Once EES comes into effect the stamps may not be necessary anyway, but much like fusion, it's perpetually 6 months away.
The main difference is that pre-2021 UK travellers simply had to show travel documents whereas now they have to get them stamped.
On the surface, it isn't clear to me why that makes much of a difference in service time, but the CEO of Eurostar pointed a finger to these changes in January: https://www.bbc.com/news/business-64390979, claiming their trains carry 30% fewer passengers due to station bottlenecks.
And yes, they claim the EES checks should help speed this bottleneck.
It's total nonsense. These trains are running now with the same amount of space with no issues - it's only 4 trains a day, with the closest one being 2 hours apart. You can easily check a trains worth of people in 2 hours, brexit or no brexit (and I am sure eurostar would have changed the timings if in some crazy world it did require more than that).
What the article should say is 'given the requirement to do full passport and security checks'.
Nothing to do with Brexit, same thing happened before. It's because the UK wasn't in Schengen and the channel tunnel regulations require security (which is a waste of time, but it's because the tunnel was inaugurated when the IRA bombing campaign was in full flow)
North America is already auto-dependent and EVs are an important piece of the puzzle for that region. Their point is that EVs won’t possibly work resource or cost-wise when that 82% inevitably gets richer and asks, “what about me?”
I wouldn’t say elitist. I think different environments have different needs.
The US, for example, has roughly 1/4th the population density of the E.U., 1/0th of India’s and Japan’s, 1/5th China’s.
Maybe Europe and Japan can urbanize and get connected via HSR, but, the US is much sparser. Suburban houses with yards make a lot more sense; cramming into the cities and relying on public transportation just feels stupid to a lot of people.
I don't really think law, medicine, and software engineering are the main drivers of wage inequality, though. If the lowest wage was minimum wage and the highest wage was a programmer salary, the Americas would be a very equitable economy.
Automating America's remaining paths to the middle class will only serve to widen the gap between capital owners who will own infrastructure for automation and those shoved into a shrinking piece of the unautomated pie.
The comment you’re replying to is making that point: that people who earn a decent wage from the knowledge economy are threatened by AI and oppose it because of their interest in the current system’s inequality.
It follows that if it is unjust for those who are knowledge workers then it is unjust for those who are service workers (unless you can morally differentiate them).
Perhaps if inequality is wrong then it’s the system that creates inequality that should be looked at rather than preserving rent seeking by knowledge workers refusing to compete with AI while perpetuating inequality on those who aren’t powerful in the current economy?
I think you're reading a lot more into my comment than is there, tbh.
The comment I'm replying to said something to the effect of: "this may be a good thing because by democratizing highly paid professions, lower income workers will be lifted."
My comment said something to the effect of: "I disagree, I think capital owners will simply get more rich and the middle class will collapse further without raising anyone."
Of course our society doesn't give service workers a fair shake. My partner worked in a grocery store for a large chunk of our relationship. The schedule inconsistency, the sleep deprivation, the lack of healthcare, no vacation, no real sick leave, and on. Much of my family works in blue collar oil positions. There you're paid a bit better, but you throw away your body to make a dime. I know.
I'm just not convinced the default outcome of automating some knowledge workers is that magically somehow that makes everyone's lives better. I think legislative change of some kind would have to happen if that's the outcome we want.
And ironically it seem like the things you'd positively attribute here to a product manager used to be/are actually part of the scope of what was traditionally a "project manager" or "program manager."
For example, look at the scope and definition of a "program manager" from Microsoft or the US DoD in the 1980s, 1990s+, as well as literature describing the role of a program manager and the discipline from that time.
Why’s that ironic? There didn’t used to be frontend / backend / full stack devs either. As software engineering has matured and grown in scale, more subdivision of responsibilities is a natural outcome of that. We’re not all just directly writing code on mainframes and our customers aren’t just < 1k of users who directly call us on the phone if something goes wrong anymore, it’s millions of people using services 24x7
now. MS wasn’t making real-time collaboration systems and cloud sync in the 80s and 90s. They were making a stand-alone offline machine that barely could install device drivers and didn’t know what the internet was. Completely different products, and much simpler.
What subdivision of responsibilities? Clients and servers were divided for as long as clients and servers existed. Full stack is aggregation of responsibilities. DevOps too. Dedicated QA is rare now.
Most companies with product managers have fewer customers and less complex products than 1990s Microsoft.
Yep, a common pitfall is to not understand how product managers are supposed to do, and thus they just do project management, which often has neutral or negative value.
Sometimes you need a formal project. We’re kitting out a new office over the next couple of years, it’s a major programme of multiple projects, all which interact. At the end of it though we have a building fit for purposes following the plans currently set. I’m sure those plans will adjust a little, but the end date is January 2025, or July, or something - I’m sure the date will slip.
You can’t build a £20m facility with a series of sprints.
Well, the Empire State Building was famously built as a series of sprints...
You need a formal design. This doesn't mean you need a formal project. Some amount of planning ahead very obviously helps, but how much is debatable, and when you have people whose sole specialization is "planning ahead", you are certainly past the point where it's too much.
Anyway, the most valuable people are the ones "planning behind", looking for what was left broken and could be done better from now on. Project management defines those people out of existence.
Think of the "formal project" is the API by which executing the design can be understood by all stakeholders.
It is a high level abstraction that allows all parties to understand what they need to do and when they need to do it. For large projects it is simply essential - you need your external vendors to plan their availability, months or sometimes years in ahead, so that they can commit to the timeline.
If you're lucky enough to work on large software projects where there are no managers or other stakeholders asking "and how long will this take, exactly?" then maybe the design is enough.
But pretending planning ahead on large projects that is something that will just happen by osmosis or people "just doing it" simply won't work. Good project managers who do what they're supposed to are worth their weight in gold (just like good product managers).
> If you're lucky enough to work on large software projects where there are no managers or other stakeholders asking "and how long will this take, exactly?" then maybe the design is enough.
How well can your project managers answer how long will this take? Because on my experience, 10000% delays are all but routine (ok, on construction it's usually bounded to something around 1000%). And how much value do people that can give you an estimate between 1% and 10000% of the target?
> But pretending planning ahead on large projects that is something that will just happen by osmosis
I'm telling you that planning ahead has a small value, following up with the plan has a high negative value, and the thing with a high positive value that is reexamining the plan is fought against by the practitioners.
If they are good project managers, they plan for non-routine delays and account for them in the project schedule. Before people are allowed to commit to schedule, the project managers make sure that these people have properly scoped and estimated their part of the work, by asking pointed questions, using their domain expertise and general experience to figure out if they're being bullshitted or not.
If things start to slip, they find out where and why and apply what pressure they can to get them on track. If they cannot get them on track, they then liaise with everyone downstream to make them aware of the slippage, adjust the entire schedule, and get everyone reorganised.
It's not just putting things in the calendar and forgetting about them - it's a constant, ongoing herding of cats to get them all going the same way.
It sounds like you just might not have been lucky enough to work with really great project managers!
That's kind of their job, though, right? Couldn't you have the same complaint about doctors, pilots, or engineers who try to write? Writing isn't what they do.
Just seems like there will never be a Scotsman capable of appeasing this standard.
Lots of people write. The author of the linked post is a journalist. His job is to journal things, if I can be loose with language, and not just to be a writer. The arrogance that comes through his statement is pretty thick, and I think, of all people, I would like journalists to be as unbiased as possible. And arrogance seems like it could leas to bias quite easily by allowing assumptions to creep in.
Not sure where you are based, but in the US I know a lot of schools shoot for the ABET accrediting guidelines[0]. They directly call out the areas you're asking about:
Exposure to computer architecture and organization, information management, networking and communication, operating systems, and parallel and distributed computing.
But they only require "exposure" to these concepts whereas algorithms, theory, programming languages, etc are required to be "substantial." Which matches with your perceptions:
It seems most are exposed to them partially through project work but without the base knowledge.
Eh, steel manning the role it kind of just sounds like a TPM. When roles are crisply defined, a good TPM has been a life changer for my job satisfaction. You basically get permission to farm out a lot of the most annoying parts of the job--status update forums, timeline management, and dependency wrangling--to another person who does it full time.
I've seen both versions of these. A good TPM is extremely valuable though, especially for work that is highly reliant on coordinating other teams. The bad version was a net negative to team productivity.
