Tennis and programming = bad analogy. When you program you have to know far more than just how to make the code work. You're usually learning at least 3 languages to get one program working, you have to understand the interactions between your program and the server or the OS and the hardware that your software will run on, then you get into maybe learning how certain compilers work, your IDE and other tools, frameworks, object oriented or functional style, etc. On top of that everything is constantly changing on you.
In tennis you have a set of unchanging rules. The equipment may advance slightly over the years but they're basically the same. So you really in tennis you learn the rules, strategies, equipment, and you're good. You could program all your life and not even scratch the surface of it all. That's why I think edw's advice is totally perfect. Learning by finding out how to get a task done is the way to go because you could learn all sorts of programming related stuff all day that you never use. In tennis you're far more likely to get an opportunity to use all you've learned.
Nice try with the tennis, it's a good argument but it doesn't work out in the end.
Lets not get bogged down in the tennis; I don't even play tennis, I just chose it because almost everyone recognises that investing time in fundamental skills is important in sports.
I spent some time, last August, playing with Haskell.
This didn't help me build the next thing I needed to. I didn't need Haskell to help me solve any immediate problem either then, or since.
I spent that time because I believe that the experience will make me a better programmer, in the long run, and give me a bigger toolbox with which to conceptualize problems.
I thought that, in the long run, in some sense, it would improve my fundamentals.
You seem to be arguing that things are so dynamic, that there's no point making long term investments like that.
If things were so dynamic that I thought there was a good chance I'd be making sandwiches for a living next week, I'd agree.
But things do not change that fast in programming.
There's a copy of SICP on my desk that I'm reading; its the 2nd Edition from 1996, of a 1984 book, and the code is in Scheme.
And I don't feel like I'm wasting my time reading it, at all!
Yeah, you're right. Enough with the tennis. I think there's equal merit with what you're saying and what Ed is saying. We're trying to answer a question that doesn't really have a right answer. Add to that the fact that there are so many ways to evaluate how much youve improved or how you stack up that maybe we should focus instead on how not to measure these things.
I've been so tired that I'm prone to losing my train of though half way through writing so hopefully my last comment wasn't totally incomprehensible.
In tennis you have a set of unchanging rules. The equipment may advance slightly over the years but they're basically the same. So you really in tennis you learn the rules, strategies, equipment, and you're good. You could program all your life and not even scratch the surface of it all. That's why I think edw's advice is totally perfect. Learning by finding out how to get a task done is the way to go because you could learn all sorts of programming related stuff all day that you never use. In tennis you're far more likely to get an opportunity to use all you've learned.
Nice try with the tennis, it's a good argument but it doesn't work out in the end.