I got better by doing the opposite of what you do, and find reading a lot of anything before trying it to be a complete waste of time. Unless it's a different w

I got better by doing the opposite of what you do, and find reading a lot of anything before trying it to be a complete waste of time. Unless it's a different way of explaining or building on something you're already familiar with. I've read numerous books on various languages and frameworks, but they've only been useful if I've been incrementally trying the code as I go. Documentation is basically pointless to read unless I needed it, and if someone interrogated me on the method signature for some api, I'd probably laugh. I used to think reading counted as learning, but it doesn't, and coming to that realization helped me learn a little more efficiently. Other than that, like others have said, reading and poking at a lot of code, diguring out how to get something accepted in a big legacy open source project would help tremendously, and is something I recommend to anyone serious about starting a career in programming. Also, ya having the humility to accept you're not as good as you might think is pretty pivotal. A few years ago I basically just started accepting that I'm only as good as some measure (that I accept as a valid measure) says I am, but my nebulous opinion of my own skill isn't as valuable. Could be commit count, could be code clarity, could be PR reviews, time to completion of a task, whatever. Pick some measure you agree with that would be relevant, and aim to reduce the variability in hitting a mark. Think about what 'good' means in the context that you want to be good in, and build a mental model of that