Everyone works differently but I can tell you that any game that I have actually finished has started with a design. The design does not need to be incredibly detailed, but you need something that outlines what you are building and provides a structure so that you can begin the coding process.
You would not start randomly building a house without at least some form of a plan. You might not have every square inch designed, but I think you would at least know how many square feet you wanted it to be, what you were using for the foundation, where your going to put the bathroom, ect.
Create a basic plan and use that plan to dictate how you develop the structure of your game. For a beginner there is usually no "right" answer. Yes it is highly likely that your code will turn to spaghetti and that you will say years down the road "I really wish I had done THIS!" but at that point you will know how to structure your next project (and you can then make a whole new round of mistakes!).
Some guidelines that I can think of off the top of my head:
1. Make an attempt to separate your game's data from the game logic. You mention XML/JSON and this is a good idea.
2. Favor composition over inheritance. Deep class hierarchies can make for deep headaches. Having to duplicate code from one class to another because you have forks in your inheritance tree but can't afford to put stuff in base classes can make for some ugly code.
3. Avoid making kitchen sink classes. Classes in general should accomplish only one "thing". In real life I have broken this rule more times then I can count, but don't go out of your way to write bad code (trust me, it will happen naturally).
4. If you find your methods becoming hundreds of lines of code, chances are you should refactor into smaller methods.
5. Avoid threads unless absolutely unavoidable. Threads add lots of complication and make problems harder to debug and solve. There are some situations where threads can be a good idea, but don't go overboard and use them very sparingly.
6. Finite state machines can help you implement your NPCs.
7. Scripting may be helpful for quests.
8. COMMENT YOUR CODE. You will look back on code months after you write it and have absolutely no clue why you wrote code a particular way. Future you will likely look and not understand why it was written a certain way. Usually I find that code is fairly readable on its merits, but the motivation BEHIND the code is what I need comments for. I might not know why I decided to use a particular approach if I don't have a comment to remind me why another approach wouldn't work or why the code looks hacky because there is a some reason for it.
9. If possible unit tests are a good way to ensure that your code is working appropriately. I must admit that my old games did not do unit tests, but the latest software design practices have been touting the advantages of unit testing code to find defects. It can be helpful to have some form of verification that your objects are doing what you expect them to be doing and it can help to verify that a change that you have made did not break the entire world. Java has JUnit for example.
Mainly you write code, refactor code, write more code, refactor more code, and repeat until your fingers are numb and your eyes bleed. When you run out of patience, money, time, or publishers are threatening to murder you if you do not release by the end of the week then you will be "done".