Lines of code, files touched, bugs fixed, hours worked. Basically any quantifiable metric. There's a couple of reasons why it doesn't work.
Metrics either try to encapsulate too much or too little scope. For example; is having more lines of code per week a good thing, well only if the lines of code are meaningful, how do you measure that? And that would encourage verbosity over simplicity.
Another issue is that it's almost impossible to stop engineers pleasing the metrics, rather than solving the problem. If their job or bonus depends on a metric, then that metric becomes a higher priority than the actual job.
It's also incredibly hard to quantify contributions to an evolving project. Writing software might be compared to building a house from a design, where someone is paid for precisely how many bricks they lay. But software development has transitioned away from the waterfall design, to a more iterative approach. This means huge amounts of effort put into the product, might be designed out through iteration and changing business requirements. So if you were to pay people based on the end product (like brick layers), some people may receive nothing.
Basically, there's no way to fairly attribute the success of the system to individual programmers. Good software is written by teams and good teams are comprised of different people with different skill sets.