> judging the direct merit of each others work is hard. Mostly because the work is a spectrum between “core” work, that is required, and “new features” You can

> judging the direct merit of each others work is hard. Mostly because the work is a spectrum between “core” work, that is required, and “new features” You can't implement the new features without the core work to provide a foundation. Don't judge performance by financial impact of the code, judge performance based on peer review. If you've got 2 programmers, you'll want them to be doing things like design reviews and code reviews, and as such they'll be able to provide a reasonable assessment of how well they think their peers are doing. Whether each bit of work itself needs doing in the first place? well you need a signoff/approval process. Whether that's a manager, or simply a chat with your peers - the act of convincing others that yes I do need to implement this core XYZ instead of feature Q is an important one