So far my limited experience with adding support for a radio (the 2730A is my first) is that it doesn't need any knowledge of C (the chirp library itself is python). A basic familiarity with memory (bytes, ascii, binary formats for numbers, etc), arrays, python and being comfortable digging into hex dumps is important, though. Depending on how similar to the existing drivers your radios are, this may or may not be easy or hard. For example, most Icom drivers have similar layouts and routines, but then the 2730A turns out to do things a bit differently, so that took some staring at hex dumps and scratching my head and debugging a bit to figure out what was different. Another recent example of a difficult driver was
https://chirp.danplanet.com/projects/chirp/repository/revisions/e96b1bfcc450 where the developer reverse engineered an obfuscation routine of the memory.
If you have a radio that is supported with Chirp, an interesting exercise might be to try to use that one and reverse engineer it. Delete the existing driver file, and repeat the procedure. You have the existing driver file as a "cheat" to compare against when you get stuck.
As for dangers to your hardware, probably not much. I've tried writing a few times to the 2730A as I'm debugging, and the only thing that has happened so far is the radio beeps, displays CLONE ERROR and I have to power cycle it, after which the memory is reset. That is using the wrong protocol, though, and not writing bad data using the right protocol, so I'm not sure what happens there yet. I would imagine it might just display an error or reset itself if there's bad or corrupt data. You are unlikely to be able to actually harm it, but, of course, that's not a guarantee.