I don't really know where that's leading (forest). In essence, I want to learn about coding before I learn more coding, so that I can direct my studies in the directions I want to take them.
I think the "forest" is knowing different programming metaphors, and knowing when to use which one. A proper choice of metaphor will allow you to solve the problem more efficiently -- which means that the program is not only quickly written, but also easier to understand (though sometimes only for people familiar with given metaphor).
By metaphors I mean things commonly called "programming paradigms" and "design patterns"; the former are more abstract, the latter are more specific templates for solving given set of problems. It is good to know these individual metaphors, and to be aware that they exist and you can choose the one you need (instead of seeing every problem as a nail, because you have completed a good hammer-using lesson and you are a certified hammer expert). Different programming languages put emphasis on different metaphors, which is why a good programmer usually knows more than one programming language.
A programming paradigm is an answer to question: What exactly is a program?
Depending on your problem, a different paradigm is useful. A functional paradigm is useful when you want to calculate functions. A command (imperative) paradigm is useful for tasks you could best describe as series of steps. An object paradigm is great for a user interface, together with "if this is clicked, do this" reactions. Sometimes you should use different paradigms for different parts of your program; for example a program for solving mathematical equations, with a user interface. Sometimes different paradigms support each other; for example you can write a list of steps to do, and then describe additional aspects such as: "and by the way, every time you read from a file or write to a file, make a note in the application log".
On the bottom level (machine code) it is all a sequence of commands for the computer. Thus the imperative paradigm is most frequently used, because it is difficult to avoid in some tasks, while in other tasks you can still use it instead of other paradigms (even if it sometimes results in a horrible code). Object paradigm is great to split complex code into small manageable parts (although most people split complex code to complex parts, thus creating imperative/object hybrids), and it is also a popular marketing buzzword. Function paradigm is the right thing to do when you have functions without side-effects (the same inputs always produce the same outputs), because calculation of such functions can be cached, paralelized, etc. (Again, most people create imperative/function hybrids by writing functions that have almost no side-effects.)
There is a pattern here: most programmers are stuck in the imperative paradigm, and don't really understand the constraints and benefits of the other ones. Many languages support multiple paradigms to allow you use them as you need, but this also allows the abuse. It is good to have an experience with a language that only allows one paradigm and nothing else, to understand the essence of the paradigm, so you can later use it efficiently in other languages.
In theory, a perfect programmer needs these skills:
In real life, in most job interviews only the last skill is required, because it is most easy to evaluate by people who themselves don't understand programming. ("Do you have Java experience?" Check. "How many years?" Write a number. "Did you also work with databases?" Check. "Do you know SQL?" Check. "Do you also know Oracle databases?" Check.)
Presumably you read Less Wrong because you're interested in thinking better.
If so, you might be interested in another opportunity to improve the quality of your thinking: learn to code.
Like nothing else, coding forces you to identify flaws in your thinking. If your thinking is flawed, your program won't work, except by accident. There's no other discipline quite like this. If you're a mathematician or physicist and you solve a problem wrong, your paper won't tell you. Computer programmers have to measure their thinking against the gold standard of correctness constantly. The process of uncovering and fixing flaws in a program, usually called "debugging", typically takes up the majority of the time spent on software projects.
But this is only the beginning. You've probably heard something like "there are some problems that humans are good at and some problems that computers are good at". This is true. And once you learn to code, you'll be able to exploit computers to solve the problems they are good at. Having a computer to write software with is like having a hi-tech mental exoskeleton that lets your mind run harder and jump higher. Want to know what the second most common letter for an English word to end in is? That's a 15 line script. Tired of balancing chemical equations for your homework? Automate it.
Two more benefits that have less to do with thinking better:
Having enough coding knowledge to be dangerous may take persistence. If you tried and failed in the past, you probably either got stuck and gave up because there was no one to help you, or you just didn't keep at it.
I've take two different introductory programming classes now to meet college requirements. The students in both seemed substantially less intelligent to me than Less Wrong users, and most were successful in learning to program. So based on the fact that you are reading this, I am pretty darn sure you have the necessary level of mental ability.
Starting Out
I recommend trying one of these interactive tutorials right now to get a quick feel for what programming is like.
After you do that, here are some freely available materials for studying programming:
Here's a discussion on Less Wrong about what the best programming language to start with is.
If you're having a hard time getting something up and running, that's a system administration challenge, not a programming one. Everyone hates system administration I think, except maybe system administrators. Keep calm, put your error message into Google, get help on a relevant IRC channel, etc.
Once you've got the basics, a good way to proceed is to decide on something you want to write and try to write it. If you don't know how to get started, start making Google searches. Soon you'll figure out the sort of libraries/frameworks people use to write your kind of program.
At first you may just be aping what others do. For example, if you want to learn something called "bleh", searching on Google for "bleh tutorial" is a great way to start. Finding a working program and modifying it to see out how it changes is another good option. Soon you'll graduate to appropriating sample code from documentation. As you write more code and see more of the software landscape, you'll be better prepared to craft original approaches to writing software.
See also: On the Fence? Major in CS, Teach Yourself Programming in 10 Years, Computer Science and Programming: Links and Resources.