Good questions! Well, if it's anything like dancing (and I think it might be), we'll always have a hard time telling when we're good.

Going with that analogy, I'd say you know when it gets easier, when you begin to see forms and patterns, and can use them to tackle new challenges.

Some other thoughts: * When you are solving problems and seeing how to improve your code through testing and refactoring.

* When you can start reading other people's code and understanding the gist of what is going on at a high level without getting bogged down in the details.

* When you start feeling very comfortable with your tools.

* When you feel the satisfaction of solving problems.

* When you help others learn something.

Finally, dance like no one is watching. Enjoy yourself. If it's not bringing you joy, then you are unlikely to progress further. Either way, enjoy the process.

it’s based on the size of a codebase you feel comfortable managing. for me personally, due to my emotional regulation problems, it was also based on the point in time about 1000 hours in when I stopped getting really frustrated with a problem I couldn’t solve immediately. when i learned to accept the speed bumps as part of the process and started trusting myself that I would figure it out eventually. which gave me confidence and the ability to enter a flow state more sessions than not, which allowed me to be much more efficient with my time.

I don't think it's for you to tell; I think it's like (as someone else mentioned) dancing or playing guitar or other creative arts - the only judge is other's feedback on the output you produce, preferably some kind of balanced mix of experts in the field, peers at your level, and the public at large.

We don't really have standard competitions (no, HackerRank and Kaggle don't quite count) but certainly (much like creators) coding in the open, collaborating, and soliciting feedback on the things you've code is probably the most certain way.

One thing that I've always admired about 30k hours high performing folks is their sheer level of output; because they have mastered things, producing new things becomes something almost effortless, and so their challenge becomes keeping psychologically grounded in that high performing zone (avoiding the "yips"); collaborating with others to break new ground; and putting their talents to their most effective use.

When the spec for software you're developing changes after you've finished developing it, what percentage of the time do you need to significantly refactor your logic instead of just making a minor tweak/extension?

Might not be a perfect measure, but it's a very noticeable one that in my experience has been going down sharply as I've gained experience.

I think this can be measured in how long it takes another capable programmer to get up-to-speed in your codebase (accounting for the overall size/complexity of the domain, of course).

Have you read Peak by K. Anders Ericsson? I haven't found the answers you're looking for, but I'd start with reading that book.