I wouldn't describe myself as a programmer, but I have spent a considerable amount of time and energy thinking about how to become 'better' as a data scientist (as well as how to encourage others to grow their skills and knowledge, and how to measure that growth). So, I can share some tips about learning in general (i.e. metalearning--"learning how to learn") that should apply no matter your field. If you devote yourself to (effective) learning and improvement, you are as 'good' as you can be, and that is what matters.<p>1. People learn best by a) effortful 'doing'/practice and b) spacing that effort out over time. (Actually, not just people...almost every organism seems to learn more effectively this way.) Generally, the marginal benefit of learning time is greater when you expend effort directly applying knowledge/skill to a difficult and meaningful, rather than ingesting the output of others. An hour spent solving programming puzzles is more effective than reading an hour of others' puzzle solutions. 10 hours spent doing either is better spent if it's spent as [10 x 1hrs] vs. [1 x 10hrs]. Spend more time working on side projects that motivate you, solve book problems, solve coding challenges, practice explaining a technical concept to someone, etc. Spend less time gliding above the vast wilderness of what there is to know, observing the work of others--hit the ground and blaze the trails yourself (but don't rush it).<p>2. Programming, like data science or research or basketball, is not really a discrete skill you can directly improve at. Each is composed dozens/hundreds of sub-skills, and mastery of the field is a lifelong endeavor of building up these individual skills as well as connections between them. What strengths form the core of your identity as a programmer? What about areas for improvement? (relative to what you want to be, not compared to coworkers/HN folks/world-experts)<p>3. If you find yourself sharpening the same swords again and again (as I have), then look for an area of both weakness and interest to reallocate effort to. The learning benefit per unit of time is greatest when you spend it on something in your 'zone of proximal development'--not too easy, not too hard, not too irrelevant, but just right. Sometimes, this may mean diving headlong into the difficult thing you believe you "should" know, but have been avoiding. Other times, being "better" at your field means improving at something that seems tangential (communication/presentation, documentation writing (!), time management, domain knowledge, mathematical skill, whatever). Just don't fall into the trap of 'oversharpening'--expand your arsenal.<p>4. Teach/communicate what you know to others. Interact and network with others both at, above, and below your general level of experience. This not only helps solidify your knowledge into something permanent, but incidentally is one of the best (only?) ways to be perceived (rightly or wrongly) as knowledgeable. You don't even need to do this 'for real' for it to work--I imagine myself explaining code / mathematical concepts to some imaginary audience, whether it happens or not. And if it does, you'll be prepared...(While backpacking in Yosemite recently, I encountered a professor that asked me to explain a ROC curve to him. Another time, I awoke on the train to an elderly lady, seeing the title of book that I fell asleep on, asking me what a stochastic ["stoychistick"] process was.)<p>5. Beware that the 'better' you become, the more inferior you may feel. Climbing higher gives you an unobstructed view of the yet taller peaks in front of you, and the canyons blocking your way. Remember to take pride in the struggle.