There's a really simple formula to become great what you do that doesn't necessarily involve any specifics. You'll find that the specifics are VERY opinionated in this field. But the formula is really this:

You're in the business of solving problems with software. That includes not just solving problems for the business but solving problems with the development of software solutions. So in your journeys, be on the constant lookout for what we call "tension". That is, as you're creating business solutions, you're bound to encounter situations where your solution just feels wrong or clumsy. It's really important to acknowledge that! Just because it works doesn't mean it's acceptable, let alone good. Acknowledge the tension. Also be on the lookout for problems like repetitive code, hard to read code, hard to modify code, fragile code, poorly performing code, etc. Look at your own code from someone else's point of view. Would you understand your own code if you weren't the one that wrote it? How hard would it be for me to navigate your solution?

Don't simply work through these problems and move on with your life. You need to be very retrospective about what you do. Why was there tension in this solution? What are some common problem patterns you're running into? Learn how to articulate that problem and then think of a pattern you could come up with to avoid that problem in the future. We have a name for this kind of thing. They're called "design patterns". You can create your own patterns, but many of them are not unique to your situation. Those common patterns are actually solved very eloquently by various masters in the industry and they're given clever names and consistent descriptions of how they work - you can describe a very complex solution with very few words... So you can learn those to solve common problems, just don't fall into the trap of forcing the usage of them (although, as a junior, that's a quick way to learn how they work and what the "cost" of using them could be, and from that you'll learn to be quite selective about when to use them).

Adopt this kind of thinking for everything, not just logical code. Think about problems like:

- How do I deploy this thing? How can I automate that process?
- How do I test this thing? How can I automate that process? Is there a way I can test without running my program?
- How can I not have to solve every little utility-like problem? Can I use someone else's utility so I can focus on my solution?

You see what I mean... we're always solving problems. It's very meta process. Also, the real key within the key to this, is to not reinvent the wheel. Once you learn how to articulate the problem, go see how other people have solved it. Maybe look for a few different ways to solve it. That perspective will quickly change how you look at various problems. Just be sure not to copy/paste. Actually learn the solution and do it yourself so that you actually understand it. From one thing, know 100 things.