I know quite a few backend developers who grew a lot by working in (application) operations for a month or three. If you can do so within a company or at a university, I'd very much recommend doing so - and not just because my team is chronically overworked and every pair of hands is a good one.

If done at the same company, you'll get a lot of insights in how the infrastructure works and is setup, and you'll quickly get in touch with a lot of technology. Additionally, you can quickly learn the values of good logging, good metrics, good dashboards - and the pain of not having those. If you listen, you can learn a lot about running an application server from a bearded postgres admin and his monitoring.

My long-horizon strategy has been the kinds of roles I take on. A product-focused role lets you go deep into a narrow problem area, whereas a customer-facing consulting/services role forces you to go wide, learning a new area every time. Over the years I’ve used time in the latter to select what to go deep into.

The best way to learn is by doing. Start a side project or contribute to an existing open-source project. Make sure it's completely out of your wheelhouse to learn the most. At the end of the day hopefully you have a cool thing to show off on your blog or GitHub page.

I'd say it's more about prioritizing what you want to learn. For one thing, frontend or backend? Fullstack?

It's worth asking ChatGPT. Seriously, you can get a list of options and then discuss whichever one you want.

my personal feeling, it is not easy to grow both breadth and depth. say, you are working on a project with a language/platform, if you want to be an expert on that, you will need to know it pretty deep with details... that takes your time. certainly many things are related, you will be easily jump to other language/platform. but your time/focus is limited...

some folks like to stay on top of more things in general (grow breadth), and don't like to dig a deep hole in one thing, certainly it does not mean they don't have the ability to do so...

guess, it is all up to your interest/time/focus... just do the best with what you are doing, really understand you need to understand, and learn more related for interest... that is probably the way to go. my 2c

Read this book: Object Thinking, David West

I agree with others suggesting that learning by doing is ideal.

I think my most instructive and eye opening experiences have been both trial by fire in unwanted situations and passion projects in highly desirable situations.

I keep a passion project on the go all the time (though I actually had a gap in that practice for a few years before the pandemic), and that’s how I learn what I’m deeply interested in. I might visit it an hour per week or 20 hours depending on what’s going on in life, but I let myself tend to it and be excited about it.

Right now I’m fascinated by how awful the developer experience story is around deploying, maintaining, and observing embedded systems. There are solutions out there, but none I’m aware of are particularly good. Most are very single purpose, many are proprietary, and they often have no support for treating these systems like something a software engineer can interact with. So, I want to find ways to address that because I think it would be incredibly useful. Will I succeed? Probably not. I might make something that works well for what I do with popular microcontrollers and raspberry pis. But I’m learning so much and I really love it.

So what would you like to build? What are you crazy about? It doesn’t even have to be useful. If you can, just think of something that gets you excited and let yourself get engrossed if you can.

Otherwise, taking on harder projects at work has been a huge source of notable learning experiences that go far beyond what I’d get from blogs, books, or YouTube. Especially soft skills. Managing hard projects with people requires good skills in managing scopes around unknown unknowns, communicating challenges and drawbacks tactfully and promptly, learning how to delegate or find the right people to learn from, how to drop your ego, and generally how to more gracefully get your ass kicked by challenges that are maybe 10% bigger than you are. I think people are at their best when they’re under a bit of pressure (though a key thing here is that it’s critical to be in a setting where it’s okay or safe to be under pressure — this experience is awful if you work with people who can’t handle setbacks or those unknown unknowns, for example).

As long as you can go into it knowing it’ll be hard and that you’ve got the resources to go all in on it, you’ll likely come out the other side much better at your job.

I find these experiences a lot of fun. Sometimes I take on contracts that are quite a bit different from what I’m familiar with just for that experience. Earlier in my career I’d kind of fake it until I made it. These days I’m very open with what I know, don’t know, what I feel confident learning, and so on. I think the latter is the correct approach now.

I’d also emphasize that a great way to learn is to find people who are smarter than you. A while ago I stayed in a job for a while where I was the most senior developer, but there was no room to move up or laterally. I loved mentoring and actually learned plenty from that, but found I was far too limited in my own work. I left that job and wound up being the least experienced on the next team (around 7 years experience vs 15+), and my god, I learned so much so fast. I was sad when that contract ended, haha. Smart and capable people are an absolute gold mine and I seek them out constantly.

Finally I’d say that asking people about what you’re working on can be remarkably useful in expanding your perspective on solving problems. Waiting until code review is too late. Try to collaborate early on and get people’s insights on how they’d approach different problems. Use this as a way to learn about their strengths but also to be open to new perspectives on the work you do. Sometimes people will drop little insight bombs, even people far less experienced than you, and you’ll flesh out projects differently than you normally might. This is one thing I miss about office work; I love this kind of real time collaboration. I encourage people I work with to do this because the chance that they can unblock someone or be unblocked is really high; your team is a resource if the workplace culture is right.