I expect the article comment was trying to be pedagogical regarding how much better they are than everybody else. perhaps as a way of allowing those self-fellating systems engineers to compensate for how they have to deal with "real" engineers who talk about how they aren't actually engineers and shouldn't be calling themselves engineers.
The way I see it, Web searches provide an alternative to reference material. Some people might act all high and mighty that they never use it but then they may very well just be repeating the pitfalls that could be avoided by reading a relevant stackoverflow question's various answers.
"Programmer's Guides" used to come with most software development tools, and they often included code samples or even rather large applications- Visual Basic 2.0 even discusses a full-blown icon editor program - so it's not as if you couldn't copy code from those.
On the other hand, I sort of understand where they are coming from. There are some developers who do rely in web searches as a crutch and perhaps would have difficulty solving problems without it; But for the most part I think it is just by developers who really don't care about that specific problem because it's part of some larger puzzle they are trying to put together.
On the other hand, There is also this idea that you "have" to google and see what everybvody else is doing. Take my recent "Tetris" clone. The game concept is pretty straightforward so I decided to reference nothing and do no searches on how it's usually implemented. At the same time I tried to design it well, without hard-coding anything. I've referenced it elsewhere and pretty much just received "Have you seen X" where X is some other Tetris clone/engine project. The entire point wasn't to have a Tetris Engine, it was to Write a Tetris engine/game myself. If I wanted to simply play it it's not like I have to look far.
The best part there is that now that I've got everything working I have looked at those other implementations and found them better in some ways, but lacking in others.
And once you get deep in domain knowledge you can't usually google it anyway. if I have issues with our Internal components, I can't rightly google it. It hasn't always stopped me and sometimes I only remember when I've entered a google search like "TheosClient WriteCommand +Can't read 2 bytes from server Exception" or something, as if there are going to be stackoverflow questions about our specific internal server libraries. And I certainly wouldn't be able to google for the algorithms of how to void invoices, how to rebuild QOH, or how to auto-renew purchase orders or how to reverse Open Item disbursements on an Invoice because even if I find something it's obviously going to be for some completely different platform/framework.
But, I've found it valuable for trying to google issues that seem to be related to the language or framework, which helps point us in the right direction. And considering it is sometimes time sensitive because there is literally a customer having the problem right now I don't think there is any shame in googling the problem. There are some instances where I doubt I would have ever tracked down the real problem, or if I did it would have taken a significant time investment. In one case I googled some of the specific verbiage of the error they were receiving and found stack overflow answers which mentioned Group policies being a possible cause, which it turned out was the problem- Apparently their IT department had put in place Group Policies that restricted certain folders from executing software on specific secure PCs (the ones they used for accounting) And it was those policies which broke some parts of our software. The policy prevented any executable from running from %APPDATA% and that was where our update software downloaded the new installation packages to and ran them, thus the problems. And once we learned that- it was trivial to change the program to download software to the Common Application Data folder instead, since it was already running as administrator anyway.