> Remember that there was a time we programmed without copying our work.
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.)
Yes, exactly, the old saying goes: RTFM (Read The Fine* Manual). In the 21st century google is the manual. If you're not looking stuff up in google, you're doing it wrong. It's great if you can do some stuff without using google, but memorizing reference material doesn't mean you're a better developer.
I argue that it does: the more you have committed to memory of the basic units of your environment, the expotentially more efficient you will be, and simultaneously the greater problems you will be capable of solving.
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.
True, but there are also other brilliant minds in the field that are creating solutions that you can also learn from. Isolating yourself from that doesn't help much either.
also there were magazines with full working programs (sometimes event 4 to 5 pages of "beautiful" BASIC) that you manually copied - letter by letter, number by number - into a trusted C64 (or other pre-historic computer thingie).
I miss those. We should bring that back. Now there is github with tons of sources but very few explanatory paragraphs to help understand the reasoning behind the design or implementation. I've seen a number of devops blogs where there are posts with snippets of command lines and config files explaining how to get some software set up in difficult configurations, but it would be interesting to see development blogs with the same kind of depth including links to github source. I'm working on some ideas for something like that. Hopefully I'll really get started on it soon.
>"...try programming for a day without Googling. Then two days, maybe a week. See how it feels. Remember that there was a time we programmed without copying our work."
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.
right- there is a time to learn and a time to earn. though, accreting a bunch of solutions that you may not appreciate can sometimes screw you in the later term
>"But as a professional, with deadlines and money involved. Wouldn't google be best?"
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.
That was my first thought as well. I think that it is a great idea to experiment when working on personal projects/something with little to no deadlines. However, when the project is due yesterday and you come across something you don't know how to do... I have to say google is best.
I have grown a lot in the last few months by consulting library code & documentation first when I hit a road block & only turning to Google/Stackoverflow if I hit a weird error message I don't understand or shit really hits the fan. One major benefit of opening up the source code when I'm using a library is it often sparks my interest to return to that library later just to learn more about how it works.
Professional programmers get paid to solve problems. It just happens that many problems can be solved through google.
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.
> Professional programmers get paid to solve problems. It just happens that many problems can be solved through google.
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.
What a stupid, humblebraggy question. Of course you're a good developer if you Google. Hell, you could argue you're a better developer than most, given that you turn information into action in probably record time, all the while increasing your knowledge base.
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.
It isn't a crime if you occasionally need to google something. It is a crime if you copy and paste a solution you find without understanding how it works. This leads to cargo cult programming.
Is copy/pasting a solution without understanding how it works worse than using a library, framework, or programming environment without knowing how it works?
Yes, it is. Using a library is a transition of abstraction layers. It's expected that some understanding might get lost at that point. It's also expected that you understand what the library promises to do when you make that call - i.e. that you read the docs.
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 ;)
In that case, it sounds like it just depends on whether you paste the code directly into an existing file. If you paste the code into its own file, then import it into your project, the distinction seems to vanish.
A library isn't just code that happens to be in a separate file. Someone chose an abstraction layer at which to create a library, wrote the library code, tested it and wrote documentation.
If you went and copy-pasted some code on stack overflow into a file, put it on github and released it as a "library", I might not agree that it was one.
While it's good to know something about how all the component works, most of us spend most of our time at a particular level of abstraction, and don't worry about the details of the framework->language implementation->compiler->hardware instruction set->silicon pathways all the time.
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.
This could be an interesting debate. On the one hand, I can see similar problems arising from either copy/paste of unknown (to you) code or using an unknown (to you) library or framework. In both cases, there is black magic (again, to you) that could go wrong and you just won't know how to deal with it.
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 would say yes, because the effort required understand a copypasted snippet is less than the effort required to understand a library/framework/whatever.
To an extent. You should still know the performance details. As an example, a project a colleague was working on was generating Excel files as a report format. He didn't need to know why the library couldn't handle anything over a (forgot the exact number) 32MB, but he needed to know that detail. It failed to execute on some data files as a result, something that could have been checked and worked around (temporary fix: multiple Excel files; permanent fix: better report format).
How dare a developer double check his work to make sure he's going down the right path and has an optimal solution. Instead, he should sit around for a few hours trying to figure out why his B-Tree traversal is suboptimal. Because that's the best use of a client's time.
I use Stack Overflow (and to a lesser extent, Google) to help me with problems large and small all the time. Why break your neck to find a solution without finding out if someone else already did? There's never a point when you can't learn from others.
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?
There's nothing wrong with learning from others, but you want to make sure you're actually learning. That means going through the StackOverflow answer and making sure you understand all the API calls involved, what they do, how you just combined them, and where to go to find documentation on them.
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.
The question is, are you really learning? How much of that copy/pasted solution sticks with you a day or a week from now? The fact is we are missing the benefit of building up expertise that used to go along with spending time researching (through docs) and problem solving. When every problem is a google search away, there is a ceiling to how much expertise one can build up this way.
Edit: the reflex downvoters will be the end of this place.
Some solutions aren't worth committing to memory. Do I really need to remember all the flags on scp just to write a quick bash script when someone has already posted the correct incantation on StackOverflow?
Do you have to google it every time? The fact that repeated googling is required is a sign that something is off--either you're not growing from your experience or the API has too much friction. I've often felt this way when it comes to linux command switches. Just accepting that having to google everything is OK is the wrong answer here.
I always tell people that if it's worth memorizing because you use it a lot, you'll probably memorize it because you use it a lot anyway. If you have to make a point to memorize something, it's a hint to consider if it's worth the time.
I don't think people should put in effort to memorize things like command line switches. The issue I'm arguing against is accepting that we must now google everything to get work done. I agree that if its worth memorizing, you should eventually commit it to memory through repetition. The problem is that sometimes this doesn't happen. This is a sign of a problem, likely with the interface you're interacting with. If we accept the expectation is to just google everything, no one will ever stop to ask whether the interface itself is broken. If we accept that one should develop a mastery of their environment over time, then incentives form to improve ease-of-use, elegance, and "memorizability".
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.
Watch programmers who don't Google how they code, it usually ends up complicated, slow and worst of all insecure. If the only tool you have is a hammer everything starts to look like a nail. Using string.join instead of paremetherized SQL queries is a typically example of this! Any tutorial on top of Google will show you the correct solution to this but if you are too smart for this and reinvent your own way of creating queries then this will bite you in the ass one day.
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.
Kind of. A lot of the time the answer is on Stack Overflow, and good ones get voted up. Sometimes I find myself on Ubuntu forums and the more mainstream nature of the users often provides quite poor hacks to get things working.
I love Scott's response here. He comes at it by saying that feeling this way is not just OK but normal and then expanding on ways that you can overcome this by doing practice problems.
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.
As a newbie programmer (self-taught), I've asked the same question a lot lately.
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.
well, i just traveled south east asia for a few months, and lets say where i traveled (lots of islands, beaches in myanmar, cambodia, thailand) there was no internet, still i needed to code a very specific webapp for my 5 year old son (an mp3 concatenatior)
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
google is the tool to find source-code, and without other source-code, other websites to look at, your are definitely alone, reinventing one wheel (baldy) after the other.
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 think this is similar to the question "does using turn-by-turn GPS make me a better navigator?" The answer could go either way. If you depend on the GPS to the exclusion of paying any attention to your surroundings, you'll probably be a worse navigator, because it will take you much longer to learn even the common routes in your day-to-day life. If, on the other hand, you use GPS-aided navigation as an opportunity to learn the back roads that take you between two places more efficiently, but that you never would have discovered on your own, and internalize that knowledge, GPS can help you become much more intimately familiar with an area than you otherwise might be.
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'm not sure how it differed from opening up any manual to anything. The reason you are opening up the manual is the key point.
I think for me its was a progression from 'how' -> 'when' -> 'why' -> 'is there a better way'.
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.
On my own projects I'll sometimes "reinvent the wheel" on purpose. It's a good way to make learning mistakes. For better or worse, I tend to learn from making mistakes.
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.)
The important part is weeding out the good from the bad.
If you're good at that, then using google to check for help/info about your current problem can provide you with new approaches, ideas, or maybe even new features in the language(s) you are using that you weren't aware of before.
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.
I used to have a multi-volume set of IBM mainframe DB2 manuals on my office bookshelf. When we got an error code, I looked it up in the appropriate book. Google is just a much faster way to do the same.
I don't know if I would have made it past the first few hurdles without the Internet. I am self-taught, so the first years were doing as much searching (pre-google, I used Usenet a lot I think), as much as checking books out of the library and typing in the code by hand. Doesn't having access to an ever-growing library of code, some functional, some not, ultimately make us all more productive? Having said that, I do agree completely that you need to get a full understanding of what the code does: read and type, don't copy.
A lot of the problem with looking for an answer, especially if coupled to a powerful search system, is that you'll usually find one. Even when you're asking the wrong question. A large part of becoming a better developer, it seems to me, is learning to ask the right sorts of questions.
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 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.
I always start with 3. I even start with 3 before I have a bug, to see if I can't find a lib for my task, or if someone has a blog post on the thing where I can find some caveats or clever solution.
Indeed, this routine depends on you reading up on the problems you're tackling ahead of time, outside of the development/debugging cycle. This is no different to 15 years ago when you'd look in a book rather than a search engine.
As a developer new to Erlang, this is my life now. Google has been my Joe Armstrong book and the manual pages as howtos and fixes are scarce on the internet relative to, say, Ruby. If I had deadlines, I would be toast. But it feels nice to work a bit harder and think through things more -- now that this is my new reality. It's neat!
Imagine how much value/productivity would be lost if stackoverflow was erased from existence.
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.
I recognize the title of this post as a tongue in the cheek, because "Googler" is a nomenclature for the Google employees, which makes the title sounding really bad. Especially if posted by a Microsoft employee. Please correct me if I'm wrong in my paranoia.
Given enough time I could always come up with an answer to my programming problems. Quickly finding a peer-reviewed answer on StackOverflow seems like a much better option to me.
Sure, just do whiteboard coding of a difficult algorithm because it replicates actual coding conditions quite nicely </snark> I'd much rather see what a candidate can come up with while working at their leisure, using their favorite IDE, googling syntax and other questions, testing, and having time to refactor than see what they will come up with on the fly, under pressure, without any tools available to them.
This. I've also had co-workers hell-bent on building out over-the-top unnecessary solutions (albeit sometimes neat in a technical sense) to problems that already had existing solutions that we could have easily leveraged and saved lots of time (money). Being able to leverage resources efficiently so that you are able to get more done is valuable. Go crazy and solve big problems when necessary but don't be afraid of using Google or any other resource to get through the rest.
Exactly. Love or hate Goog/Bing, they are powerful tools if you know how to use them.
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.
The goal of the problem solving interview is more to see the candidates reasoning process and less the ability to recall the problem and reproduce a solution. I like interviews where the problems are more open ended and the interviewer is active in the process and it's more of a discussion towards a solution and THEN coding or at least some pseudocode.
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.
That's what I meant. I personally hate interview questions revolving around "reverse a string" and alike, but really like open ended questions, which result in many options and discussions, AKA "design questions".
Since Hacker News has been going through some introspection recently, I just wanted to pontificate on the comments thus far: Almost universally garbage. Just terrible.
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.
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.)