[MeMO Pad 7 Original Android Development] lambdadroid:
That's hard to say. ROM development is hard because there is not much documentation. It's hard to create guides and tutorials because the procedure is different for each device. At some point, you run into a problem no one has run into before and then you are on your own. It gets easier when you have a basic feeling of how things are usually working. Still, Android is a huge operating system, so you will always run into things you haven't dealt with yet.

Usually, you pick an existing device tree for the same SoC and might be able to get most things working with a few minor modifications. Almost all ROMs are based on the stock kernel from the vendor, with additional patches and optimizations. Since device vendors usually make massive changes to the kernel, all you can do is apply selected kernel commits (e.g. those that fix certain security vulnerabilities). Upgrading entire kernel versions would be way too much work.

To some extend, the fact that this tablet is based on an Intel Atom x86 processor made this even harder. There hasn't been much ROM development on x86, so less examples from other devices. However, since the tablet is based on x86 and the majority of hardware components are supported by the upstream kernel, we can easily jump to newer kernel versions. Where other devices rely on proprietary libraries for a lot of functionality (e.g. OpenGL, etc), I've built the ROM on open-source components from other projects such as Android-IA or Android-x86. Fixing bugs is much easier when you have the source to look at.

Still, barely anything worked out of the box. I've spent 2 or 3 months before I released the first build in July to get the basic set of features (get it actually to boot, WiFi, sound, ...) to work. When you're lucky, you have at least an error or similar you can search for in the Android source to find potential reasons why something isn't working. Initially, neither the touchscreen nor USB (for ADB) were working so you can imagine that fun I had to figure that out... Tried a lot of stupid stuff like copying code from the ancient ASUS kernel. Didn't help. At the end it was usually just ~10 lines or so that fixed the problem.

Now, we've already left the really hard and annoying part behind us. Most things are working, we can get logs using USB, so the process is a lot less painful now. To answer the rest of your questions:

How to fix bugs: Ideally, you have some kind of idea where the problem is coming from. If you have an error, you can search for it in the source code, and take a closer look at the code. This might give you an idea what's wrong. That's how I fixed these WiFi disconnection problems. There were weird errors (seemingly unrelated), I searched for them, and eventually found out what was wrong (but only after adding a lot of debug output in the code...)

How to know which files to edit/replace: Usually, I don't! You can narrow it down to a few files that are seemingly related, but then you need to figure out if you a) just need to set a make variable in the BoardConfig.mk of the device, b) eventually need to set a system property (system.prop), c) even need to make actual modifications to the code.

How to update kernel version: Luckily, this is really simple for this device! All I do is apply some Git magic to rebase the patches I have (~ 30 commits or so) to a newer version of the kernel. Then you need to test and hope that everything is still working. That's usually the case for minor kernel updates, but might not be the case for major kernel updates (I haven't done this yet).

I'm afraid I cannot really say how you can learn more, except trying to get more familiar with the code, trying a few simple modifications and seeing what happens. However, I'd happily answer any further questions!