> it should be easy for developers to "jump into" a codebase and suggest changes You were either VERY selective/lucky with the code bases you had to work on or

> it should be easy for developers to "jump into" a codebase and suggest changes You were either VERY selective/lucky with the code bases you had to work on or never worked on complex, old, legacy code bases. Just consider the single case of having to construct a new request body for another system, without knowing what's needed. It has 50 fields, which are consumed by more than 10 downstream systems that all want a piece of it. Getting any of those fields wrong will lead to a wrong outcome in at least one of those downstream systems. You have no access to the source code of most of those systems, as it is a "principle of least privilege" company working on sensitive secrets related to, e.g. tax fraud detection and tax calculation, which actually doesn't matter as half of the code is cobol or pl/1 anyways, which you can't read. Looking at the git history, you can see no one who worked on the applications you have access to is with the company anymore. You have to find the current owners of all downstream systems, start a dialogue with them, figure out if their QA or yours will test your new request. Your only chance to get an automated e2e test you can trust is if the 60 year old QA lady who is with the company for 40 years now, who only works 20 hours a week because she has bone cancer writes one for you. Any externally perceivable bug or wrong calculation will lead to the minister of finance personally firing you. Yes, that was the second job of my life. > I wonder what the biggest hindrances are. Bad code quality, lack of useful and up to date documentation, high code complexity, high organisational complexity. > Turning the world of developer jobs into a fluid system that adapts instantly to demand and supply. Ah yes, the good old wet dream of non-technical agile proponents. Agile little cogs that provide perfect forecasting.