I did something very similar with an old strategy game called Age of empires II. Over the course of two years I went from a 1300 rating to 1850. I don't play chess, so it's hard for me to compare the scales, but I will say the highest players were rated around 2600. I think being 1850 put me around 90-95th percentile for active players-- there were less than 50 players over 2300, and only a few hundred over 2000. My…
I don't know if you've ever played runescape but it has a very similar experience to the one you are describing. It's interesting you compare your time spent in a game to time spent productively outside the game. One of the things driving the 'investments' in those style of games(MMO's) is that you get this feeling of progress and can compare your progress to your friends 'skills'. I've been writing alot in my person…
Unlike many MMOs the grind is not heavily stat-focused either: while you can get unlocks and upgrades, most of them constitute "sidegrades" into a specialty role. On the field, your effectiveness still comes down to knowing the ins and outs of the gameplay. And there are leaderboards to motivate competitive players, but it's widely acknowledged that playstyles are not represented equally on these boards: it is straightforward to get a very high K/D by learning one of the various kill-farming techniques, and to get a lot of experience points with a support role around a meatgrinder battle. But those things don't necessarily contribute the most to your faction.
It's things like that that suggest where the model breaks down on application to real world skills. Generally, once a person is aware of the things they need to focus on, through good feedback, they can stay on the task. But if you look at a thing like programming, it's like, "where's the feedback?" It's not the butt-in-chair hours that are doing the lifting here. And it isn't reducable to lines compiled or issues cleared or other single-number metrics either. "Speedcoding" is only good in rare circumstances. It's more like a finished project is a series of quests that build on each other, with each quest having some checklist pass/fail requirements. But each one is bespoke, and hard to compare to others even if it's applying the same skills.
Indeed I actually do write down pass/fails conditions as a checklist in the comments to start with a complex implementation, and to create a kernel of documentation. Having tools helps, but it's that early conceptual/goal-setting where I put down boundaries that seems to make the biggest difference.