О зарплате программистов

Сегодня беседа с одной своей знакомой программисткой навела меня на рассуждения о том, как же все-таки надо оценивать затраты труда программиста. Вот я и решил поделиться своими соображениями. Сразу оговорюсь, что я не являюсь экспертом в этой области (имею ввиду оценки производительности), и все нижесказанное является плодом моего воображения, критику к которому я с удовольствием приму в комментариях.
Для меня производительность - это характеристика, показывающая, насколько эффективно один человек работает. Сама по себе эта характеристика бесполезна ввиду того, что никак не позволяет влиять на "цену" этого сотрудника. Если существует всего один программист, то его цена никак не связана с его производительностью. Поэтому интереснее рассматривать производительность как способ влиять на цену труда программиста в контексте рынка, когда конкуренция устанавливает цены. Здесь гораздо важнее становится относительная производительность, показывающая насколько один программист лучше другого. Так как же можно измерить эту величину?
Я считаю, что за некоторыми исключениями, никак. Рассмотрим различные способы, которые я нашел в интернете:

• Количество строк кода. Наверное самый идиотский способ, которые едва ли применяется где-либо на практике. Эта характеристика не показывает вообще ничего, что не является секретом для любого, кто сталкивался с программированием.
• Количество реализованных сценариев (use cases). В теории это могло бы считаться адекватным способом измерить производительность, поскольку опытный программист может оценить сложность одной задачи относительно другой. Но появляется сразу несколько нюансов: задачи могут зависеть друг от друга, некоторые задачи могут иметь низкую сложность, но занимать много времени (пример - однотипный рефакторинг под уже запрограммированную архитектуру в противовес разработке архитектуры даже небольшого участка системы). В итоге становится непонятным, как сопоставлять сложность и длительность работы над задачами. Как оценить, что один человек работает производительнее другого?
• Гипотетический случай, когда программисты делают одну и ту же задачу, а затем сравниваются результаты. Даже в этом случае нельзя судить о производительности, если только вы не намереваетесь платить за конкретно эту задачу. Выбор подхода, например, чаще всего является субъективной категорией для более менее больших систем.

Наверняка есть и другие способы цифрами оценить, насколько один программист лучше другого. Я считаю, что ни один из них нельзя использовать как достоверный. Это связано с тем, что написание кода представляет собой творческий процесс, который уникален (очень часто, хотя и не всегда) для различных задач. В связи с этим программисты будут вести себя по разному в зависимости от поставленных целей. Здесь я даже не пытаюсь учесть влияние внешних факторов, которые тоже могут менять ситуацию.
Но как тогда можно решить. кому сколько платить? Я бы выделил 2 варианта для относительной оценки производительности программиста:

1. В силу опыта и знаний, один программист может выполнить работу, которую второй выполнить в принципе не в состоянии, либо не сможет сделать этого за какое-то разумное время. Например, я не представляю себе, чтобы я смог спроектировать операционную систему даже в общих чертах. У меня банально не хватит опыта решения архитектурных задач, чтобы это сделать. Я бы назвал этот пункт единственно возможным способом объективно разделить программистов. Это я и имел ввиду под исключением. Но здесь идет деление на "уровни", на каждом из которых по-прежнему много людей.
2. В каждой команде есть менеджер. И этот человек является ключевой фигурой в оценке производительности. Очевидно. что его суждения всегда носят субъективный характер. Но он  руководствуется двумя вещами: ситуацией а рынке и в команде. Программисты так или иначе представляют уровень зарплат коллег, а значит могут оценивать затраты и отдачу в работе. Если в команде нет по этому поводу конфликтов, значит менеджер держится хорошо в плане оценки производительности. А корректировать стартовую точку ему вполне может помогать ситуация на рынке. Иначе команда может распасться ( это тоже упрощение, конечно) из-за неадекватной оценки  в целом. В принципе рынок можно было бы не рассматривать, а обобщить пример в том смысле, что все представляют зарплаты всех, а задач менеджера дать тебе оценку относительно рынка, с которой ты был бы согласен.

Зачем я все это пишу? Мне хочется показать рассуждениями, что нельзя применять количественные оценки работы программиста. Дело в том, что затраты усилий внутри команды хорошо видны. И видны они менеджеру и команде. Я в данный момент не знаю, как эти затраты можно померить объективно. Если команда ощущает, что их усилия вознаграждаются соответственно, то проблем быть не должно. Но если кто-то пытается тыкать какими-то числами, которые скорее всего не соответствуют реальной картине, то конфликтов не избежать.