Colin R. MacDonald has written a good essay about the challenges of giving a task to a junior engineer. As a manager or project lead, I’ve run into pretty much every situation he describes. When it happens on a software project, it can be very frustrating. As Colin describes it with a picture hanging project, it’s quite amusing:
“Why can’t we get a nail gun?”
“We don’t have the budget for it.”
“So we can’t afford to do things right?”
“There’s nothing wrong with driving nails with a hammer.”
“But aren’t we trying to do things better and faster? Are we going to keep using hammers just because we’ve always used them? It’ll pay off in the long run.”
“We don’t spend enough time driving nails around here to justify buying a nail gun. We just don’t.”
Every day I need to make decisions about how much time to spend talking about or writing down the details of a task. You don’t want someone to feel micro-managed, but you don’t want to leave them clueless. Sometimes there’s a surprisingly small difference between the two.
At the moment, I’m leading a team and also writing code for the project, so there’s additional balance between how much time I spend giving direction and how much time I spend on my own work. Its more of an art, than it is a science. I know the project will benefit if I write up checkin guidelines and best practices and write down all that info about the project that is floating around my head, but the project will also benefit from the code I would write in the same amount of time. The larger the team is the more benefit there is for written documents. I find that our culture of frequent code reviews provides a good time for reflection on whether I’ve got the balance right. Live feedback can be fun and low overhead, but if I find myself saying the same things over and over, its time to write them down. Also, no one wants to hear in a code review something that they needed to hear before they started to type.
ok, ok, I’ll go write that best practices document…