It sounds like you need to learn how to write testable code. For that, I would suggest two books: Working Effectively With Legacy Code and Clean Architecture.

Read Code Complete and Clean Architecture, then start incorporating those tactics and concepts into your own projects.

Yep, read these books and apply the ideas directly to your work as you go: Code Complete (which IMO is more detailed and explanatory than Clean Code) then Clean Architecture.

So, in your opinion are Clean Code and Clean Architecture still relevant/updated?
I've come more interested in the way I think about/produce code in the last couple of months and am searching for something that might be a good read on it - considering I'm mainly a JavaScript developer.
I find that most of the concepts of SOLID, for example, are really hard to figure out in most of the code base of the projects I've worked/see online implemented in Node for example. It might be related to my lack of knowledge and understanding of said principles though, but I've seen a youtube video (https://www.youtube.com/watch?v=CnailTcJV_U) some months ago that showed me a "clean architecture" implementation that I've never really seen in any project I've fiddled with.

I spent some time in Web Apps between video game jobs. I got into some tense conversations where I, as manager, recommended against the abstraction layers the Senior Developer was trying to explain to the team on a whiteboard.

He said something like "Why do all the game developers write code like that?".

He handed me Uncle Bob's Clean Architecture. Uncle Bob is something of a meme to me. I read the book and couldn't figure out how to explain how I thought this style was inferior to what I had done in games before.

Ive been thinking about that ever since it happened. How could I explain to this guy my programming philosophy?

Last night, back in games, after refactoring the same piece of layout code for several hours, I finally arrived at the irreducible, simple, clean result that I wanted. I slotted it into our code base, and mentally noted how I would onboard the team to it on Monday, and how they would instantly understand because the resultant code is so simple. Then it came to me:

"Unit Tests are like pouring concrete on your code base."

Same goes for using "the wrong abstraction". Sometimes you want concrete to encase your precious technology. The problem is when people are writing sub par code, then they pour all this concrete on it via Unit Tests, Inheritance and Abstraction Patterns. It can become harder to improve the core logic of the system if it's distributed across many files, and enshrined in Unit Tests.

I've dedicated over 10 years to coding, and only now do I think I can write clean code that is worth encasing in concrete. I think there might be a general flaw in the idea that everyone should be writing tests. I'm not certain about this, it's just my general intuition based on my experience.

They are pros and cons to every design decision. I acknowledge that they are many pros to these kinds of designs, I'm just enumerating some cons that have arisen from my experience.