As I said on previous occasions, writing software is craftsmanship. When you watch a good craftsman, you can learn a lot of the principles that apply here, too.
When you have to write a piece of software from scratch, the first thing to do is a good understanding of the desired solution. This starts with collecting requirements. The initial collection doesn't have to be complete (that's one advantage of writing software, you can change things later, in difference to crafts that deal with physical materials), but the more you can get, the better.
Then order these requirements on whatever structure seems the most appropriate. One good approach is to write user stories. Each story describes, from the perspective of a user (this can be a person or another piece of software) what your software needs to do when certain input and stimulation (e.g. key presses or mouse events) are provided. Now group your user stories.
Eventually a clearer picture will emerge as to what this piece of software needs to look like.
Once you have a fair collection of these stories (e.g. 2-3 months worth of work, but this can vary a lot), pick a few related ones, which are relatively simple to implement, and start writing code. Write unit tests for your code, where each test covers a particular aspect of that story. These tests must cover the expected outcome as well as any error handling. Refactor your code after each unit test, to ensure it is as clean as possible (read this book about clean code and this book about refactoring). Then move on to the next story.
There will be times when you need to do some major refactoring, because the structures and designs chosen initially are not adequate any longer. Don't be afraid of this, the unit tests will help you to make sure that all your requirements are still met.
Over time, architecture will emerge. As you get better (with lots of practice) you will learn to avoid some common pits from the start and you will get faster. While you carry on implementing user stories, also carry on collecting new ones. Always keep the list of stories prioritized (ask the users what are the most important stories to implement next). When writing user stories, just put enough detail in the story to understand what it is about. The fine detail should be decided at the very last moment, i.e. at the point of implementation. Make sure you have access to the users to ask them questions.
Soon you will come to realize that there are certain things that you need again and again. These are called patterns. There are numerous books on software patterns available. The two best ones I have read (and I haven't read all of them) are the original GoF book and this one. Good luck.