Having spent 2023 doing exactly what you aspire to do, I have some casual friendly advice: go into this problem-first.
While everyone learns differently and finds motivation in unique ways, nothing pushes me through all of the layers of frustration and learning like having an end-goal that I'm passionate about realizing. On the contrary, just hitting a list of things to learn in an arbitrary order hoping that it will stick when I actually need to get something done is like driving high speed into a wall.
When you approach a problem, the correct answer to "what next" is usually pretty apparent. In my case, for example, I had no idea that transitioning from software development to "hardware" (which really is just software running on hardware) would involve detours into learning Solidworks CAD so that I could model enclosures as well as render out what things will look like before they exist.
Another major area that I drastically underestimated was connecting the dots between the parts/components I use and the logistics of sourcing and using those parts. For example, the parts that are easily available on demand at JLCPCB are not only vastly different than what you can get from Digikey and Mouser, but they often need to be ordered in quantities of 100+. It's also "fun" realizing that if you want KiCAD to have nice looking 3D renders of your future board, you often have to go off hunting for 3D step files of each part. You are about to learn how it's common to make an order at Digikey that is actually shipped to JLCPCB so that they can assemble your board. They will even hold on to your parts in between orders.
Get comfortable with Octopart!
One project that I recommend is to actually implement your own MCU board instead of relying on prefabricated Adafruit or Arduino boards. Not only will it give you more flexibility, but there is something really gratifying about fully understanding how and why everything is working. While there are many tutorials on how to do this, I personally really like working with RP2040 chips and I found this three part series excellent: https://www.youtube.com/watch?v=RNH-CL8GrF8
One bit of parting advice (feel free to ask more) is around the concept of switch debouncing and hardware interrupts. I've found that there's a sort of "stages of grief" where people go through a dozen increasingly complex ways to make 1 press = 1 event. The short version is that there's no perfect way to do it in software, and where software is involved, you want to move away from polling pin state in your loop to using interrupt handlers ASAFP because sleeping in your loop is the root of all evil.
IMO, the only correct way to do switch debouncing is to use resistors and capacitors; this is known as an RC debounce (Google it). You then send those signals into a hex inverter like the 74HC04, and then into a digital pin on your MCU (which is then captured by an ISR hardware interrupt).
Every other path will just lead to pain. This might seem like a digression, but you'll thank me later.
Finally, you will be pleasantly shocked by how amazing GPT is at talking through schematics. It knows the datasheets, can explain circuits and alert you to quirks and gotchas.
ps. if you find yourself without interesting problems to solve, I highly recommend buying some cheap Nerd Musician courses and building some MIDI controllers! https://www.musiconerd.com/