Garbled

In light of my last post, I got to thinking some more about old school hackers. Also, at my job, we’ve got some people who’ve been here a long time. One in particular, we’ll call him Steve, is very smart, but… And, see, that’s sort of the thing: I can’t put my finger on it exactly. Steve is blazingly smart. But there’s clearly a difference between he and I that isn’t, I think, just accounted for by the 20 or so (I’m guessing) year difference in our ages.

If I see something I dislike—something that could be better—I really want to see it change. I want to be involved in that change if not driving it. Steve is often watching and present. He’s paying attention mostly and if you ask him a question he’ll have an insightful answer. If someone proposes a change that’s actually a good one and addresses a real problem, etc. etc. he’ll be glad the change is coming. But he never pushes for it. He never starts a conversation (in the wider sense, I mean; he will say hi to you in the hall or whatever) and hardly chimes in unless addressed directly.

And I think Steve fits a sort of archetype. He’s very interested in low-level details (well, actually in almost any kind of technical detail). He seems to be pretty much interested in being left alone and tinkering in his shop to see how things work (to use a light metaphor, here). If something is bad or less than optimal for other programmers around him (and including him), he’ll either ignore it or work around it on his own. His solution wont be general enough to apply to everyone, though and he wouldn’t publicize it. He’s very internally focused. And I associate this stereotype with older programmers or, more accurately, with old school programmers (how long have you been coding, not how long have you been alive).

On the other hand, I think think there’s a newer breed of programmer that’s becoming or has become very common. And I want to be very specific, here: I’m talking about hackers; folks who code because they enjoy it, not those who do it because its their job. People who would code to solve computer-related problems they have at home even if they were a news anchor or a trail guide. This new breed is more externally focused. We want our solutions to problems to be useful to other people. We want to have a conversation and (often) change the way things are done (for what we see as the better). We want powerful abstractions and like to live up away from the metal, generally.

I haven’t cataloged all the differences and, in particular, I’m having a hard time figuring out the attributes for my “new breed” of hacker are. Of course I’m talking about generalizations and stereotypes, here, but I don’t think that’s intrinsically bad. Basically, I get a sense of a certain amount of cohesion in personality type and behavior in these two groups and it struck me as interesting. What do you think, am I drawing a distinction where there is none? Is this distinction useful for anything? Is there some interesting point I’ve missed?

You frequently hear (or I do, anyway) the advice that if you’re unhappy in your coding job, you should scratch your own itch, work on what you love… Work on something you’d be a user for. Because then you don’t have to do a bunch of requirements gathering and get them inevitably wrong, etc. etc. The idea seems to be that if you love the business process, you’ll love working on the code that enacts it. And, well, that’s fine. It seems to make a lot of sense, on the surface. But then I thought about history.

As programmers, we don’t have a lot of it (compare auto workers or, say, masons). History, I mean. But there’s some and in the days of Mel and COBOL Cowboys, things were different from what they are now. Today we have all these powerful abstractions and high level languages. Folks (well, not all, but many) consider it to be ideal if you’re basically writing your code in a DSL specific to your business process. Which means your code is really tightly coupled to your business (on that layer, anyway). I don’t know that that’s a bad thing at all (in case I sounded critical). I just want to contrast it to what came before.

Those dudes were almost just writing ones and zeros. They were so far removed from the business processes they were enacting and the folks who were using their stuff that I wonder how much impact it had on them. Would Mel have been any more or less happy writing financial management apps for large companies than solitaire? I kind of think it wouldn’t have mattered to him; he was in it for the code and playing with numbers. He enjoyed all that low-level stuff.

So I wonder, is our (figurative us, here) unhappiness when dealing with business processes we aren’t personally invested in a symptom of all of our awesome high level languages and nice abstractions?