I see it as a problem of maximizing the P * PC product (i.e. amount of work accomplished), subject to a linear constraint a*P + b*PC = 1. It takes time to produce stuff (factor a) and it takes time to increase production capability (factor b) and there's a finite amount of time you have at your disposal.

Unfortunately this trivial concept is pretty hard to apply with precision in real life. It's impossible, extremely fuzzy at best to measure a, b, P, and PC. However, it's pretty easy to grasp that the amount if work accomplished is really small if either P or PC is small.

When to stop training and start producing?
Why not do both at the same time?

Here's a quote from an interesting article I read yesterday:
"Lots of the experts in the world will tell you that they didn’t practice much, but that is usually because they don’t consider doing what they enjoy as practice. The kid spending hours outside playing soccer with his friends doesn’t see it as practice, but it is. The designer sketching what he sees out his window does so because he loves it."

More here: http://www.drawar.com/posts/How-To-Be-An-Expert-Developer-or-Designer

There is certainly a balance. I used to be a perfectionist, tweaking my work which never quite got out there. I think there are a lot of people out there like me who get stuck in place because of that.

That's why I'm with you: there's a balance, but if you have to choose a side, choose producing tangible results. In the end, it's mostly a false dichotomy: by doing, you are also learning.

Depends on the field and nature of the task, since some require a lot more knowledge than others. Learning by doing seems to be a great way to go about building a web app for example. Not so if you're gunning to create a new programming language or a new operating system.

The distinction there I think is the difference between systems and products. When building systems, you start with architecture, and architecture is fundamentally hard to change once the building is halfway up.

As it happens, those involved in architecture, whether it be the architecture of a commercial office building, or the architecture of a video sharing site, are wrestling with immense complexity, and yet affect many people through seemingly trivial decisions.

To that group, study until you can somewhat reproduce current systems, and then practice and iterate until you've got a refined system.

It's a good question Sebastian. I think the answer is a continuous mix of both. I believe in learning by doing. Test the things you've learned by starting a small project. And every time you do any kind of project, try to encapsulate lessons that you can apply to future endeavors. Ultimately there is no value in training on its own - the point is to do. And yet, another way to think about your life is that everything is training to prepare you for what's next.

See my post: 21 Lessons Learned from 21 Weeks at a Startup

I think it ultimately depends on who you want to be.

If you want to have a lot of answers, then Production Capability might be a better path for you. Otherwise, if you want to have a lot of products under your belt, then obviously starting sooner will be better for you. You can always pivot to the other extreme when you're satisfied with what you have.

Most ambitious people do want both. However you're still more likely to favor one over the other. So go where your passion takes you, but still leave a little bit of room for the other. In my case, I want to be as knowledgeable as possible about many things. Obviously I still want to produce, but I tend to favor learning over production. (Even producing, but nothing practical, it's all for the sake of learning!) So whenever an opportunity comes to produce something of value, I force myself to stop learning a while and build it, knowing I'll jump right back into learning when I'm done.