I keep telling myself I’d like to try a stint of project management. Preferably something safe, like the mini-software-project I’ll tackle at some point in my undergrad studies.
I was recently asked whether or not I’d be a good manager. I replied that I’d like to think so, because I have strong opinions on what makes a good manager. Of course, even if my opinions were based on something other than whatever feels good to me, that alone wouldn’t qualify me as one.
One aspect of project management is scoping things so that you can reasonably expect to finish the items in the scope, with the resources you have and within the expected time span. If succeeding there is a feature of a good project manager (and yes, it is), then I’m sorely lacking. See, after my vacation, I took two uni courses, both of which were programming labs. Having a fair bit of programming experience under my belt, I figured it’d be easy as pie. Six weeks is plenty of time. I went as far as tackling the other one, the Data Structures Lab, in C. I’ve never written a line of C before, bar the usual print(“hello world!\n”);
Of course, I can afford to make mistakes in lab projects. However, it’s somewhat disheartening to notice, that after eight years of
professional programming for a living, I still suck at estimating both the amount of effort something will take, and the amount of actual programming time I can devote to something. And mainly because of arrogance.
“I love deadlines. I like the whooshing sound they make as they fly by.” --Douglas Adams
In fact, what makes this even worse, is that I made this exact same mistake back in early 2008 when I worked on my Java lab. I had six weeks, and I failed to consider that it’s six weeks of evenings and weekends. And now, just like then, I was insanely tired when I reached the finish line, and I didn’t have the energy to put the polish I would have wanted to the labs.
Incidentally, that’s one reason why I haven’t blogged for a while. I felt somewhat burned out after all that, and decided that my RSI-ridden hands needed a rest as much as my stressed-out brain did.
Another mistake I’ve repeated is falling into the pattern of whining instead of changing things. I’ve been thinking about it for a while now, and I’m going to try something new: effecting change. I’ve tried to change things before, in a previous job, but mainly by either dictating things or arguing for or against things. In retrospect, it’s no wonder it didn’t work. I must have seemed like a total asshole.
This time, I’ll try a different approach.
I’ve identified a problem that I feel needs to be dealt with: too long feedback loops. We write code, and we get comments after a period that may turn out to be months long. At some point, the value of the feedback is less than the cost of the changes the feedback implies, because we’ve built other things on top the things we built before, and it becomes a lot like trying to change a bottom card in a house of cards.
To combat this, I’ve recruited a co-worker to help review code. My code, that is. I’m hoping in turn he’ll feel comfortable letting me review his code. And if this works out, we will see if we can get others to take part, and switch reviewer-reviewee-pairs often. The important bit is to keep it informal, keep the iterations short and make everyone feel it’s peer review, not review by superiors. That way, I’m hoping the feedback loop stays short, and the usefulness of the feedback is maximized.
Reviewing is also a great way to cross-pollinate knowledge and good ideas. I really hope this works out.