[Blackthorn]

I know you admit that it's a gross oversimplification but this kind of talk still bothers me a lot. It's a lot like when, to use a (honestly shoddy) metaphor, people talk about rankings in a video game like League of Legends. Some times you'll hear talk like "the difference between a bronze and silver player is game sense!" or "objectives control!" or "mechanics!". The truth is it's all of these things and none of them. A silver player is simply better than a bronze player.

I think the same goes here. There's not some magic thing that a senior developer has that a junior developer is missing. They are simply, overall, better.

[stuartaxelowen]

> A silver player is simply better than a bronze player.

> There's not some magic thing that a senior developer has that a junior developer is missing.

"They're just better" is a way of saying "this is magic and not quantifiable". If you cannot quantify what factors allow one developer to consistently deliver quality software on schedule, then you cannot grow your team in that direction, and are essentially rolling the dice.

[dropit_sphere]

That would be true if you were programming your team, but what you're really doing is setting the magnificent machine known as the brain on the problem, which does all sorts of things we can't explain.

I'm all for figuring out explicitly how to deliver software better, but pretending that implicit knowledge doesn't exist seems like folly.

[stuartaxelowen]

In a sense, you are programming your team, in all the things you emphasize and spend time talking about at meetings.

Also, there are obvious things that make developers more able to deliver quality software, and there are obvious things that make gamers more able to win games, just as there are with famous athletes. Thinking that there aren't specific predictors of success here is as silly as saying there aren't specific predictors for what makes a good QB.

[dropit_sphere]

>In a sense, you are programming your team, in all the things you emphasize and spend time talking about at meetings.

I'm saying that the analogy is just an analogy, and doesn't apply strongly enough. What you're doing has strong components of feeding an ML algorithm training data. Yes, people have intentions and can understand processes, but that's as far as it does. We're certainly not writing neuroassembly.

I don't mean to imply that there are no predictors for better performance, but I bet there are fewer than one might think. A lot of the factors interact in discontinuous or nonlinear fashion, making it very hard to just draw correlations and call it a day.