Completely agreed on the "slow down and really read" part.
Googling for immediate answers on Stack Overflow is not reading and doesn't lead to understanding. It's "fast food calories" for your mind, and if one solves every problem that way, it's like eating at McDonalds for every meal.
Googling for immediate answers on Stack Overflow definitely leads to understanding in my case. The trick is to not just immediately paste the code, but to dig into it and understand why that specific set of instructions is the solution. A bit of reverse engineering if you will. It tends to be faster than reading through all the docs (which contain too much info about things you won't need right now) and inventing the wheel yourself.
I don't know why you're being downvoted, this is a good insight. Particularly in the Java Enterprise world, the documentation can be very wordy, and of the form 'indoctrinate you into this way of thinking'. A barebones example from someone who knows the framework can be much more illuminating than pages of prose.
My dad does competition shooting. The format is that you can as many rounds as you want to hit 5 targets. So you can shoot off a lot of rounds. But the key insight is: "You can't miss a shot fast enough to justify not aiming."
A quote I've always liked that echos a lot of your message: "Go slow to go fast". I can't remember where I heard it first, but I think it's great advice.
That's exactly what I do everytime I buy a new iPhone! I pause for an hour and read the documentation before jumping right into it!
Wait a minute... does it come with a docunentation? Hell no - like any other piece of code you come across at work. Who writes documentations anymore???
But how do you deal with politics? Ambitious or egotistical or just assholes like to take advantage of slow people, right? I tend to get paranoid that these people will appear when I'm taking mine time to understand.
I say it jokingly but early on -- I gained quite a reputation among people far smarter than I am, for being able to solve the most difficult problems.
But I never really did anything other than read. And most of the time I never had to go beyond the documentation.
The trick I guess, is to slow down and really read. There is no shortcut to understanding. And there is no solution without understanding.