Letting the player create things is pretty easy (once you've practiced coding menus a bit), the hard part is to save the work for later in a way that works with game updates, is efficient, and will only capture the changes you want to save. If you let the player destroy things as well as create them (e.g. mining blocks for resources) you really should take the time to think through your system before you start coding, so you don't end up with stuff like savefiles containing every block in the entire world (gets kinda slow to save and load...), procedurally generated structures suddenly materializing inside the player's base when you come back after a long journey, or the world permanently running out of enemies because you added them to the list of things the game remembers being destroyed.
It does not save every block that exists, but rather the blocks that changed.
When you are playing, and you place a block, it will:
Add the current chunk to a list of changed chunks
Add the changed block to a list under the chunk list
It looks at the list of changed chunks and saves all the changed blocks in that list
When it is generating a chunk, it will:
Generate the chunk
Check if the chunk has been modified
If it was, it updates all the changed blocks in the chunk.
I made up most of this, so I hope that makes sense...
Binary files let you edit random bytes in the middle, so if you want to save all data and still have things be responsive when the player does stuff, this could be one way: when you first generate the world you save X chunks around the spawn position, and whenever a new chunk is loaded, you generate a new file for its data; any changes after that just writes 1 block in the file, not the entire thing.
Would work even better in an engine with multithreading, since you could do the slow file operations (and RNGing new data, for that matter) in the background, but ah well.