We may be using different definitions of "best." In some companies, the best developers are the ones who keep their heads down, do what their told, and don't try to question authority, decisions, or direction. These traits are highly desirable precisely because people reliably do what their told.
In other companies, creativity is considered an asset. Most of the important work done at my previous company was largely completed by one very productive intern, which was surprising to discover. And at each of the companies I've worked at, I was given freedom to determine direction and implementation of the projects I was given, as long as the results were excellent.
Both approaches have merit, but if I were to bet on one, I'd choose the company that's liberal in granting freedoms but also willing to fire someone if they turn out not to be able to deliver. This has generally been a recipe for success at most startups, for example.
It's more cutthroat, but in a different way: the former is cutthroat politicking, whereas the latter is based entirely on a developer's capabilities. I'd rather be in an environment that rewards effectiveness rather than alliances. And when your effectiveness can only be demonstrated within the very narrow scope and boundaries set by your boss, then people who care about being effective tend to migrate elsewhere.
Most of this can be summed up as "The idea of paying your dues is anachronistic."
It takes time to get up to speed and to build trust when you are performing high impact work on a medium-large project especially if you don't have prior domain knowledge.
> Most of the important work done at my previous company was largely completed by one very productive intern
> liberal in granting freedoms but also willing to fire someone if they turn out not to be able to deliver.
I suspect we simply deal with different sized systems.
The idea that an intern could do most of the important work implies you work for small companies.
In comparison my current project has ~90 devs.
Likewise you have this idea that you can quickly determine a good choice from a bad one. I'm still cursing design decisions I made 3 years ago that everyone thought were great at the time. If I had left after 6 months I would still be patting myself on the back.
Again that seems to apply better to small companies.
The company prior to my last had 50,000 employees. We were still able to design and implement a solution for a core aspect of the division. I had to push in the direction of Python + Redis, but when people saw the results, the higher-ups listened to our team.
I think you're right that if a system is massive, there won't be many major changes to it. But that's true regardless of who has authority. It's always possible to solve smaller business problems with self-contained projects that can then be integrated into the larger system. But not if an environment is set up to prevent someone from doing this by forcing them to work within the constraints of the existing monolith.
(It's possible to do this without creating a microservice, in some cases. The important part is simply to be allowed to experiment with alternate solutions, as long as it's not interfering with your main duties.)
How big was your team? How big was your project (kloc + timeframe)? How many other teams did you have to integrate your solution with? What effort did they have to put in to consume your work?
Again I think we are simply dealing with different scales of systems.
The two best developers I know have spent 12 years at Microsoft and 6 years at Google respectively.
What makes you think you need to switch jobs every 12-18 months to make a name for yourself?
And what makes you think the best developers care about making a name for themselves?