Felt the same even though I'm just 3 years into professional software development.
I found that the most comfortable place to look at software development is at the architecture level and I suggest you try too.
You'll be able to see the roles of each component in a system. It's magnificent.
Tips:
1. In the end, you'll only need to know the fundamentals
2. Docker builder pattern really helps with the build scripts thingy if you're developing a web app, either for the frontend and backend side. It really helps with fragility because fragility is often caused by leftover states and Docker container really helps you with that.
3. Rewrite instead of reuse parts that are not essentials / easily breaks. Pass-by-value and copy-paste was invented for something ;D
4. If you're using javascript, consider using TypeScript. It saves you a lot of time debugging for type-related bugs.
5. For browser/browser-like apps, use declarative language frontend libraries such as React, but don't rely much on other libs that come with React's popularity (such as redux, react-bootstrap, etc). They usually don't help as much and could be a hindrance in the future. All you need to understand are the fundamentals: html, css, and javascript.
6. For backends, don't feel forced to follow some architecture pattern such as (MVC, MVVM, etc). They often only apply well on certain tech-stacks, but not the other (e.g. expressjs is more popular than the MVC oriented sails.js, actor system is more comfortable in elm than redux due to the former having static typing). It'll help with flexibility later on.
7. Optimize the most valuable and reused component of the software/system. Over DRYing could lead you into premature optimization/abstraction where it would lead to unnecessary complexity.
8. If possible, only make assumptions if it is commonly done or it is guaranteed to not change frequently in the future. Otherwise, do not reuse. This is where YAGNI applies.
9. Don't feel rushed by the overwhelming amount of new frameworks, those things rarely survive. Choose the most flexible, helpful, and do the least (and most starred). Resist hype-based development because new programmers tend to be excited to learn new things and will inadvertently put what's new in the stack because it is cool.
10. Make it a constant if it can. Give it default if it cannot. If there's no possible default, don't run if not provided, write documentation for it. Do the same when running something. It'll reduce the amount of config in your codebase from now on.
Optimize at the architecture level, because you'll find the moving cogs over there are the most valuable for the business. Do touch the codebase at the lower level to understand what problem resides there.
Any framework you choose doesn't matter much as long as it fulfills the purpose of that very component.
You'll find that some tools and frameworks are better than the other for a particular problem, but usually, the choice of tech stack matters more despite the framework. And the choice of structure, contract, and architecture is the real deal, applicable everywhere.
Example: React feels better than Angular in electron. Nevertheless, electron app done right is almost always slower than native apps done right (not hating electron, I code electron almost every day in 2018). But ultimately you'll need to have a desktop app over publishing game in only-browsers, if you've got to run a game publishing and download management business because requirements and other things.
After a while, you'll realize that the technical decisions that matter the most are which you have to balance between development speed/productivity, performance, and maintainability. To me, it sounds like a pretty decent challenge, and I'm sure it does to you too.
If you're dealing with multi-layered architecture that needs maintaining, press your team or yourself to make each layer as simple as possible, do one thing and do it well, this also applies for frontend apps. Sometimes it takes more line of codes to do less, but it'll be worth it.
These have made my life easier and I hope they help you love programming more too.
(I love programming too, Game programming, Functional Programming, Fullstack, TypeScript, Rust, JavaScript)
I found that the most comfortable place to look at software development is at the architecture level and I suggest you try too.
You'll be able to see the roles of each component in a system. It's magnificent.
Tips:
1. In the end, you'll only need to know the fundamentals
2. Docker builder pattern really helps with the build scripts thingy if you're developing a web app, either for the frontend and backend side. It really helps with fragility because fragility is often caused by leftover states and Docker container really helps you with that.
3. Rewrite instead of reuse parts that are not essentials / easily breaks. Pass-by-value and copy-paste was invented for something ;D
4. If you're using javascript, consider using TypeScript. It saves you a lot of time debugging for type-related bugs.
5. For browser/browser-like apps, use declarative language frontend libraries such as React, but don't rely much on other libs that come with React's popularity (such as redux, react-bootstrap, etc). They usually don't help as much and could be a hindrance in the future. All you need to understand are the fundamentals: html, css, and javascript.
6. For backends, don't feel forced to follow some architecture pattern such as (MVC, MVVM, etc). They often only apply well on certain tech-stacks, but not the other (e.g. expressjs is more popular than the MVC oriented sails.js, actor system is more comfortable in elm than redux due to the former having static typing). It'll help with flexibility later on.
7. Optimize the most valuable and reused component of the software/system. Over DRYing could lead you into premature optimization/abstraction where it would lead to unnecessary complexity.
8. If possible, only make assumptions if it is commonly done or it is guaranteed to not change frequently in the future. Otherwise, do not reuse. This is where YAGNI applies.
9. Don't feel rushed by the overwhelming amount of new frameworks, those things rarely survive. Choose the most flexible, helpful, and do the least (and most starred). Resist hype-based development because new programmers tend to be excited to learn new things and will inadvertently put what's new in the stack because it is cool.
10. Make it a constant if it can. Give it default if it cannot. If there's no possible default, don't run if not provided, write documentation for it. Do the same when running something. It'll reduce the amount of config in your codebase from now on.
Optimize at the architecture level, because you'll find the moving cogs over there are the most valuable for the business. Do touch the codebase at the lower level to understand what problem resides there.
Any framework you choose doesn't matter much as long as it fulfills the purpose of that very component.
You'll find that some tools and frameworks are better than the other for a particular problem, but usually, the choice of tech stack matters more despite the framework. And the choice of structure, contract, and architecture is the real deal, applicable everywhere.
Example: React feels better than Angular in electron. Nevertheless, electron app done right is almost always slower than native apps done right (not hating electron, I code electron almost every day in 2018). But ultimately you'll need to have a desktop app over publishing game in only-browsers, if you've got to run a game publishing and download management business because requirements and other things.
After a while, you'll realize that the technical decisions that matter the most are which you have to balance between development speed/productivity, performance, and maintainability. To me, it sounds like a pretty decent challenge, and I'm sure it does to you too.
If you're dealing with multi-layered architecture that needs maintaining, press your team or yourself to make each layer as simple as possible, do one thing and do it well, this also applies for frontend apps. Sometimes it takes more line of codes to do less, but it'll be worth it.
These have made my life easier and I hope they help you love programming more too.
(I love programming too, Game programming, Functional Programming, Fullstack, TypeScript, Rust, JavaScript)