In situations where agile/story-points make sense, I suppose developers that accomplish more story-points are "better".
In academia, articles that are referenced more frequently are "more important". For page ranking, pages that are referenced more frequently, are more important. I wonder if there's an equivalent with infrastructure programming? If a developer builds a subsystem that is used frequently, does that indicate the developer has provided substantive value?
> In situations where agile/story-points make sense, I suppose developers that accomplish more story-points are "better".
Not really. Story points are cost estimates--a subjective judgement of how much effort a story will take. They're a prediction tool, not a productivity measure. It's very easy to increase the # of story points you deliver just by increasing your estimate and possibly even sandbagging. Not good.
If story points were value estimates, created by a business folks rather than developers, they'd be better measures. But even then they'd be subject to gaming. It's easy to increase velocity in the short term by incurring technical debt. Say, not writing enough (or good enough) tests. Or not helping out co-workers. Or not spending time understanding business context. Or...
You are not the one who choses what subsystem you will work on, If someone writes a mandatory wrapper for logging which then is used in every single subsystem doesn't mean anything. If someone writes the selfdriving algorythm for the car which works on itself but is not used by other subsystems, this means nothing either.
In academia, articles that are referenced more frequently are "more important". For page ranking, pages that are referenced more frequently, are more important. I wonder if there's an equivalent with infrastructure programming? If a developer builds a subsystem that is used frequently, does that indicate the developer has provided substantive value?