Original post by dclyde
To be honest, even most programmers cannot schedule themselves well.
Oddly, knowledge of actual programming is only a small slice of the pie when it comes to the scheduling as there are several major factors.
Complexity of the problem - This can vary from technical challenges to the current infrastructure of your engine.
Related experience of the programmer - Have they worked on related systems before, or can they work on things they have no knowledge of well.
Motivation of the programmer - Different people are motivated by different things. If you have one graphics programmer and he is visually motivated he will do complex lighting systems much quicker than he will redo the underlying mess engine code to be more efficient.
Existing infrastructure - Does anything exist already in the engine to help this task out?
In general a good lead will pick up on the strengths or weaknesses of his team and even then will probably still only use that for matching the right task to the right person and will then ask them to estimate the time. If he knows them well enough he knows what multiplier to apply to their estimates.
When I estimate my tasks I have multiple numbers in mind. Potential minimum time necessary to write the system. Potential maximum time it will take assuming I run into technical challenges. Actual number of days it will take given the number of interruptions I tend to have per day and other responsibilities. Each place does things differently. For instance in my current job I am asked to round all tasks up to whole days and account for distractions myself. At my last job I gave the actual range of programming hours it would take and they knew that I only got the chance to do actual programming during 50% of my day so they knew I would only get through 20-25 hours of programming a week.
Overall I have never met anyone who accurate estimates their programming tasks. There are almost always too many unknowns. Most programmers I have met know how optimistic their estimates tend to be and have their own internal multiplier they use when estimating tasks.
The part that helps the most from an outsider point of view for scheduling is being able to break down the task. But to be honest almost no one person at any company can break down every task for every discipline. Especially like I said when there is existing infrastructure reasons that something may need to take longer. (vague ex: We currently skin on the GPU, if we want way more complex shaders for a ps1.1 target we would need to move skinning to the CPU) which someone not ultimately familiar with the system would have no idea about. Working with the people being scheduled or their lead is usually the most efficient way to do it. Being curious during these scheduling meetings will introduce you to the topics that you would probably care to research.
well my time management is more about individuals at this point. figuring out exactly who has talent and isn't along for the ride...