Vrftsjtryk

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. But there seems to be a class of problems that don't have one solution -- things like software architecture. These things befuddle me and cause me great distress.

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 dammed.

How can I more quickly get through the architecture phase and onto the coding and debugging phase, which I enjoy?

Perfect is the enemy of good.

That said, you should not cut corners. Software design will have longer lasting impact, and save you (and your peers) tons of time and effort in the future. It will take longer to get right. Most of the time spent programming isn't hammering on a keyboard, but by a whiteboard figuring out how to solve a problem.

But you also shouldn't worry about perfection. If two designs fight to a stalemate, it means they're likely about the same goodness. Just go with one. It's not as though you can't change things once you figure out the flaws in that design.

(And hopefully it will also help out once you find out that there's not just one way to debug/solve technical issues.)

What you can do is start with the minimal number of abstractions that you need. For example, a Person class in one file. Now as you keep on adding code and features, you start seeing things that need to be moved to a different abstraction. For example the single responsibility principle(S of SOLID) tells you to not have methods related to address parsing in the Person class. So you now know that you need an Address class.

But it is always good to take some time to think about what "minimal number of abstractions" looks like for your system. Start from a good enough architecture and improve it as you go.

For simple and small programs (e.g. with less than ten thousands lines of source code), you can architecture them while writing the code. You should adopt an iterative and incremental development approach and you'll make progressively architectural decisions while writing your code: so write a few dozen lines of code (adding some single micro feature), improve them to get no warnings from your compiler, test that in your debugger, and repeat.

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

They should not. And they don't matter that much for a small program. You just need to be consistent. And you really need, from time to time, to refactor slightly some small parts of your program (and that is not a big deal).

Look into most free software programs (even big ones like the Linux kernel). They have not being "architectured" during a long time at the beginning. UML is almost never used in free software. And you'll learn a big lot by studying the source code of several free software projects.

As a newbie, either you are working in a large software project, and then you need to trust the senior developer (who makes architectural decisions), or you work on small projects (typically, less than a few dozen thousands of source code). In the later case, you'll make incremental architectural decisions, refactor your application from time to time, so the "architectural design" will come naturally.