Flederfalter
I'm serious, I don't know what the "right" thing is to learn from. I feel overwhelmed by the massive information you can find in books/internet/people who proclaim to be as "good programming". Even CS school doesen't really help me or make the situation more worse.
I feel you. I'm not very close to the industry so I don't have a good feel for these things, but my current philosophy on this is as follows:
There are so many different
ways to program effectively and so many different
things to program, that there is no one right approach to it all. What might be good practice for making a desktop application could be totally different than making something for the web, or doing some embedded code somewhere, or making a game, or any of the myriad of other possible things to do. Each of these, and even different projects within each broad category, has different requirements and different constraints (sometimes obvious and sometimes subtle).
As if that weren't enough, you then have to consider that there's many different effective methods of achieving the same goal. Many different schools of thought, philosophies and disciplines which all can act like different paths to the same destination, the same goal. Which is: reliable, maintainable code that's correct and efficient (which priority you give these is the only different between some philosophies, see
rise of the worse is better). What might work well for one combination of person and project might be totally different for another combination of person [or team or whatever] and project.
I think, as with all fields, you can't go too wrong by just starting with the fundamentals and history first. All knowledge is built on past knowledge. So, to learn how things have evolved and how they worked in the past is just a good general philosophy to life and learning.
But going from there as a starting point, one thing I've found is the more (different and varied) perspectives on things you can get, the more powerful you become. For years I've been programming at a high level of abstraction. So this low level stuff is very refreshing and enlightening for me. I grew up getting taught OO in all my classes, so this recent vogue of functional programming is likewise refreshing. The more ways you can look at things, like walking around an object to get different views of it, the more depth and nuance you see to whatever you're looking at.
But I guess I'm digressing a bit from the thread topic. I could go on at length about why HH is important but for now I'll just mention one simple example that kind of encapsulates [in the normal sense of the word, not the programming sense ;)] one of the main things I appreciate about the philosophy behind HH. In yesterday's stream (16), Casey checked his notes to look at some compiler options and saw the answer he was looking for. So many people (it's very natural) will stop there and just say "oh, it's -xad [or whatever], that's what it is." But what Casey did is then he says something like "oh but
let me show you how you could know that." And that is what makes all the difference.