Ok, so I've just joined a game development group at my university, and somehow, I've gotten the position of Lead Programmer because I know the most (other than the technical director and project manager) about DirectX and general engine programming. So what does the job of lead programmer entail? What am I supposed to do? I've never really worked on a project with a team of more than 3. And that team of 3 was an engine programmer (me), general programmer, and an artist. So I'm really lacking in knowing what I'm supposed to be doing. Would anyone with this sort of experience tell me what my job is?

One of the first issues should be getting to know your team and particularly their skills and interests. You represent your team and you need to know the people you represent. You want to present to the project leader the capabilities of your team. The project leader generally is not technical, but rather administrative. They are not in a position to assess the technical abilities of your team. A good project leader has a project plan. Tasks require resources to complete and resources are not unlimited. One resource is people and specifically their time. They have to assign individuals to tasks to get an estimated completion date that means anything. So they need to information about capabilities of individuals to make reasonable assignments.

Now it isn't just what the people can do, but what does the task require as well. Again the project leader isn't really in a position to make that technical assessment. So you have to assist them in that. That often means you need to be at meetings to provide input while decisions are being made. Part of that input should be in how long a task should take. That is standard time, not based upon the individual you expect it to be assigned to. Basically how long should it take someone with the skill to perform this task. If you set the time requirements on a task based upon the individual then on paper the fast guy looks the same as the slow guy. If you use a standard time then the fast guy is getting things done in less than the time allotted and the slow guy is taking longer than the time allotted.

When it comes to actually doing a task you should be supervising. You don't just give them a task and hope they someday reappear with it completed. You check the progress and status of it. If things are not progressing well then you may need to coach the individual. If it is not a lack of skill or direction then you may need to motivate them. As a last resort that may mean warning them and ultimately removing them. When tasks are completed you should sign off on them. Verify that it is in fact completed per specification.

When things are released from your team that are incorrect it is your responsibility to correct it. That means what went wrong in your policies and procedures that allowed this problem to slip past, not debugging the program. To err is human, to forgive divine, but to continually repeat the same mistake is careless. More generally things that interfer with the productivity of your team is your responsibility to deal with. An example is source control so people aren't wiping out each others changes or making sure two people aren't writing the same program blissfully unaware of each other.

Overall the last thing a lead programmer should be doing is programming. Generally when a lead programmer programs merrily away the rest of the team is setting there wondering what they are suppose to be doing. That doesn't mean you don't program very much, but you don't set around programming when everything is falling apart around you. If the project is going to fail unless you single handedly save it then delegate or outright resign the lead position. There is nothing wrong with simply preferring to program, but rather only with holding onto the lead role when you really have no interest in leading.

Thanks LilBudyWizer, that was exactly what I was looking for.