Short answer: Yes, I think it should be this way, but with caveats. Balance is the key. Taken to an extreme, the thinking approach can kill a project. After al

Short answer: Yes, I think it should be this way, but with caveats. Balance is the key. Taken to an extreme, the thinking approach can kill a project. After all, when it comes to computing, we are all standing on the shoulders of giants. The position that we should always solve our own problems by "thinking" suffers from irreducible complexity. Why not implement our own language? Brush off those compiler skills. See you in 5 years when you have the beginnings of a mature language. Meanwhile, your competitor, who used an existing language, will be 5 years ahead of you on their project. The same applies to "Googling" answers, which is just a metaphor for looking for prior work. If I find a solution to a complex problem in 2 hrs of Googling and reading, while my competitor hammers out their own solution, there's a good chance I'll gain a lead on them. There's also a good chance that my solution will be more flexible, leading me to continue development while my competitor is still extending their solution. As usual, "it depends". What are the priorities at the time? Is the team under a deadline (ha!)? Are we solving a problem that is considered central to our solution? In other words, would we gain a competitive advantage by building a better mouse trap? Do our programmers have the experience and talent to build said mouse trap? Few companies have the resources to hire people focused enough to solve difficult CS problems, so scouring the internet for leads on the best solution is never a bad idea, IMO. This applies even if a solution immediately comes to mind. At least "check your math". Maybe you'll find something you didn't think of. If you've got Facebook/Google money, well then throw this advice out the window. Go hire a six-figure PhD in your specific domain and make history. When faced with a difficult problem, the "think through the problem" method often requires the most time, and there is no guarantee that you'll arrive at the most efficient solution. Depending upon what you consider difficult, there may be exceptions to this rule, but if you are the kind of programmer that needs to Google solutions to trivial problems, you've got much bigger challenges ahead. For most competent programmers, Googling usually means looking for a library that accomplishes a task, or trying to locate the most efficient approach to implementing a non-trivial task. In these situations, Googling to locate an answer has the added benefit of context. It's rare that you find a solution in a vacuum. There is usually some discussion, so you're benefiting from the contribution of many people. Few companies have the resources to hire a large team of developers who specialize in all the important areas for a given project. Normally, you end up with a team -- sometimes a team of one -- of generalists who must look for solutions to specific problems that falls outside their area of specialty. In this case, Googling solutions makes a lot of sense.