I see some serious issues with this question. Let's start.
How to stop wasting time designing architechture
This question is rather loaded. Also, you don't design architecture. You architect. Architecture and design are complementary and related activities, but are not the same, even if they might overlap.
Similarly, in the same way it is possible to waste time doing architecture (by over-architecting), you can also waste time over-designing and over-coding (by coding stuff in a manner far more complex than necessary, or by failing to code for the things that are required.)
Proper architecture aims to prevent that waste in coding. It does so by limiting, narrowing and documenting the possible ways a complex system is to be 1) designed, 2) coded and test it, 3) delivered, 4) maintained, 5) recover from failure, and 6) ultimately decommissioned.
My experience has been that people who just enjoy coding, they just code without any thought of how a system is to operate and maintained on the long run, moving to the next hot potato leaving some poor soul to maintain an ugly golem.
But I digress...
This is the thing: For systems simple enough, architecture is self-evident and emanates from sound design and implementation practices.
It is only for large systems that involves a rather large number of people or system-level software that does very complex stuff that require explicit architecture.
I have recently graduated from uni and started working as a
programmer. I don't find it that hard to solve "technical" issues or
do debugging, things that I would say have 1 solution.
That is the minimum required for this profession, and I'm glad you have no problem doing them (I'd be worried if you did.)
But there seems to be a class of problems that don't have one solution
Those are the bread and butter of our profession, the type of problems for which employers are willing to pay our (typically) far-above-average salaries.
As a matter of fact, problems worth solving are those that can have more than one solution. Real world problems, they are like that. And the world require our expertise, as software developers, to come up with acceptable trade-offs.
-- things like software architecture.
The architecture of things is an inevitable characteristic of complex system, be them virtual/software or in the concrete world. Every system that operates, that takes input and produces output, it will be complex and will have an architecture.
When we develop software for such systems (a banking system, a power monitoring system, a ticket sales system, etc), we aim to produce a piece of software that mimics the functions and requirements of such a system.
We just cannot simply wing it and code it cowboy style. We need some sort of architecture. This is particularly true if the project requires dozens of engineers, if not more.
These things befuddle me and cause me great distress.
That is ok. It is not an easy subject to learn or teach, not without a lot of practice.
I spend hours and hours trying to decide how to "architect" my
programs and systems. For example, do I split this logic up into 1 or
2 classes, how do I name the classes, should I make this private or
public, etc. These kinds of questions take up so much of my time, and
it greatly frustrates me. I just want to create the program, the
architecture be damned.
Unfortunately, that's not software architecture.
It's not even design, but just coding. I'll provide some suggestions at the bottom of this post.
How can I more quickly get through the architecture phase and onto the
coding and debugging phase, which I enjoy?
I'm having a hard time finding a way to answer this, for it is rather emotional.
Are we trying to get a job done, or are we trying just to enjoy the practice? It is great when both are one and the same, but in real life, many times they aren't.
It's great to do things we enjoy, but in a profession as complex such as ours, to focus just on what we enjoy, that's not conductive to have a fruitful career.
You won't progress, you won't mature or acquire new knowledge.
There's this saying in the Army, "embrace the suck."
Others phrases have similar advise. "If it doesn't suck, it's not worth it" and my favorite, "If it sucks (and it is important), do it until it stops sucking."
It seems to me that you are still struggling to understand the differences between
coding (how to code your classes, modules or what not, naming conventions, access visibility, scope, etc),
design (how many tiers, front-end/back-end/db, how each communicates, what goes where) and the implicit architecture decisions that comes from the design of simple systems,
architecture (as found in complex systems requiring thousands, if not hundreds of thousands of man-hours.)
So I would suggest you delve deeply into the first subject (coding) to take it to the next level.
Robert "Uncle Bob" Martin's "Clean Code" is a good place to start.
Additionally, I'd suggest you get familiar with a specific Object-Oriented software metric called LCOM or rather LCOM4.
It can get rather mathematical and it's not bullet-proof, but your goal should be to empirically understand and detect (or eye-ball if you wish) if a class is cohesive or if it lacks cohesion.
This goes closely related with the "Single Responsibility Principle" or SRY that we should all be familiar with. SRY is one of the 5 "SOLID" that we all need to be familiar with if we are to become proficient at coding.
As we move through SOLID principles, we also need to familiarize ourselves with "GRASP" principles, which govern, or rather guide how we code classes.
Lastly, I'd also suggest the following:
"Refactoring" by Martin Fowler and Ken Beck would be the next
book I'd read in this list.
"Design by Contract, by Example" by Richard Mitchell, Jim McKim
and Bertrand Meyer (the later of Eiffel's fame.) This book is out of
print, but you can find cheap, used copies in Amazon.
With this, you should get a good grasp of how to start coding and design, and with practice, to move and master (or at least grasp) software architecture.
I'm sure there will be other professionals who will add, subtract or object to these suggestions. They'll come up with other suggestions, likely validated by their own experience.
All I can say is this - there are no shortcuts.
All the best.