He lost me immediately with the first box entry for Managers. In my experience there's been a stronger correlation with morality and contribution in hackers than in managers. And note he is using the definition of hackers as "programmers" not as "breaks into systems". If he used the latter, I could agree with his generalization. But in this case it seems backward.
I think it's worth reading further. He points out managers' preoccupation with morality, then says: "Measures own contribution to society by the extent to which he adds to rules and sees that people live by following rules. Tends to equate rules with morality or the good of society."
This is the morality of someone who wants to create the rules which others live by. When I think back to how managers react when someone ignores their rules, a lot of it could have been moral indignation. As if you rejected society's rules. (Which is kind of true, as they're among society's rulemakers.)
On the other hand, the hacker "Does not equate rules with morality or the good of society." A different moral view.
He's not talking about either an ordinary programmer or a cracker but the Mythical Genius Hacker(tm): Yes, I am serious; a hacker on a roll may be able to produce, in a period of a few months, something that a small development group (say, 7-8 people) would have a hard time getting together over a year. Whether claims of programmer productivity variation are true or not, I'm dubious that the most productive programmer necessarily goes by the title "Hacker" or necessarily operates in the "mad genius" fashion.
As a software engineer, I'd encourage managers to avoid the "hacker" who is more productive because only he understands the poorly designed system he created. The genius hacker myth is counter-productive here.
We had a "Genius Hacker(tm)" where I currently work. He got projects done quick and they stayed working for a long time. He left and we needed to extend some projects or something would break on another. Everyone agreed, it was some of the most horrible code any of us had ever seen. Also, over-engineering is an understatement. He still plagues us years later as we find his legacy floating around.
I think sometime poor design or horrible code is quite subjective. For example, when I write complex query for performance critical system, and no other colleagues understand, is that my fault?
I'm talking about metaclasses in Python for the hell of it. I'm talking one-liners that consist of map, lambda, map, lambda, filter, map, map, map, join. I'm talking about inconsistent indenting and one letter variable names everywhere. I'm talking about huge monolithic code bases, all of which he wrote, containing code copy and pasted from each other instead of making a library. I could go on but I'll spare you. I agree that "poor design" and "horrible code" is quite subjective but sometimes it's an easier call than others.
Not if you wrote clear supporting documentation appropriate for an audience that will not be familiar with your particular conceptualization. This in itself is a real art.
