Kernel development is mostly 3 things: Adding & improving drivers (which require knowledge of how pieces of hardware work), adding & improving architecture support (which requires knowledge of CPU features), and adding & improving core kernel data structures & algorithms (eBPF being a recent example).

What all of these have in common is the C language (for now), the kernel coding style, the kernel data structures and algorithms (things like lists and locks, which serve as primitive building blocks for doing more advanced features), and the general layout of the kernel modules and subsystems within the codebase.

Personally I would recommend splitting your time between something you are trying to accomplish (perhaps adding a new syscall, or new hardware support), and general understanding of kernel development. So pick a goal and read about how to accomplish it (or read through code that was added that does that thing), and also read as much general information as you can (lWN, kernelnewbies, the LKML, etc.)

Picking a goal to accomplish doesn't have to be achievable, but doing the research will give you an anchor point for further context later.

I tried doing this a couple years ago. You should download the source and read the docs. If I remember correctly noobs are recommended to make improvements in drivers/staging. There are "TODO" files with things that need to be done. There is a good post about "wanting to contribute" that used to be at the top of the kernelnewbies IRC channel you can read.

Start here: https://kernelnewbies.org

Which level are you at? If beginner, why not just start reading the code? Pick a small driver of the hardware of your choice, then print it out and start puzzling.

Not sure if it's still on offer, but search for the Eudyptula Challenge maybe.

I didn't like it personally but YMMV.