To add, experience is intuition. Let's break it down. Dunning and Kruger have an effect named after them, but really their seminal paper focused on how information is internalized in the mind. It comes down to 4 quadrants:

known   | known
unknown | known
-----------------
unknown | unknown
unknown | unknown

The things you know you know. The things you know you DON'T know. The things you DON'T know that you DO know. And the things you don't know you don't even know.

Intuition moves from a known-known, to an unknown-known. From rote memory to intuitive memory.

The former is inferior - because it's only by active recall. You haven't internalized it. You can't act on it but with an extreme amount of effort and help. Yes, you can recall it, exactly as it was presented to you, but so what?

The latter is when you stop thinking about it. You're just using it. Intuition is informing your decision making and consideration without you having to actively do it - this frees your mind, capacity, and resources, to more immediate tasks and unknowns. But it's there... It's helping you...

The difference between you and me is I've got 37 years of experience. When you watch me work, I make it look easy. I get straight to work with designs and solutions, right to code without having demonstrated any prior consideration for why I'm already doing what I'm doing.

That's because I'm not making decisions - not now; I've already decided. Up to 37 years ago.

This is what you're trying to train your brain to achieve. You're trying to get the known-knowns into known-unknowns. If you recall in earlier education where you're supposed to read a book and write a report "in your own words", what the exercise was trying to do was help you move rote knowledge into intuition. Once it passes that barrier, once you forget the memorization but still retain the knowledge, THEN you can speak the truth in your own words. This is what it is to have expert knowledge - it's breadth, it's depth, AND it's intuition. This is why you can never keep up with a domain expert, because while you're swatting at facts and figures and rote knowledge, they've made neural pathways and inroads and unconscious deep consideration for years and decades on the subject, that they can pull knowledge structures from deep within that expertise that you cannot possibly do yourself, unless you're also a domain expert in specifically that field, too.

We're just trying to get you there. Now time is the almighty critical factor, but exercising these neural pathways is a big component in making that happen, so just keep going. If we could ever figure out a FASTER way of doing it, we'd all be experts sooner, and possibly richer for having discovered such a technique - it'd revolutionize education, but alas, no one actually knows how to make this process go faster. Just be in it. All the time. Saturated, but not, perhaps, to the point of exhaustion though...

My other bit of advice - my philosophy is that I'm not very smart, that 99% of what I want to do has already been done 40-60 years ago. Usually this is true. Very few of us ever invent anything new, most of the job is business logic, which is almost entirely established; you've got industries catering to markets, that means everyone is doing the same basic business practices, I'm just implementing a given business process HERE, as it's never been done before, HERE...

Ok, so typically what I do is a fair amount of googling. Typically, there are libraries and standards that already exist JUST FOR what I want. You need to get good at searching and recognizing when you find it. Sounds like an impossible task, but it really is just another skill. My most common example is logging - everyone writes their own logging code like logging doesn't already exist. The code tends to look like what Eric Allman did for Sendmail in 1983 - the pattern EVERYONE copies. Very poorly. But no one bothers to acknowledge Eric also invented system logging and RFC-5424. Everything you need your logging code to accomplish is in this standard, and anything you do that is less is buggy, incomplete, unstable, ad-hoc, and incompatible with industry standards, which has more damning consequences. Everything everyone does with their own logging is wrong. Drives me FUCKING crazy.

Syslog is slow!

Your ass is slow. If your logging was actually complete, and compatible, it'd be just as fast. Ubuntu uses rsyslog, which is asynchronous and can handle something like ~6m messages a second on this old-ass x86 clone embedded bullshit no-name processor we're looking to replace here - it's plenty fast for your shit.

This leads into my next philosophical point: Presume you're wrong. Stupidly, retardedly wrong.

If your logging is slow - flip the premise and thus the question: logging is fast, so why is my logging slow? Have you ever considered you're logging wrong? Have you ever considered that the way you're doing things, the way you think you want to do things, is the wrong way? Industry wide standards - and it just so happens to be too slow to be usable for ::checks notes:: everyone? And yet all our most foundational and performance critical software - the OS and system, all use it..? I mean, if the OS is slow because of logging, isn't that dragging down your software? So why are you on that platform? Why does the platform even use syslog? Make it make sense...

It took me DECADES to understand C++ and OOP, because I discovered literally ALMOST NO ONE understands it, and those who do are essentially impossible to find. It took decades of learning OOP from ancient whitepapers and seminal works, languages like ALGOL-68 and Smalltalk to understand what it was, learning about Bjarne and his works to understand what the hell he was thinking, what Jerry Schwarz (the forgotten father) was getting at.

Now days my code is what our C++ founders intended, OOP or FP, and it's entirely alien to my colleagues across my career. It's a curse.

So I always recommend people stay curious about software history, because the context gets lost, but understanding it makes technology make sense. So much of our shit is backward compatible with 1850s telegraph equipment on purpose, and maybe if you understood more of that a lot more would make sense about what's going on and why. It'll help you build the future from first principles.

Also what's old is new again. We're always solving for the slowest part of the system. When the next new thing comes out, that part is no longer the slowest. That means the NEXT slowest part is now the slowest, so we're solving for THAT. The old techniques become forgotten as they become abandoned due to the focus on the next new slowest problem. Alright, well give that 10 years, and wouldn't you know it? But what was once the fastest part is NOW THE SLOWEST PART, and how we once solved for that is relevant again! But we've all forgotten, so now we have to rediscover those techniques again. Data Oriented Design used to be called "batch processing". Edge Computing was once called "thin client". What we all know as Docker today is actually built upon namespaces in the Linux kernel which was a concept first invented in the late 1980s with 11th edition Unix aka PLAN 9...

If only we never forgot...