I've only written a simple LKM to patch the interrupt descriptor table and patched the kernel pool memory allocator on the true operating system of the proletariat (That is to say Plan9) but I think I can safely say that you don't just hack on it and see what happens.

The knowledge required to write device drivers or understand and manipulate kernel behavior is totally distinct from what is typically taught in Computer Architecture/Computer Science and Software Engineering, a massive amount of knowledge is required that I could see no way to acquire short of trying to build your way up designing/reading kernels of greater complexity or being interested in some field where consecutively deeper levels of knowledge are an exponentially more profitable use of your time such as information security.

The documentation on ALL modern kernel's current implementation details is sparse (yes, even Linux) and the knowledge is assumed which gives some truth to the statement "You just hack on it" in the sense that there's no way to learn it save actually doing it. In truth however, to really get anywhere you MUST know x86 (Or whatever architecture you are developing for, additionally, if you think this will be easy because you coded MIPS or SPARC in school, be prepared to feel dumb), you MUST know deep C and a slew of other topics that the typical CS education leaves you remarkably ill-equipped to even get started.

I agree, but that's because you're starting with an existing kernel you're trying to improve. If you were a startup-sized team with no kernel programming experience and you had to write an entire OS from scratch I think you'd be pretty likely to end up after five years with the software equivalent of the non-competitive microprocessor designs the grandparent describes...

[Note the caveats: obviously history provides us with examples like Linux of OSes from scratch which did get from zero to competitive in five years but that had rather more people working on it.]