Breadth, not depth
I'm taking my niece Katie around the area to look at colleges this week. I did the same drill for her older sister Sarah last year and it has been a blast for me on each trip. One of the things I've been doing is sneaking off to the bookstore at each college to see what textbooks they're using in their Computer Science curriculum. Some places have piles of interesting books. McGill University in Montreal had an AI book I'd not seen before. I waited until returning to the States to snag that. Other colleges, though, had books stacked up that looked old and tired. I'm not saying the subjects were old and tired, mind you, just the selected text books.
I've had a couple of reasons lately to be interested in such things. First, as a hiring manager for some of my career, I'm always interested in what they're teaching the college kids. After all, their new graduates are potentially my new hires. I'm not a hiring manager any more (thank goodness!) but we did do a round of interviews recently and I must say that a couple of candidates left me scratching my head.
Now I'm not going to go into one of those back when I was in school things because there were a number of numbskulls in my classes, too. No, what worries me about the last couple of candidates, and the books I see on some of these bookstore shelves, is a lack of breadth. That's right, not a lack of depth, a lack of breadth.
Interviewing candidates is a tricky proposition. You need to learn a great deal about the talent, character, potential, and versatility of an engineer in a very short amount of time. I have two general ways that I approach an interview: I either talk to them about software engineering principals like CM, testing, design, integration, documentation, reviews, etc. and see if they've got a general idea of how things should work. Or, I see if they've done some large project recently and quiz them on what they'd done, what choices they'd made, what they would do differently, why that would have made a difference, and so on.
The last few candidates had recently done large projects so it was easy to pursue that route. You'd think that would be exciting and low-pressure for a candidate: just talk about stuff they've been working on 20 hours a week for the last 3 or 6 months. Nope. What I found was, and this was shocking to me, as soon as I went outside the scope a bit and started challenging assumptions or asking about the underlying infrastructure or technology, they were stumped. I mean dead in the water.
What in the world is going on?! Have we become so specialized even at the college level that we can't speak intelligently or have a reasonable intuition for things that border our comfort zone? Now, some of the questions I'd asked were, in my mind, pretty easy. They should have been a slam dunk on an interview. Obviously I'm writing this because that's now how it worked out.
I'm also posting this on Java.net so, obviously, you'd hope that there was a Java tie-in. Yes, there is. But, it might not be the one you're expecting. I'm going to make the assertion that Java, my very favorite language, cannot be allowed to be the only language or programming platform that young programmers learn. (And, no, I don't count Perl, Python, Tcl, or other scripting systems as languages in this context. They each have their merits--except Tcl--but that's not the point here.)
I was fortunate enough to become a computer science student when microprocessors were really gaining a foothold. I learned assembly language programming on a big IBM machine, and then again for a microprocessor-based system. I actually built (wire-wrapped) a microcomputer of my own design for a senior project, something that required both hardware and software skills. I learned C and other medium level languages. And, I now live in the age of Java. I was around for the whole progression.
What I have, and what those candidates did not have, can be neatly summed up in just two items:
- an intuition for what the machine is doing from the bits up, and
- a curiosity to learn about stuff outside the particular boundaries I'm working within right now.
We've lost that somehow. And, I can't help but believe we'd have better programmers, better Java programmers, if we had young engineering students with a little more breadth in the background. Training on the latest web-serving-gizmo will fade in usefulness very quickly. A driving curiosity and deep intuition about what's going on in the machine will serve them for their whole career.
Again, I'm not saying that young engineers have to do it the way I happened to have done it. Further, I hope they don't have to do it the way I did it! But, there's something missing in this age of speciality. Call me old fashioned, but there are times when I just want to hire a bright, motivated, and intuitive generalist. I'm worried they're a dying breed.