Good points. I'd also add: management/companies can fail developers many ways.
1) Too cost sensitive so forcing developers to work with out dated tools/restrictive computers. I worked in healthcare and you needed middle manager approval for a monitor larger than 19" (not your boss but your bosses boss). So you got a single 19" screen and windows XP (because IT didn't want to bother trying to support anything but the standard that all the secretaries already knew how to use).
2) Similar to 1) but a lack of bravery. In this case there is money around your boss is just too shy to step up and say: "hey our development staff could use a couple new people, or a week off to do training, or a new CI server". Another one is culture: not fighting for a culture that is supportive of creative people/professionals. Requiring a 9-5 day in suits and ties from developers when the team would rather work 10:30-6:30 in shorts. Your free to require that and developers are free to go somewhere that doesn't make them dress up like they are front desk clerks dealing with customers face to face all day. They manage by keeping their department of senior managements TODO list.
3) Giving detailed technical specs when they no longer have the technical knowledge to understand the tools that are currently being used. Manage towards maintainable business outcomes not lines of code on a screen.
Part of the problem is as others have pointed out already too: most engineering isn't innovative. How much of everyone's day is adding/making more a new page to list a customers address and order information? But is more than that too it is inertia a lot of which we do to ourselves. Things were done a certain way because the projects senior dev at the time code reviewed it into that standard. Now you have 1M+ lines of code all structured a particular way. Guess which way you'll be expected to code your new module? Guess how far a request to change that still and refactor the existing code base this month rather than pound out a few more features will go? You can get lucky and have management that understands and is good enough to say: we aren't going to do it that way anymore but it becomes the culture. You can go to a newer project, perhaps even in the same company, where the culture is still forming and either it is the way you like our perhaps you can help steer it that way: but guess what? You've just become that senior developer that people 10 years from know will likely be wishing it wasn't done that way. Change is the way developers like it: standardization is the way process management and product lines like it.