4. Future thinking is future trashing
Solve the problem at hand. Don't think "We can do this in a more general way and, in the future, it will be easier to add more". Adding more will never come and you'll have to deal with a pile of trash.
Solve one problem, then solve the next. A patter of problem will emerge -- or not.
6 3/3. Good languages come with integrated documentation
If the language comes with its own way of documenting functions/classes/modules/whatever and it comes with even the simplest doc generator, you can be sure all the language things and libraries will have a good documentation.
But languages with no integrated documentation will most of the time have bad documentation.
8. A language is much more than a language
A programming language is that thing that you write and make things "go". But it has much more beyond special words: It has a build system, it has a dependency control system, it has a way of making tools/libraries/frameworks interact, it has a community, it has a way of dealing with people.
Don't pick languages just 'cause they easier to use.
11. You're responsible for the use of your code
This is hard. Very very hard. It's the difference between "freedom" and "responsibility".
There is nothing wrong in writing, for example, a software to capture people's faces and detect their ethnicity, but you have to think about what that will be used on.
12. Understand and stay way of cargo cult
"Cargo cult" is the idea that, if someone else did, so can we. Most of the time, cargo cult is simply an "easy way out" of a problem: Why would we think about how to properly store our users if X did that?
"If BigCompany stores data like this, so can we".
"If BigCompany is behind this, this is good."
13. Companies look for specialists but keep generalists longer
If you know a lot about one single language, it may make it easier to get a job, but in the long run, language usage dies and you'll need to find something else. Knowing a bit about a lot of other languages helps in the long run, not to mention that may help you think of better solutions.
"A language that doesn't affect the way you think about programming, is not worth knowing." -- Alan Perlis
14 1/2. Design patterns are used to describe solutions, not to find them
(Again, personal opinion) Most of the time I saw design patterns being applied, they were applied as a way to find a solution, so you end up twisting a solution -- and, sometimes, the problem it self -- to fit the pattern.
First, solve your problem; find a good solution; then you can check the patterns to know how you name that solution.
(Addendum to types: This is what most people get wrong about adding booleans to check the number of True values.)