Strategically ignoring things... on learning

scrottie on 2009-10-13T19:46:10

The Perl camp, under Larry's guidance, embraces "baby talk", where someone learns just enough of the language to serve their purposes. Yet there's a large stigma against this sort of shallow knowledge among the ranks of #perl. The bulk of people who come to Perl Mongers meets or ask for help on the Internet wind up trapped between these ideals as they find themselves caught in the middle of this old debate. The "Little Bobby Tables" meme strikes squarely for one side of the debate; the success of PHP for the other.

I haven't blogged much this past month. Indeed I haven't done much. I've been busy learning git, DBIx::Class, being not fresh on jQuery and Apache, ...

My instincts were squarely against learning more Perl related technologies, instead wanting to continue to focus on ActionScript and Flash, where the grass looked greener, but once I got into it, I realized that I'd be unhappy with myself if I didn't stay current with Perl. I learned Java early on and then neglected it to the point where I could no longer claim it and trying to catch up with the past years would be painful. The same thing happened to me with JavaScript. It's the old story of being put into suspended animation and waking up to a strange but strangely familiar world you don't fit into and enticements to conceptualize or relate to it are dangerously misleading. But on the other hand, maybe Perl should just sit and spin... I've said a lot of mean things about it and meant most of them.

Deciding to learn ActionScript, I immediately ordered a pile of books. Then I checked out some from the library. Then I ordered a pile more. And I read most of them.

This is exactly what the kids are _not_ doing. And I think they know something I don't. Today my suspicion that I'm being slow was confirmed for me.

I know and have known some older programmers who worked their entire life on the same codebase. The number I've touched... eek. Many. Hurts to think about. My resume has an incredible breadth of skills. Almost all of them are rusty. I seldom have the luxury of using the same skill twice. Apple wanted to talk to me about my ARM accelerated 3D experience. All I could think was, crud, I do not want to have to work under the gun for Apple and learn my way around their massive codebases. Gadzooks!

The problem with learning how to do things is that you learn how to do them wrong. Like the famous quote about BASIC and the stigma Java shops have against hiring "reformed" Perl programmers (and Ruby shops have now developed about Perl programmers even though they used to proudly boast Perl as an influence), I would not want to have a software shop and hire COBOL programmers. There's a stigma against old programmers. I am now an old programmer. The novices on IRC are in a better position to tackle today's problems than I am. They only have to learn. I have to unlearn. "What's the command?"... "Do it for me?" is a better match for companies who want programmers to hit the ground running. In Programming is Dreaming terms, we're all in shallow sleeps. There's less learning technologies and more learning how to co-exist with them. "Sometimes a few hours of guessing can save tedious minutes of reading the documentation" is less true with codebases optimized for obviousness and accessibility and single point of modification but such codebases are less geared towards learning all of the interconnections and locations of the single points.

It was my intention to put my attitude aside and learn something for once but, as usual, what I'm learning isn't quite what I expected. In fact that attitude itself was off. A "where's X, dammit!?" attitude would have served better. Another advantage of youth -- being wrong hasn't gotten old yet. Being wrong does eventually get old. It wears on you after a while. More and more, I can understand the programmers who don't want to re-tool from COBOL.

-scott