malvasia bianca

I’m in the mood to blog about managing, so I thought I should add a “Managing” category. But how to fit it into the hierarchy? I manage programmers, and I expect most or all of my managing posts to be about programming as well. But programming is already the only subcategory I have; to add a subsubcategory to it would be a bit ridiculous. Maybe I’ll just get rid of subcategories entirely, actually: have Programming be a top-level category, and reserve Computers for non-programming computer topics. (Which is tangential to the issue at hand: the Managing posts would still probably be a subset of the Programming posts, even if the relationship isn’t formalized in a hierarchy.)

Of course, I may start writing at some point about aspects of managing that don’t directly involve programming. I think that part of the issue here is my own ambiguous feelings on the matter: my group has all of five people (including myself), one of whom is currently on leave, so managing is hardly a full-time job (especially since they’re delightfully easy to work with). As a result, I spend around half or two-thirds of my time programming, and all of my managing thoughts are inevitably tainted thereby.

Which is the way I like it. Don’t get me wrong: managing is quite interesting, I’m learning a lot by doing it, and it gives me lots of things to think about. But at the time I started managing, I’d only been working as a professional programmer for a year; it’s been basically another year since then, but I still have a lot to learn about programming, and I don’t want to give that up. My official position is a “Staff Engineer” at Sun, which is on the technical track, not the managing track, and that was an intentional choice: I expect that, in my next job, I’ll look for a programming job.

The nice thing about managing while working as a programmer, though, is that it gives me quite a bit more control over my programming environment than I would otherwise have. I’m starting to get very strong hypotheses about how I think code is best produced, and how I think I would most enjoy producing code (the answers to both being the same); I would, frankly, rather not spend time in an environment that I feel is hindering my programming. And if I have to give away half of my time to managing in order to get that environment, that’s a reasonable trade-off.

I’ll definitely have my eyes open to management issues during my next job search. Which, fortunately, is not at all imminent: I quite enjoy my current job, and it’s getting more interesting rather than less interesting. If you’d asked me a few years ago, I probably would have speculated that I’d prefer greenfield development to what we’re doing now, getting code ready for production while adding a few features that we left out. And I’m sure I would enjoy greenfield development; but there’s something quite refreshing about working with actual, flawed code, being forced to confront its liabilities, and deciding what to do about them (while, of course, preserving the strengths of the code). I suspect that, when doing greenfield development, it’s easier to pretend that you’re writing good code, while the truth may be that your code just hasn’t been put to the test in enough ways. (Both in terms of extensive testing and in terms of successfully supporting further development.) So a bit of extra concreteness is nice.

Which is, in a funny way, where this post started: just as I like being confronted with concrete programming choices, the reason why I can’t separate managing and programming is because I can’t get away from the concrete managing choices that I have to make, and programming is always close enough to the surface in those choices that it inevitably bubbles up in any thoughts I have on the subject.