tom5

The most efficient way to learn is to find out the original problems that these new things trying to solve. Learn as much as possible about the historic context of these problems and solutions. Having this big picture in mind will enable you to learn much faster and deeper.

Another thing is to apply what you just learned in practice as quick as possible. That will help convert your new knowledge to ability.

1. Requirement. Try to give clear requirement since changing requirement leads to frustration. In real world, requirement keeps changing. Try to explain the change and reasons behind it and it will help developer understand the big picture.

2. Verify Implementation. Test code and help developer to find bugs as soon as possible. If there is any issue, you want to find it earlier. This is good for your teammate and yourself.

3. Try not to micromanage. Open to new solutions and leave details to developers as long as the deliverable meets requirements.

4. Try to have less meeting.

How about starting with a web site? It is much easy to iterate and validate the idea. Once you get enough usage and feedback, then start to build app.

You asked a good question and I do think programming is a good way to help lean math. This is a good book:

Numerical Recipes http://nrbook.com

Yes, Java is relevant, especially in large companies. A lot of back-end systems are using Java.

For learning, you can start with reading Java Language Specification. And then you can read Java Virtual Machine Specification. After that, you should have very good understanding of big picture. Then it is just about writing code using APIs.

As for back-end, there are a lot of topics (not specific to language). File system, networking, distributed computing and others. In real production systems, it is about how to compute/process within certain time-frame. And how to operate the production systems.

I think it is more about paradox instead of fear.

a)you want to add enough features to attract/impress potential users. b)you want to ship it, so you can get feedback asap.

a) and b) are pulling to opposite directions, hence the paradox. There is no easy solution for this.

However, if you change the question to "what do I need to build to test my assumptions (about the market and user)", the answer will be more obvious.