I read just enough about it that I can get a "Hello, World" program written and running. I then try a few things to modify that program to learn more about the language. In particular, I'll often try breaking it in several different ways. If I know what I broke, then I can learn how to interpret error messages.
Once I've done that, it's time to start on a small project. I just start coding and looking up what I need to know. I know in advance that my code will be bad. In fact, the more often I encounter some piece of documentation that leads me to say, "Oh, I should have done it that way", the more I learn.
Sometimes. It depends on what I'm typing. Documentation I mostly touch-type. Code, never. Touch-typing is one of those skills that pays with an economy of scale. The time it takes to place both hands on the home keys isn't justified when I will have to remove them too frequently.
I agree 100% about Ubuntu, Python and PostgreSQL. They're an excellent tool set. You'll want to learn how to configure PostgreSQL. Go to the project website. The manuals are quite good.
Both Vim and Emacs have some very nice features. Compared to a full-featured IDE, yeah they do look a bit old school. Even so, you can be incredible productive in either of them. I use Emacs myself, and I can't imagine trying to live within the constraints of an editor that I can't extend.
Absolutely! By learning to deal with pointer manipulation and memory allocation, you can learn what it is, why it is necessary and how to recognize when it is broken. One of the problems with garbage collection is that it suffers from a memory management problem at a higher level of abstraction. There was an entry in an autonomous vehicle competition a few years ago that stalled. Physical objects in the environment were represented internally as objects in the code. When the vehicle passed them, they were moved to a collection of objects that had already been identified but were out of the field of view. That collection grew unbounded even with garbage collection because every one of those objects was still referenced.
One of the best things about HN is precisely that there is a core focus to it, but that it touches on many related topics. Some of the most valuable areas for exploration are where one field of knowledge meets another. Each sheds some light on areas of the other that haven't yet been explored.
At 44, I'm backing up your argument. But honestly, I had already accumulated most of my eclectic intellectual curiosity a quarter century ago. Even so, I still browse the technical books at bookstores. Libraries are hopelessly out-of-date on anything technical that would interest me. I don't need the latest power users' guide to anything. I'm interested in new insights into building something that has never been done before.
There are situations where the order of evaluation is not guaranteed. The big one that I've seen is evaluation of expressions as arguments in a function call, but there are others. It is easy to create floating point expressions where because of rounding, the results will differ depending on the order of evaluation. I'm not aware of situations where the order of operation differs from one execution to the next. However, I could see a compiler generating different code for the same expression when it appears in more than one place in the source code because of optimization.
Your motivation to learn the language will be a strong factor in your success. Wanting specifically to communicate in the language is a big plus.
Get as much contents as you can and use it. Since you are studying Spanish, if you have access to a Spanish language cable network (or a broadcast TV or radio station in some cities) use that. Start with something that is fairly predictable, like the weather forecast. Get podcasts and listen to those. Rent movies in Spanish (and turn off the English subtitles).
On the other side, find people to talk to. Ideally, you want native speakers. You want to spend extended periods talking in Spanish. Force yourself to say what you have to say in your new language, even badly, ungrammatically. You will make mistakes.
Two blogs I like that emphasize exactly these two facets of language learning are:
You're right. And the problem with that is that the only opportunities for 100% coverage happen when you can start a project that way with the buy in of everyone on it. That is only likely to happen when everyone is familiar with TDD and comfortable with it. That creates a substantial hurdle for a group to cross when adopting it for the first time.
I prefer the approach we used here (at a non-startup). We simply decided that we were going to use automated tests as much as possible on a new project. Everyone was encouraged to use them. Our coverage wasn't 100%. However, when you are committed to creating an automated test case to reproduce any bug regardless of how the bug was originally found, your coverage expands. Usually you can write variants of the same test to cover related areas.
I can't speak for every member of the group, but my total testing time went down slightly and my test coverage improved enormously. Full TDD is not necessary in every instance. Just because you can't immediately make the jump to full TDD doesn't mean that automated unit test tools won't make your code better, and your testing easier.
Once I've done that, it's time to start on a small project. I just start coding and looking up what I need to know. I know in advance that my code will be bad. In fact, the more often I encounter some piece of documentation that leads me to say, "Oh, I should have done it that way", the more I learn.