It doesn't matter. What matters is success. A good developer will be more successful in the marginal projects, and cheaper in the very worthwhile projects, but that is just a matter of dollars on the bottom line. The best developer in the world cannot save a stupid idea. The worst developers just ups how insanely profitable, and how long he need to wait a project must be before it is successful.
The above assumes a single developer. If you have a team of developers it quickly becomes obvious. In fact a boss who knows nothing about programming is probably better able to judge if someone is doing a poor job in these cases: those who know the new guy see him trying to get up to speed, while the boss sees a bigger picture by comparing to others. (a good developer will be making useful contributions on the second day, while a bad one will flounder for a couple weeks before the others will give up on teaching him the project)
>If you have a team of developers it quickly becomes obvious. In fact a boss who knows nothing about programming is probably better able to judge if someone is doing a poor job in these cases
I've been on such teams and that isn't what happens. This is:
* Team mates do not like badmouthing their coworkers unless they do not like them. Hence, if a coworker complains about another coworkers' performance its as likely to be due to a personal problem as it is performance. Most coworkers also won't know each others' wages so they are in an even poorer position to judge relative performance.
* Managers without technical chops are incapable of distinguishing hard tasks from tasks that are being done badly or easy tasks and tasks that are being done well. They are incapable of distinguishing quality engineering from hackjobs that will blow up in 6 months. They will either default to just assuming every developer is more or less equally productive or use terrible proxies for productivity (like how late each developer stays at work or their scrum 'velocity').
* Good performers who do not have their achievements recognized will leave for better paid positions, leaving mediocre and poor developers. The quality of the product takes a dive. Profitability may also take a dive as a result if the industry is competitive and the quality of the software matters.
The above assumes a single developer. If you have a team of developers it quickly becomes obvious. In fact a boss who knows nothing about programming is probably better able to judge if someone is doing a poor job in these cases: those who know the new guy see him trying to get up to speed, while the boss sees a bigger picture by comparing to others. (a good developer will be making useful contributions on the second day, while a bad one will flounder for a couple weeks before the others will give up on teaching him the project)