You count the number of lines of code a programmer writes, of course. ;)
Seriously though, there are two aspects to a developer's performance, and that would be quality and quantity. For what concerns quality, you can roughly determine this by the occurrence of bugs which show up in a section of code written by a developer (though keep in mind that there will be bugs from the best of developers), and the time it takes to fix these bugs (though again, you'd have to look at averages since some bugs take longer to fix than others).
For what concerns quantity, tracking progress of a programmer is notoriously difficult even if for the simple reason that it's difficult to gauge progress in the creation of a program. Traditional thinking would suggest that if it takes 1 programmer one month of time to perform a task, 2 programmers would take a half a month to perform that same task (The mythical man-month). That's been proven again and again to be a completely inaccurate judge of progress.
Though it's clear what isn't a proper judge of progress, it's not clear what is. At this point you enter the realm of highly argued ideas about what are best practices for judging progress. Though, perhaps the best idea I've heard is to hold a meeting with a group of developers and ask each one to estimate how long it would take to develop a specific task. Take the average of all estimates and double it (yes, double it), and you have roughly a safe estimate on when it should be done by an accomplished developer, bugs and all. However, there are always exceptions to the rule, so it's better to evaluate performance of a programmer from a statistical standpoint rather than ability on specific tasks.
My advice would be to break down the tasks of a project into well-defined bite-sized pieces and handle each one with its own estimated deadline. After a few of such tasks, you can begin to get a feel for how developers perform with respect to their estimated deadlines.