So, this may sound like a weird response, but:
- What language are you writing in?
- What sort of projet are you working on? (A scratch-your-own itch project? Contributing to something Open Source? Something to eventually make money off of? A game?)
- How much autonomy do you have over this project?
- What kind of libraries are you using?
I write Java for a paycheck and have been doing so continuously for the last... 12 or 13 years or so?
And, of course, the idiomatic way to do Java is to write your code atop a precipice of abstractions. A simple HTTP server library wasn't good enough, so they built Servlets. Servlets weren't good enough so they built Spring on top of Servlets. Spring wasn't good enough, so they heaped Spring Boot on top. I can't wait to see what they come up with next.
And these abstractions make everything so easy right? You just throw a little annotation here and it does all the magic behind-the-scenes and you don't have to think about it! ...until the moment something goes wrong. And if there's one thing that you can depend on going wrong, it's Spring/Spring-Boot stuff.
One thing you mentioned specifically was a lot of "Googling." And that's very reminiscent of a phenomenon I've seen repeatedly. All the Java people say you should be using Spring Boot because it makes things so easy, but the moment you actually go and try to use Spring Boot to do anything serious, you run into obstacles.
Not only does this lead to googling hell, but developers (particularly junior developers) tend to internalize that. "If I'm doing what folks are telling me will make things easier, but it's not working for me, then I must just not be a good programmer." But the truth of the matter is that these libraries often don't work as advertised. And nobody really knows how Spring Boot, so the top dozen answers about the problem on Stackoverflow are just straight up wrong. And so you throw shit at the wall until something eventually sticks, because you're not one of the Spring Boot core developers and you don't really want to delve into that madness. In short, the reason why it isn't working is Spring Boot's fault, not the developer's. (And I'm picking on Spring Boot in particular here, but it's far from the only good example.)
My team sees me as a "senior developer." The kind of developer to turn to after googling hell has lasted so long you've run out of leads. What that really means is that I'd rather spend hours delving into Spring/Spring-Boot source code than try to sift through a million wrong answers to find a code snippet to copy-paste in and hope it will work without having any understanding why it might work.
So, my recommendation to you is to stop using dependencies to the extent you can. Use what's in your language's standard library to the extent you can. Don't be so phobic to reinvent the wheel (and if you're phobic about reinventing the wheel, blame the propaganda you've been fed, not yourself!) that you pull in something that'll quadruple your project's and cognitive load. When you do need to use dependencies, use the most minimal ones you can. Also, don't be afraid to go "lower-level" with things. And never use any "frameworks" that try to do lots of unrelated things over libraries that implement a single narrow use case. And never use libraries whose only reason for existing is to "magically make things easier."
When you do things that way, you're just... writing code. Nothing's ever broken or misconfigured in a way that causes things not to work because... there's nothing there to be broken or misconfigured. There's fewer moving parts to contend with, so writing code is just... writing code. As fast as it pours out of your head and through your fingers into your text editor. (Oh, speaking of which IDE's are the devil too. They just muddle things. "Is it the build system that's broken, or is my IDE just giving me red squigglies because it's misconfigured?" Fuck that shit. Just run a build and if it says things are broken, then you don't have to choose between two different sources of truth to determine the state of the codebase.)
If you want to see some examples of what the results look like, a couple of projects I've written that are decent examples of this dependencies-avoidance approach are:
- GoVTT - A web-based "virtual tabletop" for playing tabletop roleplaying games remotely. 13,000 lines of Go and JS code. Exactly three dependencies: a Sqlite3 client library, an HTML/CSS/JS minifier library, a transitive dependency pulled in by the minifier library. (Zero JS dependencies.)
- CodeComic - A domain-specific language for making web comics. 4,000 lines of Go. Three dependencies: two having to do with image generation/processing and a transitive one having to do with font rendering.
- Hydrogen Proxy - I haven't touched this one in a good while, but it's a scriptable HTTP proxy. 7,000 lines of Python. Three dependencies: an SSL library, a standalone templating engine, and a library that implements the Socks protocol that I also wrote myself.
Other things to look into:
- suckless.org - These folks know how to minimalism in programming. The coding philosophy of these folks is elegant and beautiful.
- cat-v.org - The person who wrote this site was heavily involved with suckless.org before his tragic passing, so largely it'll be more of the same, but much more humorous and enjoyable to read.
- Rob Pike's Mastodon account - Rob Pike's awesome. Top architect of of the Go programming language. Has unusually level-headed views on coding.
If you don't have enough autonomy over the project to make decisions about what libraries are used, spend less time googling and more time learning the internals of the dependency by pouring through the source code (or, if it's not Open Source, official low-level developer documentation -- JavaDocs or whatever) of the dependency that isn't behaving as it should. It's fine to spend a little bit of time searching Stackoverflow when you run into an issue, but set yourself a timebox after which you'll switch to source code and shut out the cacophany of wrong answers that Google is providing.
Good luck, and happy hacking!