One of the tricky bits about being a lead is finding the time to keep writing code yourself – with the transition to managing people, your world changes a lot. That’s true even if you’re in an organizational structure expressly set up to allow development leads plenty of time to write code – you’re responsible for more “stuff”, and the time you spend on the not-writing-code work items is generally quadratic in terms of number of items, not linear. This is problematic because it’s very easy to get divorced from the reality of the source code trenches if you’re not checking in, or reading and having to modify other people’s code, on a regular basis. Such a lack of full context, in turn, makes it harder to do your job well, because you don’t really know how that feature works, or what the current health of the codebase is, or how your bits are going to get deployed etc. And then you run the danger of making a decision with long-term ramifications based on incomplete or incorrect information, and it comes back to bite you in the posterior 5 months later, when you’ve lost all context about why you made that decision. Or you start making statements that so obviously highlight that you’re out of touch that people start to flip the “pointy-haired clueless manager” bit on you.
Ok, so you try to keep writing code. But what sort of stuff should you really sign up for ? You shouldn’t promise to deliver a complex feature that lots of other features depend on because you don’t really have the time to implement it properly, with a clean design, high performance, unit tests, stress tests etc. And then you’ll deliver something half-baked and other people will have to fix your mess, and that’s not going to do anything for your reputation as a good engineer. And it’s not so great for your performance review either …
[Note: I’m assuming here, for the sake of discussion, that you choose to work sane hours. You can always find time to keep writing lots of code if you’re willing to spend lots of time at night doing so …]
Well, gentle reader, I believe I have part of the answer, at least if you’re working on something Internet service-y: sign up to write the live-site troubleshooting, “Is it healthy ?”-type monitoring and usage analysis tools for your service.
Work of that nature has several features that make it a good fit. First, having to write tests that check whether a service is working will force you to understand what the thing you’re testing is supposed to do [giving you a better understanding of the features that your team of programming elves has been busy cranking out], and will also give you direct insight into how well it actually is working, which serves as good way to check whether your team is checking in solid code or not. Second, it’s work that nobody usually wants to do, so there’s not a whole lot of contention – monitoring tools aren’t nearly as sexy as user-visible features. Also, these sorts of tools [generally] don’t have to be ready at the same time as the product, so there’s less schedule pressure to get them done. This lack of schedule pressure fits in nicely with the fact that, as a lead, the best you can generally do in terms of estimating how long it’ll take you to finish a given piece of code is to provide the calendar year in which you think you’ll finish. And, last but not least, doing logfile analysis helps you see how your service is being used, which is useful context to have when you’re deciding what features to add, how to modify existing features, which features to de-emphasize etc, and will help you drive product direction.
I can’t claim to have thought up this scheme all by myself. Rather, I happened to do this sort of work on a couple of projects, and it worked out well both times, which made me realize that I might have stumbled onto a pattern worth thinking about a bit more to see whether it could be generalized. I believe it can, so that’s my plan, and I’m sticking to it.
