> Let me give you another example that maybe drives the point home better: Have you seen the videos of how Minecraft was made? A very short amount of time was spent on getting the I/O to the filesystem to work, of setting up a window and filling it with colors, of creating the basic 3D world. I believe that is a huge part why not everybody can write a successful game as Minecraft. Because I don't have trained the routines, I need to spend a considerable amount of time getting all these basic things done before I can start with an actual 3D game. Thus an experienced game developer is already done with his first demo in the time I am done with the basics. And at this point he has a demo to show for, I have nothing. So he even gains more motivation in the same time to continue, and he may even gain some first user feedback. This will make him code longer (huge benefit, I give up at this point) and he will also develop more in the direction that is fun for players (huge benefit two).
I think Minecraft's success is mostly luck and doesn't really prove anything. A lot of very experienced game developers write games that fail, all the time.
You're right that as a programmer, when you start working on something you're not yet familiar with then there will be a period in which things that are routine and automated for someone experienced in that area are not yet routine for you and you haven't yet automated them. I just don't see that as particularly important. You learn how to do these things, then you automate them, and you've only needed a small one-off extra effort compared to the experienced programmer doing the same thing. 80% or more of the work of writing a program isn't solving business problems directly, it's writing the tools that make it straightforward to do the actual business problem solving. Most of the skill of doing this is transferable, and learning 10-20 languages really doesn't involve that much overhead.