> In Germany et al employing a worker is seen as a favor to this worker whereas in US it's the other way around.
But again, this is only true because of the delusional rock-star fantasy which grips the tech industry. The vast, vast majority of software developers are not rock-stars. They are seen as disposable - precisely because they are - which is why mass layoffs can continue to happen as a predictable part of a development lifecycle.
You are approaching this discussion as though the key factor is the pay of a company's top employees - but those people are a tiny, tiny fraction of the people employed in the software development industry.
> There is no argument whether American software/hardware industry is doing better than EU software/hardware industry
Yes, but what people are (rightly, and increasingly) concerned about is how well the employees of those industries are doing. The fact that US tech makes more money than EU tech is largely irrelevant to the discussion of whether and how those employees should unionise (they should).
> My point is none of these will ever solve the problems American SWEs are trying to solve. You cannot build an Uber this way. You cannot make rockets go to sky this way. You cannot write Airbus's OS this way. You cannot do these and retain the same, competitive quality required in this industry. You cannot do that unless you spend a lot of resources for R&D how to automate programming.
Yes, but again - most developers do not work on these problems. Most developers aren't building an Uber. They're not building rockets. They're not writing Airbus OS'. And in each of those areas - what can be automated will be.
> No C programmer ever got fired because GCC suddenly became too good at optimizing C and "their job was automated".
Plenty of developers have been fired because management decided that throwing faster hardware at slow software was more cost effective than paying slow humans to make slow software work on slow hardware. Optimisation of code wasn't really what I was thinking of in terms of 'automation'. Rather, what I was arguing is that machines, given a (relatively) well defined problem, will be able to implement a solution that is cost effective enough to be cheaper than hiring developers.