This is an important point to understand. Otherwise you will grow up to be one of those curmudgeons who refuses to comprehend why all the kids today insist on reinventing your language of choice, only with a different syntax, a slightly different subset of the features of Common Lisp, and kernel-level support for Twitter. (Which is crazy, since Twitter is just a fad. We had IRC back in 1988! Grumble grumble grumble.)
The way to understand things is to take them apart and put them back together, repeatedly, preferably with slight variations each time. It was true with the wind-up alarm clock I had when I was a kid, and it's true with software, today.
Of course, you do have to be careful. The CW cautions you against reinventing the wheel, not because rebuilding something isn't the best way to understand it, but because many programmers consistently overestimate the utility of understanding something as opposed to merely shipping it and moving on -- or just skipping it and buying an off-the-shelf solution. Our personalities tend in this direction and have to be watched. A year or two ago I spent valuable hours figuring out how to configure a local Linux mail server to handle encryption. The resulting solution worked, but I feared it was a bit delicate. So I slapped myself on the head and started paying $30 per year to Fastmail. (Which has apparently since fallen to $14 per year. And, of course, Gmail offers much the same for free.) I don't have to understand mail server configuration! That knowledge adds nothing to my life!
"many programmers consistently overestimate the utility of understanding something as opposed to merely shipping it and moving on"
I agree and want to add that it's not just overestimating the utility of something that is a problem but underestimating the quality of something because you did not write it. Of course that can really be true sometimes but more often not. You need to investigate and make the decision process more fact driven.
I do disagree with that statement in the case that you're just plain interested in something: no reason not to satisfy your curiosity if you have the time. You will probably learn something even if it is not the most practical thing in terms of the here and now of your project. The latter is what I thought we're discussing here though, the actual practical things to do under time pressure.
The way to understand things is to take them apart and put them back together, repeatedly, preferably with slight variations each time. It was true with the wind-up alarm clock I had when I was a kid, and it's true with software, today.
Of course, you do have to be careful. The CW cautions you against reinventing the wheel, not because rebuilding something isn't the best way to understand it, but because many programmers consistently overestimate the utility of understanding something as opposed to merely shipping it and moving on -- or just skipping it and buying an off-the-shelf solution. Our personalities tend in this direction and have to be watched. A year or two ago I spent valuable hours figuring out how to configure a local Linux mail server to handle encryption. The resulting solution worked, but I feared it was a bit delicate. So I slapped myself on the head and started paying $30 per year to Fastmail. (Which has apparently since fallen to $14 per year. And, of course, Gmail offers much the same for free.) I don't have to understand mail server configuration! That knowledge adds nothing to my life!