My kids are playing chess. And they really eager to play it even better. Therefore I'm reading books about how to teach chess. Much of the advice in the book are really not that specialized on chess but are applicable for any kind of learning and training. One of those advices is: There are three kinds of training:

Theory: Here kids learn about different patterns (yes there are patterns in chess just as there are in software development). They learn when and how to apply them. Mostly by looking at examples and analyzing them. They also learn rules, like how to properly convert a pawn into a queen if no queen is available (Hint: turning a rook upside down doesn't work)

Practice: In this kind of training the kids get isolated problems to solve. Puzzles basically. Like Mate in one. They also do games based on chess rules, but not actually chess. Like collecting gummy bear from the chess board with knights.

Play: Starting from a friendly game against family or other club members to tournament.

I think it maps 1:1 to what you should do if you want to improve your software development skills:

Theory: Read books, read blogs, go to conferences. Learn as much as you can about design, algorithms, network protocols and so on. 90% of all developers neglect this. But since you are already reading this blog, you are probably among the other 10%

Practice: Do Katas, Dojos, spikes, tracer bullets, prototypes. Write code. But not in order to have working code in the hand but in order to learn and explore. I'm afraid 90% of those doing the theory part completely neglect this part. You should not. The first couple of times you try to use something which you have read or heard about, you probably will do it wrong. To bad if this is in a real project with time pressure and lots of money at risk.

Work: If you take care of the first two parts work will still bring some surprises. Your agile approach runs into problems because the customer doesn't like it. Your nicely normalized schema doesn't happen because you have to use an old existing database, used by lots of other applications, what worked nicely in the kata fails flat on its face when applied to 1 million records ... So there is still a lot of stuff you can learn at work, but for this you have to think about what you are doing at work. Chess players eager to improve their skills analyze games they played in order to understand which move was good and which wasn't. Do you do that? Do you do a personal retrospective in the evening? Thinking what you did well? What you could have done better?

I think you should.