Otherwise, my programming learning has basically all been self-taught. As a result of this, I tend to learn the stuff for which I have a real use, and that's about it. Oh, sure, I "learn" some stuff for purposes of wanting to know how things work as an academic exercise, out of curiosity and fascination, but if I don't have real-world applications for what I'm "learning" I don't really learn it in a way that makes it ultimately useful when the real-world application of the concept does rear its head. It's only then that I actually learn it in a practical, applicable manner.
I got to thinking about this in part because I reread Dan Kegel's How To Get Hired — What CS Students Need to Know. In it, he identifies three basic programming skills that many programming job applicants (surprisingly) lack:
looping (e.g. "Write a loop that counts from 1 to 10.")
doing basic arithmetic in your head (e.g. "What's the number after F in hexadecimal?")
practical recursion (e.g. "Use recursion to solve a real problem.")
Of course, the first time I had a real-world problem to solve where recursion was the obvious best choice, I'd surely learn it sufficiently to solve that little deficiency in my skillset, but this still offers two problems:
Being unfamiliar with recursion outside of gratuitous examples like Fibonacci sequence generators, I may well not notice when a recursive solution is marginally better than the iterative solution I'm using instead. It would take a really obvious (to me) need for recursion for me to notice I needed it, I suspect.
The ability to learn concepts quickly and apply them well while learning them doesn't prepare me for the circumstance posited in Dan Kegel's essay: job interviews. In other words, he probably wouldn't hire me.
Every once in a while, I find myself kicking around the idea of getting hired on at a "normal" programming job. One of the things that holds me back (aside from all the other things, like my enjoyment of rolling out of bed at 10:30 instead of jumping up at 6 AM, choosing the projects I work on rather than toeing a corporate line, et cetera) is the fact that any place I'd want to work, in an environment with smart programmers doing interesting things, I'd probably lack some of the "signifier" skills interviewers would expect of me. The very best places would be those where someone would think to ask "Why don't you know how to do this?" rather than just chalking up my ignorance to incompetence — thus perhaps allowing me the chance to get in anyway — but that's such a rare case that I'm unlikely to find a hiring dev shop like that anyway. It's difficult enough finding a place that doesn't have arbitrary, pointless requirements like "must have Master's degree" for "entry-level programmer" jobs.
I'm probably a prime example of what people who value certain levels of "higher education" in "computer science" (note that the quotes around CompSci are meant to denigrate the quality of most CS degree programs, not the concept of CS itself) like to use as examples of how right they are to ignore matters like intelligence, passion, adaptability, integrity, and other actually useful characteristics, preferring sheepskin as the Metric Most High for a new hire. This isn't because I'd be bad at the job, even if it required constant use of advanced recursive techniques. It might take me a month to spool up to the same speed on recursion as everyone else there, sure — but the initial investment would be worth getting me rather than someone with a Master's in CompSci who's dumb, plodding, rigid, and prone to doing everything for CYA value rather than the success of the project.
None of that changes the fact that, without the standard CS degree program course of study, I'm at a distinct disadvantage for certain types of interview skills-test questions.
At least I know that the next number after F is ten, though.