Chad Perrin: SOB

30 April 2008

recursion confessional

Filed under: Geek,Profession — Tags: , , — apotheon @ 11:45

I have taken a couple of college classes in programming. I remember conversations after class with the instructor from my Programming 101 (not sure that's what it was actually called) course, where we strayed from C/C++ (the implementation language(s) for the class) to matters related to Cobol and Perl, among other things. I remember being frustrated by the fact that while taking a class in JavaScript, I discovered that I learned programming more slowly in a formal education environment than on my own.

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:

  1. looping (e.g. "Write a loop that counts from 1 to 10.")

  2. doing basic arithmetic in your head (e.g. "What's the number after F in hexadecimal?")

  3. practical recursion (e.g. "Use recursion to solve a real problem.")

The reason this got me thinking about my (lack of) "formal" education in programming is point three — practical recursion. See, I've never really had to use recursion in the real world, and it sure didn't come up in introductory courses in C, C++, and JavaScript. The obvious use-case for recursion is parsing arbitrary depth hierarchical trees, such as directory structures — but the vast majority of my "real world" work has been in Perl, PHP, and Ruby, all of which make implementing the actual tree-parsing algorithm an exceedingly rare necessity for common cases. In such languages, the recursion is done for you. Ruby compounds the "problem" by providing such excellent iterators that even in the rare case, you can put together an easier, more elegant-looking solution with an iterator block than with recursion anyway (and punishes deep recursion by failing at tail-call optimization, too, at least as recently as version 1.8).

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:

  1. 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.

  2. 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.

All original content Copyright Chad Perrin: Distributed under the terms of the Open Works License