Something that occurred to me yesterday is how much less structured my work week is than it used to be.
When I was a new developer, my TL (team lead) liked to have everyone maintain a spreadsheet showing everything that we were currently working on, with an estimate of how many hours we were planning to put into each item for the coming week. I was never convinced of the ability of the average developer (or, more specifically, of myself) to accurately estimate how long things would take, but it at least showed how much time would be taken up by meetings, vacation, etc, and how much work everyone had on their plate.
Over time, I stopped doing the spreadsheet, and my workplan meetings largely became me saying “I’m currently working on this, this, and this” and my TL saying “ok, sounds good” or “I need you to prioritize this other thing.” This worked for me – I still had a good idea of what I was going to be working on, but I wasn’t spending time typing up estimates of how long each change would take.
These days, that’s still how my workplan meetings go, but two things have changed. One is that I now bring written notes, because even though I don’t feel the need to do the formal plans we used to use, I have too many things going on to remember everything I want to talk about without them. The other is that my plans for the week are much more open-ended: rather than having six fixes I plan to do, I’ll have two or three things at the top of my priority list and other stuff hanging around for “when I get to it.”
Largely, this is because I’ve taken on more responsibility: a lot of my time goes to either dealing with important issues that come in and get routed to me that I wouldn’t know about in advance, or helping newer members of the team. As a result, it’s not unusual that only a minority of my time is actually devoted to what I’d planned to spend the week working on. The other reason is just that I tend to work on larger projects now, which take several weeks or longer to complete, with smaller development thrown in when I need a break; this means it’s rare that I have a half-dozen fixes on my “will absolutely do this week” list.
At the same time, while I’m not directly responsible for any other people on the team, I am in charge of a project that several people are working on, which means I’m setting priorities and making decisions for multiple developers. My impulse so far has pretty much been to pretty much say “here are the team standards and the company standards; I expect you to follow these. Otherwise, work how you like and let me know when you need more.” If I can agree on a design with one of my developers and then not hear from him again until he’s finished coding three weeks later, I’m fine with that; I have no interest in knowing how many hours he’s spending on a given part of his activity each week.
My own feeling is that if you give someone work to do and let them figure out how to get it done (assuming that person is reasonably competent and professional), with the occasional check-in, work will get done more effectively and people will be happier than if you try to micro-manage what’s being done when. At least, that’s always been my experience – if I have multiple things I need to get done, I’ll be more productive if I can just choose to work on whichever item I happen to most feel like working on at the time, not what the schedule says I should be doing. The nice thing about being a software developer is that this is quite possible; as long as I’m hitting my deadlines, how I’m managing my time doesn’t need to concern anyone else.
But it’s still a good thing the computer keeps track of everything I need to do without my having to do anything. My memory isn’t that good…