I recommend learning less languages, but learning each one in-depth as much as possible.

You’ll be more effective as a programmer with a mastery of one language than apprentice level at many.

I totally agree with your prescription and recommendation for achieving optimal results.

My advice is more geared towards pragmatism for the general beginner.

So, I guess what I am saying is that what you recommend is exactly the path I would, myself pursue today, to achieve the best overall knowledge and success in the field.

You’ve laid out a perfect road map for becoming an expert.

But, not everyone is interested in the most optimal path and has the follow-through to get there.

I’ll have to think on this some. Great comment.

Good points. Thanks for the suggestions. I agree. You are right that my focus is on encouraging to learn something rather than getting stuck making a decision about what.

Considering your points that each new language is exponentially easier and that the important thing is to get some proficiency in one language rather than skipping around, choosing an easier language is quite important. Perhaps a language that doesn’t require OOP theory off the bat would be a good choice.

Conversely, some languages are more forgiving of “bad habits”, and while easier, should perhaps not be the foundation that sets initial habits.

I think your intent is to motivate them to focus on learning something rather than be stuck on choosing what to learn. With so many great points, your readers would be well served if your conclusion distilled them to a few of the better options.

The best way to learn is to jump in and use it, so to get to the level of Joshua Bloch’s,”Effective Java” (Amazing book by the way) your best bet is to get your hands dirty and start using it.

If you get bogged down or finish a project but think it could be better, I’d recommend a process called “Clean Slate Refactoring”. Start a completely blank project, and rebuild it, copying over the parts you think are good, and improving the parts that aren’t. You’ll find the insight you gained from the first project makes the 2nd iteration come out with much simpler, smaller, more powerful, and much better code.

You can also use that to mitigate the danger you mention of breaking an existing project. Instead of modifying a project you don’t want to break and uses concepts you aren’t clear on, start up a blank project and reproduce it. You have a working version you can look at when you get stuck and it will force you to understand the areas you aren’t clear on (or find an alternative).

Another way to get past the fear is to make a copy and work on that or use a source code management tool like git.