In Defense of Managers

I know it’s not fashionable to look at things from the enemy’s perspective, but has it ever occurred to you folks that the reason there are so few good managers is that managing people is hard? Let’s try looking at this from a couple of different perspectives.

  • Look around you, right here on slashdot. Pick a half-dozen messages from this very thread. Would you want to manage a group consisting of the people who wrote those messages? Well, I know I sure as hell wouldn’t. “Herding cats” doesn’t tell half of it. Most cats are at least a little bit predictable, sleep a lot, occasionally show affection or at least look cute, etc. Maybe herding really smelly ill-tempered cats who miss the litterbox regularly and have a tendency to use your legs as scratching posts at every opportunity is getting close.
  • Managers get to spend a lot of time cooped up in small windowless rooms all day with other managers. Sounds like a working definition of hell to me. It’s like No Exit. Every organization has people who will try to screw you and who are good at it. Even if such people are only 10% of the managers, that’s enough to keep the other 90% going to the meetings and making sure they and their people don’t get totally worked over.
  • Most managers get next to no training. Trying to keep a non-trivial project, particularly one that involves new technology, on track takes some doing. Trying to juggle the desire of everyone in the group to go off and do the Next Cool Thing while you still have products to ship is tricky. Dealing with the conflicts between the two would-be Top Guns in your group, or between the Process Weenie and the Cowboy, or between the NT bigots and the UNIX zealots, could drive anyone insane. And then someone comes along with a patent issue or a sexual harassment lawsuit and your goose is truly cooked.

Where are you going to find good people to do all this? Where do you find someone who can keep both the technical details and the corporate goals in mind, who’s reasonably intelligent and has a decent set of ethics and yet doesn’t mind sitting in rooms full of Machiavelli wannabes and Just Plain Dumb people, and who’s willing – all to often – to do all that for less money than some of the people “under” them get paid? There really is a shortage of quality people in the industry, but it’s not a shortage of hands-on techies; it’s a shortage of managers who aren’t scum or morons or both.

I whine about my job as much as anyone, but I honestly don’t think there’s anything I could find myself doing in my prized role as an individual contributor that would be worse than being a manager. It is necessary to have someone else to do all that stuff, but I’m damn glad it’s not me. Next time you feel like a few minutes of manager-bashing, spare yourself at least one second to give thanks that you have a better job than they do.

ICC and Cheating

chessplayer <> wrote in message news:hXmA5.1102$…
> Each time as soon as the game ended
> the message was that ICC had found computeruse. And there was no way to
> verify that without somehow hacking my harddisk

Not necessarily your hard disk; memory will do. As others have pointed out, BlitzIn does send information about running processes to ICC, which is how you were caught. Of course, there are several objections to this:

(1) Some consider it an invasion of privacy.

(2) It doesn’t really solve the problem. Someone who uses a program on a different computer, or uses a program that BlitzIn doesn’t know about, or hacks a program that BlitzIn does know about, or uses a utility to mess with the process table, won’t get caught this way. Some might even argue that ICC’s approach to this is discriminatory, since people rich enough to have a second computer handy or technically savvy enough to use one of the other tricks can still cheat while Joe User with one computer can’t.

(3) Pushing a single client supported on a single OS platform deprives users of choice with regard to both interface and OS.

As I’ve pointed out before in this group, I believe that ICC’s attempt to address this problem via BlitzIn is terribly misguided. Their policy of not discussing the issue is also misguided; it’s well known in the rest of the computer industry that “security through obscurity” is a poor design choice. If they were really serious about cheating, they’d bite the bullet and devote more resources to catching cheaters the old-fashioned way – by looking for well-known patterns in moves and move timings and sudden ratings increases. Of course, that would require lots more human time and/or more computing resources (more $$$) to separate the wheat from the chaff and reduce the number of games the humans must examine. I believe that ICC’s failure to do all this, and their insistence on the broken BlitzIn-based solution instead, shows that they’re much more interested in _appearing_ to do something than in actually doing something about cheating.

ICC is a for-profit enterprise; where’s the profit for them? Cheaters are customers too. If they can avoid alienating the cheaters, and also make enough of a show to avoid alienating others concerned about cheating, that’s a win/win for them.

Python vs. Perl

