Hex editing is not a thing, a skill, or ability beyond the obvious "hex is 0 through F, type it like you would in a word processor but using that instead" and less obvious "hex editors tend to be split into three sections -- left typically is the location in the file/memory/hard drive, middle is the data represented as hex, and right is typically some kind of text decode that can be customised to be a different encoding or a custom one in some cases as you desire). The word processor analogy also often holds quite well -- hex editors tend to feature niceties like overwrite/insert, go to location, simple common operations (I would say most boolean and bitwise operations are much like "make bold" or change case in a word processor).
Skilled ROM hackers might use a hex editor as a least worst option to make a small change, or initially analyse a file to see if it looks similar to things they have seen before*, has certain tells**, has patterns worth exploring or similar. They might also realise a change could be in any number of places but is in a fixed location relative to something easy to find, or if there is a wide selection of options might direct a user to make a change with one rather than making however many thousands of patches that the combinations of such changes might make (think put this number in here to make the pokemon of your choice appear, and put this other number to put this in your inventory -- if there are 500 pokemon and 500 items that is 250000 total combinations before you even consider someone might only want 1 potion rather than a full stack, far easier to say "this location and this number from this list, and this location and this list has numbers"). As the hex quite literally represents the contents of the file then hackers might share dumps and screenshots for other hackers to contemplate but they know the other hacker will be able to filter out the useless information.
*this does include visually. I could look to see if what I think could be a section of pointers makes sense given the rest of the file (assume pointers for text are at the end of lines/sections and comparing section count with possible pointer width) but if I change the window width/section width and suddenly end up with a line of 0000s going down the screen or a diagonal line/repeating pattern on diagonals then I am probably onto something.
**I know if a DS file starts with 10, 11 or 40 then I should look into whether it is compressed, can also compress the file (compressed files don't compress much, uncompressed files might well do), I also know many DS files start with "magic stamps" as well as the extensions the files will tend to have, I know GBA pointers tend to have 08 as the first number as that is where most GBA games see the ROM in memory but also know where that fails, I know the DS is fairly weak as these things go so tends to have certain formats, know what the shiftJIS encoding (
http://rikai.com/library/kanjitables/kanji_codes.sjis.shtml ) range is, know what text generally looks like (how many sentences have words with more than about 8 characters between a space, most languages don't routinely use thousands of radically different characters), know what compression looks like (in text it typically makes things start normally but then go to gibberish if it is a sliding window compressions
https://ece.uwaterloo.ca/~ece611/LempelZiv.pdf or randomly miss bits if it is huffman or some substitution/lookup approach). This on top of things I might have done elsewhere to give me an idea of what I might be looking at (if I have already found at least what I presume is music, levels, graphics, code and video then I know to adjust my sights to find text type patterns).
Perhaps another analogy. I have a nice collection of hammers. Give me a bit of sheet metal, something to bash it against and a hammer and I can make whatever you like. Someone that has a sheet metal bender will likely make a far nicer finish bend in a fraction of the time though. There are dozens of other tools to manipulate sheet metal as well and they all do far more, far more precisely and far more quickly but rarely as versatile as hammer and infinite time. The hex editor is the hammer in this scenario -- very crude but in some ways less limiting than tools designed for specific common scenarios.
What you then want to learn is ROM hacking, how files tend to get made by programmers in general and for the system you are looking at (you are probably not going to find yourself editing some kind of standalone nosql database for a NES game, might do for a modern MMORPG though).
We have guides to ROM hacking
https://gbatemp.net/threads/gbatemp-rom-hacking-documentation-project-new-2016-edition-out.73394/
http://www.romhacking.net/start/
http://wiki.xentax.com/index.php/Game_File_Format_Central is not really ROM hacking but one of many examples of a library of game formats you can get some idea of things previously seen for.
Short version. There is no hacking skill or programming skill that hackers would call hex editing. Much like being able to make a word processor absolutely sing does not mean you can inherently write a novel with nice characters, plot and pacing then a hex editor is to hacking what the word processor is to novel writing. In this case it sounds like you want to learn ROM hacking.
