Nope. I remember specifically copying from known solutions in large organized reams of marked paper (a "book" we called it). They used to have whole rooms, and personnel, dedicated to storing them. Now, you couldn't just ask for what you wanted, like "clojurescript core.async examples". Oh, no. Research required either knowing how to search through the "books" or remembering previous solutions to similar problems. (And, I'm not that old.)
Think of programming as speaking in a language. He who has more of the language committed to memory will be orders of magnitude greater at communicating in that language than someone who has to look up every odd word. Furthermore, the concepts that can be created will be much more complex and abstract than the person who doesn't have a handle on the basics: people who are clever and quick-witted in a language they are fluent in will often seem dull in a language they don't know well. Having the basics committed to memory is absolutely critical. Its unfortunately that this level of mastery has been devalued with the rise of the "just google it" culture.
Once I decided I really wanted to learn to write code I just plain stopped with the copying and even referencing anything beyond docs or a thorough book.
I work to create a functional implementation of whatever it is I'm looking for, no matter how naive, convoluted or narrow my solution ends up being.
Only once that's done do I go about searching out solutions. Sometimes I'm delighted to find that what I've come up with comes very close to established solutions, other times I learn some new, concise way of going about the problem.
In any case, that first sort of experimental phase is incredible for informing everything that comes after. I'd say experiencing 100 less than optimal ways to do something is far more valuable than memorizing a single optimal solution.
Thing is, around the web, this sort of approach seems pretty ripe for ridicule as the Internet standard response is something like this [0].
There's a culture against discovery and creation. You either come out of the womb writing clever, idiomatic code and using or the hottest framework/library or you're an idiot.
I actually meant to say something about this in my original post.
There's definitely something to be said for going straight for a solution if you write code for a living.
Though, I'd be hesitant to say Google is best without a qualifier. It's a great tool and incredible reference, but you'd have to think about the value and potential liability of a developer who is committing Googled code he/she doesn't fully understand.
There's nothing to be ashamed of if you need to do a bunch of searches to get your job done. What we all should be wary of though, is to have a job so that all of our problems are solved through googling.
Where we really earn our money is when we create something that wasn't there before, solving original problems.
This. Also, the web has largely displaced the bookshelf of resources that used to come with most language implementations (some with first-party documentation on websites, and some with web forums, etc.) So I really don't see any difference between using Google to find information when programming today than RTFMing when programming in the 1980s.
I might be different from most, because I went from 0 to professional developer in under 5 years, and I can easily remember what it was like to find answers and not be able to know what to do with them, or how they worked. I still google for answers. A lot. But when I find an answer, even one that's not directly related to my problem, I'm still usually able to apply its principles to my solution.
It's that artisanry that makes us good developers. Hell, why do you think every industry has trade conventions? It was sharing trade solutions before Google.
Copy/paste lives at the same abstraction layer as code that you actually write yourself - the same level of understanding should apply. (Of course, if you don't understand any of the code you write, you're in the clear ;)
If you understand your code at your current level of abstraction, you're probably doing OK. If you don't, you're definitely in trouble.
On the other hand, there's a difference in the level of abstraction between copy/paste of code and calls to a library or framework. The question is, will you recognize the difference between a bug in your code, a bug in the copied code, and a bug in the framework code?
To solve code problems, you need to be able to identify where the problem actually lies ...
I think that in most cases, I can reinvent the wheel if I have to (find my own solution). But why should I? Why not ask Google if there's already a library that does that?
It's like pair programming on a massive scale!
If you do that you'll get really good at your technologies really fast. If you just copy & paste the answer you'll have solved exactly one problem, and then you'll have to Google again for your next problem.
Edit: the reflex downvoters will be the end of this place.
Good programmers come up with solutions. Poorly half-reinventing what has been done before.
Great programmers learn from others (googling is expeditious method these days). They take from others and make that knowledge their own.
Code monkeys have little understanding of what they copy, can barely get syntax right, and are satisfied that it seems to produce desired result with the one input they tried.
Even if you think you know how to do something, spend 5 minutes on google to see if this is the defacto optimal solution for your problem and if there are any gotchas you have to consider. I'm not advocating blindly copy pasting code from random stackoverflow answers but at least look at them and understand what they do, then you can copy them.
Am I really a musician, or just a good YouTuber?
The ability to learning how to utilize resources that are available to you so you can do your job better is a huge part of why I'd hire you.
This has been a great boon to my confidence lately as when I'm working the mode I get in is to solve a problem as fast as possible because if I don't I'm wasting my companies money... I don't always get the time to think about the problem (which I recognize is not a great environment but it's easy to fall into). So googling something and taking the first working answer sometimes seems the best thing to do even though deep down I know it isn't.
That is why I do practice problems, they force me to think and give me a chance to ease off of Google. Great advice as from Scott.
I think to some extent it's a matter of habit -- I've learned the most about my ever-improving (but still limited) abilities during the few times I've found myself coding on an airplane flight without WiFi.
When I'm forced to go with only what's in my head, I've been surprised at how far I can get (!). It was actually pretty satisfying to solve a problem and get some code working without a single Stack Overflow query :)
Of course, there are limits, and there are times when I'll hit a roadblock that's truly a limit of my knowledge (usually API/syntax-related). And even then, I've managed to make a few educated guesses and surprise myself with the result.
'Short order cook' is a low wage job, 'Executive chef' is a high wage job.
i will outline my experience on the next viennajs (our local JS meetup) http://www.meetup.com/viennajs/events/126159362/?_af_eid=126... in a talk called "coding an awesome real world problem solving web-app without internet access after your girlfriend deleted your dev-setup on a device that hates developers while traveling south east asia" - i will post the slides to HN after the talk. but (SPOILER) the conclusion as it contributes to this discussion:
EMBRACE THE INTERNET
- right click "view source" is a gift from the gods
- github is even better
- read the f_cking source, luke
so google away, but not looking for frameworks and other ready made solutions, but for (example or real world) sourcecode and understanding.
note: the only thing bearable to code without internet access was the chrome dev-tools, with auto-complete and object-inspection you can piece together most HTML5y APIs.
I see Google/Stack Overflow through the same lens. Lean too heavily on snippets of other peoples' code, and you'll never learn to solve even simple problems on your own. But if you take the time to actually learn why a particularly elegant answer on Stack Overflow works, and generalize that technique, you can grow your skillset much more quickly than by trying to figure out everything yourself from first principles.
I'll frequently go days without Googling anything, weeks if its just CRUD work. When I started it was very different, I can remember writing entire database layers via copy and paste with no idea what anything did I just knew it worked and thats all I needed.
But I'm at a point now I smell bad code in my own work and want to get rid of it and I only got there because I did google... I did go to blogs... read the responses... reference pages/critiques... read white papers/specs/manuals.
And above all I wasn't intellectually lazy, I put in that little bit of effort to ask why, and then get it verify. Nothing wrong with reading source material, theres only problems if you fail to understand and retain what you are reading.
At work though, my employer isn't really paying me so I can experience personal growth. I'm try to deliver value as efficiently as I can.
I've done this long enough to know that the "easiest" problems can have subtle bugs. Think of the singleton pattern: if you write one "without looking at the answer" you invariably make a small mistake that introduces a race condition. That's why I Google even "easy" problems.
That said, I can't do math in my head very well any more - calculators have robbed me of day to day practice and my 8th grade math skills are flabby now. (My degree is in math so it's especially embarrassing.)
Personally, I usually map out the approach to the problem and then check if there are any matching helpful resources available online. Even if you don't find something that applies to the current situation, most of the time you will end up with a collection of interesting new ideas and approaches, which could be helpful for another project later on or is just of general interest, such as a new library or language feature.
I feel that it keeps me more up to date compared to just hacking away on the problem without any further research.
Which is difficult to do if you don't have a reasonably wide general knowledge and an understanding of why things are done a particular way, as compared to some other way, and what the trade-offs in that choice were.
Step 1 read the docs (again.)
Step 2 look at somebody else's code: the library and its tests, another similar project, or whatever. Use the source luke!
Step 3 put a natural-language-ish query into google/stackoverflow.
When you're properly competent with the language and tools you mostly won't get to step 3. By the time you get there, you're looking for a specific piece of info, not a solution.
Google is simply one of the many tools in the developer-of-today's toolbox.
I saw somewhere that you can get all of wikipedia on a 128GB SD card? Would be cool if you could get the same for all of stackoverflow. Would make a neat gift and might serve some practical purposes if you were working offline.
It all depends on your goals though, I guess.
Before the ubiquity of spell checkers I never hesitated to pick up a dictionary to double check spelling or a definition. I've never thought twice to grab a text book, manual or encyclopedia to reference a subject I was familiar with but did not know by rote or fully comprehend. Memorization is a very useful skill, as is understanding & comprehension. There is no guilt or shame in not being omniscient.
I've had interviews where I'll be asked some canned algo/data structures problem (some version of knearest, or longest substring) and then the interviewer will tune out- these are mostly lame.
There is some sort of bizarre urge for people to rush to explain "Why This Guy Is A Dumb Asshole" for virtually every submission to HN. Where someone talking about a letter they were sent, and opportunities for learning experiences, turns into some profound statement that everyone needs to dispel defensively.