Riddle me this: does Python have lexical scope, closures, useful built-in data-types, familiar syntax, functions, variables, looping constructs, or objects?

Before I get started, I invite a Perl advocate to answer the same set of questions for Perl so we can all compare. Any volunteers?

OK, here goes:

  • Lexical scope: kinda, sorta. Truth be told, Python scope is neither truly lexical nor truly dynamic. It is, however, well documented and easy to understand; see this post and the pointers therein for a better explanation. Short form: the language generally tends more toward lexical than dynamic, and is certainly evolving even further in that direction
  • Closures: not as such, but there’s a very standard trick involving lambda default arguments that gives the same effect without requiring an extension to the language.
  • Useful built-in data types: damn right! Lists, dictionaries, objects, you name it.
  • Functions, variables, looping constructs: yes, yes, and yes. Also a nice exception system.
  • Objects: absolutely. A well-designed set of interactions between objects, dictionaries and namespaces is at the very core of Python. OO is not just something bolted on to Python after the fact; it has been there since day one, and it’s almost impossible to write any non-trivial program without using objects.

Before we go on, I’d also like to touch on two things about Python that you didn’t even ask about but that help make it even cooler.

  • Python maintains a good separation between language and environment. A lot of stuff that clutters up A Certain Other Language is in libraries with Python, often using much nicer object-based interfaces. This makes things much more portable, extensible, etc.
  • The ability to extend Python with modules written in C, using a well-documented API, should not be underestimated. This aspect of the language is, again, not an afterthought. As with Tcl, extensibility and embeddability (something with which I personally have less experience) were design goals from Day One. Time-machine references aside, this is what happens when you design stuff well to start with. Extensions have been written that I’m sure Guido van Rossum could never have imagined when he was designing Python, but because he followed good design processes they were easy to create.

Next question:

How does it help you manage a program better than, say, Perl?

I have to admit that it’s hard for me to put some of this into words, because it has to do with general philosophy rather than specific features. A lot of what’s in Python is there specifically to improve clarity, reduce possibility for error, etc. Sometimes Guido has arguably gone too far, such as with the indentation thing or long-standing (but finally overcome) opposition to augmented assignment, but it’s hard to fault him for that. He knows what he’s doing, and so do the other decision-makers. Despite quibbles from Perl or Scheme folks who are surprised by anything not Perl or Scheme, Python generally follows the “principle of least surprise” rather well.

The fact that objects are central and not just peripheral to Python is one example of something that has far-reaching but hard to define consequences. The fact that it has had mature module and exception features from the start is similarly helpful, especially in larger programs. Object-persistence stuff like pickle and shelve (yeah, weird names), rudimentary as they may seem, have also proven invaluable to many people. One might say that Perl has caught up in many of these areas, though I personally think it still has a way to go, but catching up is still not the same as doing it right the first time. Legacy code written “before we had X” is a pain.

What does it *not* let you do that you might conceivably want to do, and how ugly are the methods used to get around this?

Damn little. A lot of people have done a lot of very fancy things with Python. There’s very little you can’t do even if you only use the language in the most straightforward way. If that doesn’t work, you can step into meta-object programming and namespace manipulation, which are a little bit tricky but still not “black magic”. If that doesn’t work you can write an extension module, which again is about as painless as one could reasonably expect it to be. Overall, whatever level you have to go to, it’s about as non-ugly as one could hope for. The only time I had to do something really ugly in a Python program was when I had to deal with some issues about default parameters being evaluated at function-definition rather than function-call time.

In a post of this length, I would of course be remiss if I didn’t mention some of the things that I think are wrong with Python. Bear in mind, though, that I’m loth to gainsay the language developers’ decisions even when I might have done it differently myself. They have done a better job than I would have.

  • I live with the indentation thing, but I’m among those who would be at least half an iota happier if Python used braces.
  • The fact that certain built-in types are not true objects is suboptimal (this is improving).
  • Not being able to subclass extension-module objects sucks. You can get around it by creating a Python class to wrap the C class, but that is kind of kludgy. In general, some of the internal relationships between objects, classes, and namespaces could be improved.
  • Some nitpicky details about lists/tuples/slices have never felt right to me. This is definitely a matter of personal taste; most people would probably hate the way I’d do it.
  • Some of the newer package stuff seems a little baroque to me, but it’s still evolving, so who knows?