Loading/Saving is highly dependent on what language you are using, what engine you are using, and what decisions about how you've decided to make it work. Will discuss high level stuff.
First one, and the one Cain likes using a lot, is save anywhere at anytime. Hardest ones to write, you have to save the state of many, many things. Sometime it's hard to get the things you need to save, if you can save anywhere, can you save when a character is in the middle of an animation? If they're falling, if they are casting as spell (Animation, particle effect, AI reacting) that is a lot of things to save the state of. You may not have written everything that is coded, if you brought in a third party physics engine, you need to know how to ask that physics engine the state and locations of objects so they can be recreated. Some of them don't provide that, so depending on choices that have nothing to do with saving/loading, you will be restricted on what save/load systems you can implement.
Probably a more common save/load system will be you can save somewhere at some times but not everywhere. For example, save when game is not in combat. That avoids a lot of save variables that only have to do with combat, especially AI (Can ignore moment to moment AI in favor of high level stuff.) Also seen games that only let you save when back in town, which presupposes you're not in combat and in an area without many state changes, especially if there are essential NPCs or you simply are not allowed to fight in towns. Some games only let you save at rest, a very restrictive way, but it guarantees you won't be casting a spell, be in the middle of a dialogue, nobody is falling, it allows you to avoid a lot of things to save down, many systems will never have to consider saving/loading under that system.
Some other system has has seen, very common in consoles, are checkpoints. Game automatically saves at certain point. Checkpoints are very easy because you are defining when and where states can even happen. More modules will never have to worry about saving and loading when you know it's only being saved at this particular variable. Not every story variable needs to be remembered, just which ones carry over into the next act and ending sides, all others get thrown out.
Some games also have an autosave system, the game may have save anywhere or save in certain areas, but an autosave is an addition. Autosaves are kind of like checkpoints in the sense not that much needs to be saved, but they are more of a way to making sure the player doesn't end up in a bad state if they die or the map transition goes bad. Related to autosaves are quicksaves. Quicksaves are when the player hits a button to save and the game allows him to (Can have quicksave systems in games where you can't save anywhere), allows the player to make a save without going through UI.
UI choices are the next stage for save systems. How many slots can you have, is it infinite until you run out of space, or is there a hard limit? Can vary with each kind of save, the player can have as many manual saves as they like, but quicksaves/autosaves are limited to a rotating set of 3. Some games do that, they kind of have to because without a UI the quicksave has to know where to save. Do you get to put a name to your save? Some games do auto generated save game names, map location/sublocation + date stamp. For autosaves and quicksaves that don't bring up a UI, you have to do that, so some people decide to just keep the manual saves consistent with autosave/quicksave and keep the same naming scheme.
Finally, does your save game have an image associated with it? Didn't use to do that because it was expensive space wise, the screenshot would be larger than the save system. Nowadays not a problem, image makes it easy to figure out which save game is which.
As for the save and load code itself, Cain won't show you how to serialize, will tell you what he does and what decisions you have to make yourself. For every module/class in C/C++, Cain would write a save module that knows how to write that particular class/module's (will only say class from this point forward) data. What tends to happen is that it's past a file pointer, and if you save, you write out your data at that file pointer and return. If you're loading, you load in that data from the file pointer. Some things you have to check is if the file pointer is in the right spot. If yes, you can do this and it's pretty fast. It requires you to follow a very specific rule of making sure it's at the right spot and it remains there. Nobody else besides you may know where that spot is. Will lead to failure if not properly done, hard to debug. If you decide to have each method reposition the pointer, that problem is solved, and it makes it easy to write in new sections. You put in that data, and it finds it's correction section when it is past the file pointer. This is always slower than just assuming where the file pointer is, you are calling out to your save device of choice and having it search through your data and move that file pointer. Maybe your save system is so fast this isn't a problem, but Cain has worked on games where this method has slowed it down a lot.
Next question is do you save the data as raw data. If you have an INT, do you just fwrite the four bytes in it and then fread in that INT from your load/save. Saving it in raw data is very fast and gets you the smallest file size you can get. But you need to learn how to serialize everything by hand. You will have to serialzie your base data, but figure out how to handle pointers, if you have pointers to items, you have to save those items and then reconstruct that array of pointers during load. This is memory allocation, settings pointers, lots of work, but gets you fast saving with small file size. Maybe you don't want to do that, something like JSON (String based object saving) got pretty popular. It is very easy to code for, you can read in your variables just from their names. Your save game will be very big, and very slow. If size/speed aren't a concern, this works, otherwise you have a problem.
This also impacts how you do versioning. If you have save games from previous versions of games, can the 1.1 read 1.0 saves? If you have a save with DLC installed and you uninstall the DLC, can the game still read the save? If you support modding, if you play a modded game can the base game load it? If you play a modded game does it know what the mods are, will it know if you try to load a save with a mod removed? Some games just fail, some games can't detect it and just load the base game version, lots of decisions on how to make. If you went with JSON, this is very easy as if you get to a section you don't know you can have a default. Can't read an item, have it default to not knowing. Can be done with raw data, but harder.
Also need to keep in mind patching, if 1.1 generates a save game 1.0 can't read, you need to decide if that is something you can see in the UI, this is a save game for 1.0. How does it display it? Does it just fail on load, does it warn you it can't load and tell you what to do, does it just grey out the save? It can get complicated and Cain has not mentioned a line of code.
TL;DR : What kind of save game system you want to support, what UI choices you need to make, and how you want that code to work with data, raw or serialized? Good luck, complicated thing to do.
