"Is it normal practice to consult php.net and google like mad when developing?"
If by php.net you mean the language manual, then yes. You will consult the language manual less and less, but you will always have new libraries to pick up, not to mention platform documentation.
Eventually you will know so many different things that you will seek to learn how a given system differs from another system you already know. You will end up getting a book on a new technology you have never used and jump straight to chapter 5, for example, or flip to the appendices, or read the dense 50 page spec over a cup of coffee. Sometimes, specially for protocol wrappers, you might skip the whole manual and retain the help of a disassembler of a packet sniffer. Sometimes you will start attacking a given implementation from its weak entry points: first the test cases, to see how something is used; then the header files, etc. You can skip on a whole new fangled thing by reading the BUGS and TODO files, if they exist (be weary of their absence more than their presence.) You will get an eye for the brittle by skimming the source and see how the developers implemented a few standard things. I have dumped way too many weak C system applications by just looking at how the developers implemented command-line parsing, for example. This will help you narrow down what you actually need to use, and from there you can choose the easiest one to learn of the few good remaining options (at some point you will learn to isolate library use-points by wrapping calls to other people's code in functions/modules, so you can replace them in one tidy place.)
At some point, also, you will end up googling for error messages more than actual tutorial help. This is specially true if you're interfacing with infrastructure software like an RDBMS or system libraries.
It always takes long to write the first solution, but as you write many different kinds of software, you will develop a portfolio of useful solutions you can apply in other works. Projects that are written fast are also the ones that don't teach you anything; it's not flattering to have churned out something quickly, it just means you're not pushing yourself (which shouldn't be a goal in and of itself, btw.)
Don't worry about the speed of development and just try to write small, fun programs that solve your immediate needs (if no need is apparent, then brag points; nothing motivates like the kudos of your peers. Ok, maybe cash, a red Ferrari and a night at the Vegas strip ;-)
At some point, also try to broaden your horizons. PHP is not exactly a fun thing to work with.
The fastest way for me to code is to unplug from the internet completely. Get all your necessary documentation available in offline documents so that when you code, you don't get distracted by Hacker News :-).
Plus, your memory tends to improve since you'll actually be able to figure stuff out on your own than googling every little thing.
this is _really_ good advice - I find when I'm coding in a coffee shop then I feel more productive because the internet is a really big distraction.
I have the documentation on my laptop as well as the framework source code, so whenever I need to look someting up it's there. Having to make an effort to look stuff up means that my brain has more of an incentive to memorise it.
And practise, practise, practise. These things come over time.
If by php.net you mean the language manual, then yes. You will consult the language manual less and less, but you will always have new libraries to pick up, not to mention platform documentation.
Eventually you will know so many different things that you will seek to learn how a given system differs from another system you already know. You will end up getting a book on a new technology you have never used and jump straight to chapter 5, for example, or flip to the appendices, or read the dense 50 page spec over a cup of coffee. Sometimes, specially for protocol wrappers, you might skip the whole manual and retain the help of a disassembler of a packet sniffer. Sometimes you will start attacking a given implementation from its weak entry points: first the test cases, to see how something is used; then the header files, etc. You can skip on a whole new fangled thing by reading the BUGS and TODO files, if they exist (be weary of their absence more than their presence.) You will get an eye for the brittle by skimming the source and see how the developers implemented a few standard things. I have dumped way too many weak C system applications by just looking at how the developers implemented command-line parsing, for example. This will help you narrow down what you actually need to use, and from there you can choose the easiest one to learn of the few good remaining options (at some point you will learn to isolate library use-points by wrapping calls to other people's code in functions/modules, so you can replace them in one tidy place.)
At some point, also, you will end up googling for error messages more than actual tutorial help. This is specially true if you're interfacing with infrastructure software like an RDBMS or system libraries.
It always takes long to write the first solution, but as you write many different kinds of software, you will develop a portfolio of useful solutions you can apply in other works. Projects that are written fast are also the ones that don't teach you anything; it's not flattering to have churned out something quickly, it just means you're not pushing yourself (which shouldn't be a goal in and of itself, btw.)
Don't worry about the speed of development and just try to write small, fun programs that solve your immediate needs (if no need is apparent, then brag points; nothing motivates like the kudos of your peers. Ok, maybe cash, a red Ferrari and a night at the Vegas strip ;-)
At some point, also try to broaden your horizons. PHP is not exactly a fun thing to work with.