How Much Does an Experienced Programmer Use Google?(two-wrongs.com)
two-wrongs.com
How Much Does an Experienced Programmer Use Google?
http://two-wrongs.com/how-much-does-an-experienced-programmer-use-google
97 コメント
Lets not forget about the MSDN subscription that came via CDs.
I'm only 27 and I too started coding before there was Google. Dial-up was barely becoming a thing in my country. This was around 1995/1996.
I got my first internet connection at home in 2001 (ADSL). Before that I would go to the library to use their internet. But it was a huge novelty and I had no idea how to use it to help myself or how to find a BBS or anything. I knew how to IRC, but I didn't know there were other programmers there.
Those 5 years were a strange strange time. I would spend my days between the text editor and its built-in help files. This was Turbo Pascal. It was great, I could look up the function signature of anything in the language and some description of what it does. Once a week I would ask my mentor about things. The rest was tinkering.
And, honestly, it was amazing. I was having shitloads of fun just playing around with different functions, coming up with my own ideas on how to use them, figuring things out just by trying them and seeing what works better instead of immediately resorting to the internet and doing research like I do now.
Sure, I'm more productive now, but I'm having a lot less fun.
I got my first internet connection at home in 2001 (ADSL). Before that I would go to the library to use their internet. But it was a huge novelty and I had no idea how to use it to help myself or how to find a BBS or anything. I knew how to IRC, but I didn't know there were other programmers there.
Those 5 years were a strange strange time. I would spend my days between the text editor and its built-in help files. This was Turbo Pascal. It was great, I could look up the function signature of anything in the language and some description of what it does. Once a week I would ask my mentor about things. The rest was tinkering.
And, honestly, it was amazing. I was having shitloads of fun just playing around with different functions, coming up with my own ideas on how to use them, figuring things out just by trying them and seeing what works better instead of immediately resorting to the internet and doing research like I do now.
Sure, I'm more productive now, but I'm having a lot less fun.
Yeah. I didn't use Google (or any other search engine) when I started. For some I had an electronic reference with some syntax. But you know what I really used? The printed reference, either a manual for a language or a printed copy of it if the original was in electronic form. I'd have this stack of 200 pages of printed paper..
Nowadays I'm kind of scared of how much I rely on Google and StackOverflow, and fear I'm being too reliant on other people's knowledge, but you know what - there was an alternative, and it sucked.
Nowadays I'm kind of scared of how much I rely on Google and StackOverflow, and fear I'm being too reliant on other people's knowledge, but you know what - there was an alternative, and it sucked.
Scared, but also delighted, because paper manuals and futzing around with syntax was a joyless chore.
I didn't have internet access when I was a kid so I used the included qbasic documentation and books from the library that had example code (in the form of atari-style video games) when i taught myself to program.
Yes, I remember the days of the giant Java reference book being shared among cubicle-mates.
The other thing to keep in mind is that much more of the code we relied upon back then was closed source. Anyone remember the bad old days of decompiling Weblogic to track down what was going on with some strange bug under the hood?
The other thing to keep in mind is that much more of the code we relied upon back then was closed source. Anyone remember the bad old days of decompiling Weblogic to track down what was going on with some strange bug under the hood?
There was Compuserve dialup. Expensive and slow as molasses.
Compuserve was great for its time. It allowed you to connect to other developers. I have never been more active on forums then I was on the compuserve forums. It WAS the place for developers.
Having grown up with google, I still sometimes look at code (that I just got to work after an exhausting search on Stackoverflow) and think, "man, future generations of coders must figure out something more practical" and I'll probably get to tell them, "yep, that's how tedious it was" stories as well. What strikes me the most is how often code repeats, how often mistakes repeat. You can google a quite specific problem and more or less always find a result, likely a Stackoverflow article with tens of thousands of views. While it's great that we now have a collective knowledge tool to fight this, it also illustrates how much programming is still running in circles. We take pride in expertise and skill, but how much of this is memorizing workarounds and exotic quirks that shouldn't even be necessary?
What will be the next google? The next Stackoverflow? I doubt it will literally just be a better version of either. It will probably be better IDEs and debuggers. Heck, I doubt we'll continue to type as much as we do...
What will be the next google? The next Stackoverflow? I doubt it will literally just be a better version of either. It will probably be better IDEs and debuggers. Heck, I doubt we'll continue to type as much as we do...
> You can google a quite specific problem and more or less always find a result
usually when i have to resort to finding someone else's solution i find nothing. its probably a 70/30 or 80/20 split. when it comes to low level or actually challenging problems stackoverflow is more noise than answers. its become a bit like expertsexchange used to be, unless you are a web dev.
usually when i have to resort to finding someone else's solution i find nothing. its probably a 70/30 or 80/20 split. when it comes to low level or actually challenging problems stackoverflow is more noise than answers. its become a bit like expertsexchange used to be, unless you are a web dev.
>I still sometimes look at code [...] and think, generations of coders must figure out something more practical
Imagine if package management happened this way: say you want to update your version of, oh I don't know, wget. First you Google "wget" and your operating system (analogy for your programming language). Then you open... not the wget page. There is none. You open stack overflow tabs. Not just one either. You look through them, i.e. the answers, the comments about the answers. Finally you find one that people report actually works, you copy a massive block of code into a text file. You make some changes, as it isn't really complete. You save it. You compile it. And, if it worked, there's the latest version of wget, and you move on.
Sound reasonable? Apparently it is for programming languages.
Imagine if package management happened this way: say you want to update your version of, oh I don't know, wget. First you Google "wget" and your operating system (analogy for your programming language). Then you open... not the wget page. There is none. You open stack overflow tabs. Not just one either. You look through them, i.e. the answers, the comments about the answers. Finally you find one that people report actually works, you copy a massive block of code into a text file. You make some changes, as it isn't really complete. You save it. You compile it. And, if it worked, there's the latest version of wget, and you move on.
Sound reasonable? Apparently it is for programming languages.
I am not sure that your analogy quite holds. Though maybe I am reading into it incorrectly. When I turn to Google or Stackoverflow the problem isn't something that could or should be solved by existing code or documentation. It's often more nebulous. I am sure there are those who strictly code by copying and pasting from StackOverflow but I would imagine in the long run they either get better at coding or they fail miserable.
For me and most of the people I know who look things up it's more like, "I am working on this piece of code which is giving an error, and I have stared at it for a bit and I don't see what is wrong. I wonder if others have seen this problem before. I need a bit of inspiration to get me through it." It's almost like paired programming. It's not so much that I am looking for an answer, I am looking for a toe hold in order to push myself just a little higher on a cliff. Inspiration from others experiences helps me to move along quicker. I got this in the past from BBS's, books, and magazines. But now the internet has made that process quite a bit faster and less expensive. And that seems reasonable to me.
For me and most of the people I know who look things up it's more like, "I am working on this piece of code which is giving an error, and I have stared at it for a bit and I don't see what is wrong. I wonder if others have seen this problem before. I need a bit of inspiration to get me through it." It's almost like paired programming. It's not so much that I am looking for an answer, I am looking for a toe hold in order to push myself just a little higher on a cliff. Inspiration from others experiences helps me to move along quicker. I got this in the past from BBS's, books, and magazines. But now the internet has made that process quite a bit faster and less expensive. And that seems reasonable to me.
yes and no. It is often nebulous, but at the same time the nebulous parts are often incredibly well-defined, so that if your IDE came up with it instead of a Google result, you could fill in the blanks there and then. But your IDE doesn't do your Googling for you, you have to leave and come back.
My guess is that IDEs and debuggers will be more integrated with what's available online. Let's say you have a compiling error. Currently you look up on google the error message the compiler gives you and most likely get a stackoverflow link with someone having the same problem - and hopefully someone else having answered it. Your IDE could do that automatically instead - there is already a plugin to access stackoverflow from emacs [0].
I imagine one further step would be to have some AI that can read snippets of your code that are causing problems and match it to similar snippets from Stackoverflow. Let's say your code is (in python):
[0] https://github.com/omouse/emacs-sos
I imagine one further step would be to have some AI that can read snippets of your code that are causing problems and match it to similar snippets from Stackoverflow. Let's say your code is (in python):
myCounter = 0
while myCounter < 10:
doSomething(counter)
The AI could realize that it's exactly the same mistake as this code that someone posted on stackoverflow because it ran infinitely: i,n = 1, 50
while i < n:
doSomethingElse(i)
(of course, I used a very trivial example, but you get the idea).[0] https://github.com/omouse/emacs-sos
> Currently you look up on google the error message the compiler gives you
this makes me afraid a little. although given the style of your examples i can imagine you have just not had a problem just because of using simple and permissive, modern languages which are difficult to make mistakes with.
due to the nature of compiler errors 99% of the time i can work it out by looking at the line of code.
1% of the time i need to read it carefully because it involves deeply nested C++ templates, and once i find the offending line i fix it 99% of the time in the same way.
the remaining tiny fraction i learn something new. but find that most of the google results are people who failed to solve the problem instead of anything useful, and just have to work it out for myself. i will waste time reading stackoverflow posts with no answers, or answers from people who only want to answer, rather than know an answer. occasionally an apple fanboy will rile me by claiming in some comment that everyone is doing it the wrong way and suggesting something so dumb my head nearly explodes. :)
this makes me afraid a little. although given the style of your examples i can imagine you have just not had a problem just because of using simple and permissive, modern languages which are difficult to make mistakes with.
due to the nature of compiler errors 99% of the time i can work it out by looking at the line of code.
1% of the time i need to read it carefully because it involves deeply nested C++ templates, and once i find the offending line i fix it 99% of the time in the same way.
the remaining tiny fraction i learn something new. but find that most of the google results are people who failed to solve the problem instead of anything useful, and just have to work it out for myself. i will waste time reading stackoverflow posts with no answers, or answers from people who only want to answer, rather than know an answer. occasionally an apple fanboy will rile me by claiming in some comment that everyone is doing it the wrong way and suggesting something so dumb my head nearly explodes. :)
I wonder if there is (or could be) a program that collates the most common bugs for X programming language from SO. So you run it as a sort of preprocessor, and it picks up stuff that the compiler either doesn't or can't.
Google's Tricorder
http://research.google.com/pubs/pub43322.html
Not related to SO, but FindBugs and PMD for Java are designed to identify potential bugs, based on accumulated knowledge of "gotchas" (e.g. calling "multiply()" on a BigDecimal without assigning it to a new variable - BigDecimal is immutable).
Just tie the compiler to Stackoverflow! I kid, but error messages could be much better.
There was a sorting algorithm that randomly selected a sort function from Stackoverflow posts until one of them was able to sort data
The help in programs used to be fairly comprehensive though. I don't think I have used one for years.
Larger (regional) public libraries were where I'd be able to find a pretty good variety of books about computing. I'd pick them up regardless of subject, e.g., the APL book despite having no access to APL-capable machines, or a text on expert systems despite having no AI fundamentals. It was fun and a little mysterious, and I did a lot of on-paper coding. It was also easy to get a good C programming book for more practical stuff.
Sometimes I'd scour BBSs for a little info, mostly about BBS programming in pascal. It was usually faster to go to the library, though, since the Fidonet transfers were irregular and usually a day between.
I'm not sure if having Google, or even a more developed internet, would have been better. I spent a lot of time "inventing" things, which, I think, really ingrained the basics into my head. It was, in a way, disappointing to learn later that some data structure was actually old and well researched by people with 20 years on me. But those are the ones that will always stick with me.
Sometimes I'd scour BBSs for a little info, mostly about BBS programming in pascal. It was usually faster to go to the library, though, since the Fidonet transfers were irregular and usually a day between.
I'm not sure if having Google, or even a more developed internet, would have been better. I spent a lot of time "inventing" things, which, I think, really ingrained the basics into my head. It was, in a way, disappointing to learn later that some data structure was actually old and well researched by people with 20 years on me. But those are the ones that will always stick with me.
if you were a late comer to those days it was amazingly good. the help file from qbasic got me started down a path that didn't end, and getting a visual basic with msdn on cd was even better... it makes me sad when i see the msdn today, and even more so the apple and google docs which are absolutely terrible, bordering on useless in many cases. don't even mention linux development which still seems to be stuck in 1970s mentalities when it comes to usability.
When I learned programming, it was pretty common to get from a senior programmer, some huge source listing, and use it as a reference.
When I got my first real computer, I got Turbo Pascal, and its manual was excellent. Also (not atypical in the day) the language and its libraries replicated the essential functionality of the system, so the language was the system.
It was not unrealistic that I memorized TP in its entirety after a couple of years.
Today, I think the challenge is that we are programming much more complex systems, and the functionality we need is not self contained, but is pulled together from scattered bits and pieces. Much as I love the Python ecosystem, it must seem like an enormous squirming mass to someone who is accustomed to working within a package such as Matlab or Excel.
When I got my first real computer, I got Turbo Pascal, and its manual was excellent. Also (not atypical in the day) the language and its libraries replicated the essential functionality of the system, so the language was the system.
It was not unrealistic that I memorized TP in its entirety after a couple of years.
Today, I think the challenge is that we are programming much more complex systems, and the functionality we need is not self contained, but is pulled together from scattered bits and pieces. Much as I love the Python ecosystem, it must seem like an enormous squirming mass to someone who is accustomed to working within a package such as Matlab or Excel.
Google usually finds StackOverflow answers which is great.
I once found an answer to my question from SO, tried to upvote it but SO didn't let me because it was my own answer to the problem written over a year ago.
It seems StackOverflow works well for seniles as well.
I once found an answer to my question from SO, tried to upvote it but SO didn't let me because it was my own answer to the problem written over a year ago.
It seems StackOverflow works well for seniles as well.
I'm embarrassed to say, but this has happened to me too. More than once!
> Google usually finds StackOverflow answers which is great.
Depends - I've seen stackexchange questions that are exactly what I'm looking for and I would argue are on topic - only to see that it has over N thousand views with a note saying "closed due to offtopic" by a moderator.
Don't even get me started with those people who go through the site editing posts to change the link that someone posted because they don't agree with that site.
Don't get me wrong - there are some great answers on stackexchange sites. But too many times I've seen someone ask a question, a response with "no that's not possible" then another with "actually that is possible".
Depends - I've seen stackexchange questions that are exactly what I'm looking for and I would argue are on topic - only to see that it has over N thousand views with a note saying "closed due to offtopic" by a moderator.
Don't even get me started with those people who go through the site editing posts to change the link that someone posted because they don't agree with that site.
Don't get me wrong - there are some great answers on stackexchange sites. But too many times I've seen someone ask a question, a response with "no that's not possible" then another with "actually that is possible".
The worst part is when you search for a question and find one obscure topic several years old asking the same question. Then you realize you were the one who asked that question years ago, and you never found an answer.
Almost 20 years in and I still use stackoverflow (via google) most days.
There are just so many weird things that take too much digging through other people's src to figure out while you're busy trying to solve another issue.
Something as simple as (last week) - why is my unicode printing ok in the terminal but not when running from upstart? You debug to that level and then you want to know the right way of configuring things. I normally read a bit more than I need to so I'm better armed for other scenarios.
There are just so many weird things that take too much digging through other people's src to figure out while you're busy trying to solve another issue.
Something as simple as (last week) - why is my unicode printing ok in the terminal but not when running from upstart? You debug to that level and then you want to know the right way of configuring things. I normally read a bit more than I need to so I'm better armed for other scenarios.
I miss the days when I was developing in mostly only one language (C) and mostly only one environment (X11/Motif), all the searching I needed to do could be done on my bookshelf that was filled by the awesome O'Reilly 'Definitive guides to the X11 system' series and other related books (like the great 'Software portability with Imake', for example)
It was so nice to have all the knowledge I needed at my fingertips and I was always sure to visit any technical bookstore if I was abroad to see if there were other O'Reilly books I didn't own; I remember when I went on vacation in England feeling so bad about not being able to buy all the books I wanted in London because I didn't have enough space in my luggage...
Nowadays having to switch at a moment's notice between perl, python, C and java, as well as many, many, many related environments/libraries I don't think I could function without google, there is just too much information available and it changes way too fast.
It's not like it's any more complicated than it used to be (I think at one point I ended up subclassing the XmText widget to support rectangular selections, which took a while to get working) it's just the volume that makes it difficult to keep more than a couple of environments fresh in your brain without having to be online to refresh your memory.
It was so nice to have all the knowledge I needed at my fingertips and I was always sure to visit any technical bookstore if I was abroad to see if there were other O'Reilly books I didn't own; I remember when I went on vacation in England feeling so bad about not being able to buy all the books I wanted in London because I didn't have enough space in my luggage...
Nowadays having to switch at a moment's notice between perl, python, C and java, as well as many, many, many related environments/libraries I don't think I could function without google, there is just too much information available and it changes way too fast.
It's not like it's any more complicated than it used to be (I think at one point I ended up subclassing the XmText widget to support rectangular selections, which took a while to get working) it's just the volume that makes it difficult to keep more than a couple of environments fresh in your brain without having to be online to refresh your memory.
I am considered a senior engineer in my specialization and I still Google a lot of things.
There are still many things that I don't know, some things on the tip of my tongue that I almost remember and some things I use once or twice a year and forget in the meantime.
However, the more I mature as a developer, the faster I can detect horrible StackOverflow answers which technically answer the question but cause a couple of more or less sneaky issues.
There are still many things that I don't know, some things on the tip of my tongue that I almost remember and some things I use once or twice a year and forget in the meantime.
However, the more I mature as a developer, the faster I can detect horrible StackOverflow answers which technically answer the question but cause a couple of more or less sneaky issues.
Yep, the good/bad pattern-matching is the important and hard (impossible?) to teach part.
If it's pattern matching then the most effective teaching method is probably exposure to patterns plus feedback on attempts at detecting/emulating those patterns.
Agreed. Interestingly, this is how gaining experience works – you become exposed to patterns by needing to search for them, and get feedback from interpreters, compilers, and code reviews from teammates on how well you have picked out the right approach. Presumably that process could be sped up with a more formal approach.
For the sake of other programmers, I really hope you comment these answers and provide tips ;)
One common characteristic I've noticed among the experienced engineers I've known - none of them have the time or inclination to post to StackOverflow, or forums, etc.
> However, the more I mature as a developer, the faster I can detect horrible StackOverflow answers which technically answer the question but cause a couple of more or less sneaky issues.
This has been my experience as well. As I progress beyond the junior engineer stage of my career, I find the surface layer of the web to be increasingly less useful. The sheer amount of garbage out there makes me worry for new programmers.
This has been my experience as well. As I progress beyond the junior engineer stage of my career, I find the surface layer of the web to be increasingly less useful. The sheer amount of garbage out there makes me worry for new programmers.
Using Google is ok, but mastering Google is art!
Although sometimes you are the first that hit an issue.
Solving the issue and sharing the results is the next greatest thing one could do. Reporting the issue is great too.
Although sometimes you are the first that hit an issue.
Solving the issue and sharing the results is the next greatest thing one could do. Reporting the issue is great too.
This post is a good example of why fact based interview questions are not useful. It's how information is gathered and applied which separates the wheat from the chaff.
Einstein puts it best:
One of Einstein's colleagues asked him for his telephone number one day. Einstein reached for a telephone directory and looked it up. "You don't remember your own number?" the man asked, startled. "No," Einstein answered. "Why should I memorize something I can so easily get from a book?"
Einstein puts it best:
One of Einstein's colleagues asked him for his telephone number one day. Einstein reached for a telephone directory and looked it up. "You don't remember your own number?" the man asked, startled. "No," Einstein answered. "Why should I memorize something I can so easily get from a book?"
There's a similar story in "You Must Be Joking, Mr. Feynman". Feynman looked up something on an anatomy chart of a cat. A biologist was ribbing him that he had to look it up. Feynman said, "You mean you spent four years memorizing something I could look up in 15 minutes?"
Feynman was not a medical doctor, I don't understand why he would be teased about not knowing the anatomy of the cat.
Reasonable question, but I'm pretty sure the person was just happy there was one thing they knew better than Feynman (who seemingly knows everything else).
As I recall, it was Feynman giving a presentation in a biology class he was taking, and the biology graduate students saying Yeah, Yeah we know that; Feynman then said that no wonder he could catch up to graduate level if they spent all that time memorizing cat anatomy. And I'm not sure that Feynman had quite the name outside the physics community at that point.
That was my first thought today. Faced with a programmer who had to look up how to determine array length, what would you conclude about their skills?
I seem to remember a Joel on Software post a while ago that said that deep and specific API knowledge was a must, and I remember disagreeing rather strongly with that too.
The last company I ran, we used a programming test in a language the candidates didn't know. It seemed to be a better predictor than the C++ test it replaced. Because it separated knowledge and understanding. I'd rather have people with deep understanding who can offload their knowledge retention burden, than trivia-gurus.
I seem to remember a Joel on Software post a while ago that said that deep and specific API knowledge was a must, and I remember disagreeing rather strongly with that too.
The last company I ran, we used a programming test in a language the candidates didn't know. It seemed to be a better predictor than the C++ test it replaced. Because it separated knowledge and understanding. I'd rather have people with deep understanding who can offload their knowledge retention burden, than trivia-gurus.
Knowledge.
Understanding.
Experience.
They all seem necessary for optimal performance. And they all seem different. Yet they all rely on the first: knowledge.
At some arbitrary point of abstraction, the ability to manipulate accumulated knowledge becomes understanding. This seems best gained through practical (rather than theoretical) experience.
But it's all based on knowledge.
Certainly "understanding" appears to be more valuable, as evidenced by examples given here comparing understanding with knowledge. But is that an arbitrary distinction? Is understanding predicated on knowledge? It seems to be. Is practical experience better than theoretical? It feels so.
I wonder if the distinctions we draw between these concepts is somewhat arbitrary. I struggle to pinpoint the phase-shift at which accumulated knowledge becomes understanding, and what signifies a collection of knowledge that had failed to become understanding.
Understanding.
Experience.
They all seem necessary for optimal performance. And they all seem different. Yet they all rely on the first: knowledge.
At some arbitrary point of abstraction, the ability to manipulate accumulated knowledge becomes understanding. This seems best gained through practical (rather than theoretical) experience.
But it's all based on knowledge.
Certainly "understanding" appears to be more valuable, as evidenced by examples given here comparing understanding with knowledge. But is that an arbitrary distinction? Is understanding predicated on knowledge? It seems to be. Is practical experience better than theoretical? It feels so.
I wonder if the distinctions we draw between these concepts is somewhat arbitrary. I struggle to pinpoint the phase-shift at which accumulated knowledge becomes understanding, and what signifies a collection of knowledge that had failed to become understanding.
> I wonder if the distinctions we draw between these concepts is somewhat arbitrary.
Yes, that is a feature of all language.
But I think I was specific about the knowledge I meant. Namely, deep and specific recall of the API. Contrasted with understanding of a range of ways an API might have been structured or defined that would allow someone to program effectively in an environment they had no experience of.
Of course, one can define that as 'knowledge of a range of ways an API might have been defined', but them's language games. Beloved of undergraduate philosophy majors, but pointless beyond that, I'd say.
I wasn't making a point about words, but about the way we approach syntactic recall in programming languages as a proxy of programming competence.
Yes, that is a feature of all language.
But I think I was specific about the knowledge I meant. Namely, deep and specific recall of the API. Contrasted with understanding of a range of ways an API might have been structured or defined that would allow someone to program effectively in an environment they had no experience of.
Of course, one can define that as 'knowledge of a range of ways an API might have been defined', but them's language games. Beloved of undergraduate philosophy majors, but pointless beyond that, I'd say.
I wasn't making a point about words, but about the way we approach syntactic recall in programming languages as a proxy of programming competence.
I wasn't disagreeing with you, just adding some thoughts.
However, I do disagree with you here :) I suspect that AI researchers, linguists, theorists of mind, neuropsychologists and many others may take umbrage with your suggestion that exploring the ability to gain knowledge and convert that into "understanding" is pointless beyond philosophy.
Perhaps my tone was philosophical, not that I have a problem with that. However I was hoping for someone to dig further into the topics raised rather than dismiss them. I also wasn't "making a point about words" but rather the fields I mention here. Perhaps I should have been more explicit about that.
Anyhoo... syntactic recall as a proxy of a practical skill always seems doomed to produce inaccurate results. A job is not like an interview, in many ways. Where does that leave us? It feels that we should be able to interview people in order to separate the suitable from the unsuitable. Perhaps that's not the case, and we're deluding ourselves. I'm reminded of Daniel Kahnemann and the Israeli army recruiting procedure: http://www.businessinsider.com/daniel-kahneman-on-hiring-dec...
However, I do disagree with you here :) I suspect that AI researchers, linguists, theorists of mind, neuropsychologists and many others may take umbrage with your suggestion that exploring the ability to gain knowledge and convert that into "understanding" is pointless beyond philosophy.
Perhaps my tone was philosophical, not that I have a problem with that. However I was hoping for someone to dig further into the topics raised rather than dismiss them. I also wasn't "making a point about words" but rather the fields I mention here. Perhaps I should have been more explicit about that.
Anyhoo... syntactic recall as a proxy of a practical skill always seems doomed to produce inaccurate results. A job is not like an interview, in many ways. Where does that leave us? It feels that we should be able to interview people in order to separate the suitable from the unsuitable. Perhaps that's not the case, and we're deluding ourselves. I'm reminded of Daniel Kahnemann and the Israeli army recruiting procedure: http://www.businessinsider.com/daniel-kahneman-on-hiring-dec...
This... a thousand times this!!!
I think it is very reasonable to answer "you know, I don't know the answer but I can find it quickly using [google|man|stackoverflow|a book|etc]" to a technical interview question for which one does not have the exact answer.
Of course, being able to find it isn't everything - you also need to be able to understand, evaluate and apply what you find. But it is a step in the right direction, and given the wide scope of what developers/engineers must understand these days, I think a totally reasonable consideration.
I think it is very reasonable to answer "you know, I don't know the answer but I can find it quickly using [google|man|stackoverflow|a book|etc]" to a technical interview question for which one does not have the exact answer.
Of course, being able to find it isn't everything - you also need to be able to understand, evaluate and apply what you find. But it is a step in the right direction, and given the wide scope of what developers/engineers must understand these days, I think a totally reasonable consideration.
anytime I hear an Einstein story I assume it's made up.
This is my rule too. I actually use the stronger rule which is anything attributed to anyone famous was not ever said by them.
Well, he also said that imagination is more important than knowledge...
I can't agree with this article more. It's like the author read my mind. I have programmed in perl, C, C++ in linux, VC++ & COM, python, JAVA, JS, VB, assembly language, Prolog, Lex, Yacc. I am sure I missed a few in this list. I think of problems in abstractions and when I think of syntax/semantics its almost a vague haze a mix of libraries of various languages. Dont get me wrong, once I start programming in a particular language, I am in the "zone" so to speak. But I think I need Google too often.
All I can say is that I've never regretted spending too much time looking for more information, on the web or otherwise, but I've frequently regretted not spending enough time after re-implementing someone else's mistakes for the past several hours/weeks/whatever. It's the lesson that keeps on giving.
[Not that I'd call myself an experienced programmer, but I'd say the same is true of scientific research and many other things.]
[Not that I'd call myself an experienced programmer, but I'd say the same is true of scientific research and many other things.]
Sometimes I force myself to think for ~5 seconds to recall a functions name. I usually end up feeling that it would've been quicker to just google it.
When I was first learning, I googled everything.
When I grew comfortable, I took pride in my ability to look up the reference docs myself and figure out the correct solution.
When I grew comfortable with that, I googled everything because it was a lot faster.
When I grew comfortable, I took pride in my ability to look up the reference docs myself and figure out the correct solution.
When I grew comfortable with that, I googled everything because it was a lot faster.
Me too, but I have decided to never cease to learn, so I am stuck in step (1) :D.
I wonder if you had enough electrodes or some BCI monitoring your thoughts before during and after a Google search and then that was used to train a deep learning system (probably specific to you) then you could get the answer before you start typing into Google, basically automatically.
Perhaps I am in a minority because I am currently involved in research / academia, but I find I am using Google less and less as time goes on. This is not meant specifically to be a dig at Google, nor am I saying I go without; however, it really isn't as useful to me now as it was when I first started programming.
The reason for this, I believe, is that I am less and less interested in the broad range of answers Google often returns. Sure, you can easily find an answer on StackOverflow as to why Visual Studio is giving you a LNKxxxx error at compile time, but this has limited utility (in my experience). As time has gone on, I find myself searching Github, API documentation / wiki's, and most importantly, my University library. I vastly prefer reading real code alongside documentation than to just get an answer. Sure, I memorize the easy things, like how to get the length of an array in Javascript or which library to import to access vector-fold in Scheme, and that's fine if you're able to do it (if you Google this information, you likely work with more than 3 languages per day or per week). Instead, I find myself searching for answers in 1) other implementations 2) documentation of that implementation, and 3) in the original work documenting the theory or concept (papers, journal articles, textbooks).
Certainly, I think it's okay to Google something, or just search in general. But as time has gone on, the value of my University's library, as well as specific documentation and the availability of open-source implementations of most general purpose materials / paradigms has made my life infinitely easier (and hell, possible). While I value what's possible to find on today's search engines, often times dedicated resources really are the best way to go over the much more broad search engine Google provides.
Note though, that despite this, I do realise that much of these "specialized resources" were discovered through Google, so perhaps I am in circles on this one.
The reason for this, I believe, is that I am less and less interested in the broad range of answers Google often returns. Sure, you can easily find an answer on StackOverflow as to why Visual Studio is giving you a LNKxxxx error at compile time, but this has limited utility (in my experience). As time has gone on, I find myself searching Github, API documentation / wiki's, and most importantly, my University library. I vastly prefer reading real code alongside documentation than to just get an answer. Sure, I memorize the easy things, like how to get the length of an array in Javascript or which library to import to access vector-fold in Scheme, and that's fine if you're able to do it (if you Google this information, you likely work with more than 3 languages per day or per week). Instead, I find myself searching for answers in 1) other implementations 2) documentation of that implementation, and 3) in the original work documenting the theory or concept (papers, journal articles, textbooks).
Certainly, I think it's okay to Google something, or just search in general. But as time has gone on, the value of my University's library, as well as specific documentation and the availability of open-source implementations of most general purpose materials / paradigms has made my life infinitely easier (and hell, possible). While I value what's possible to find on today's search engines, often times dedicated resources really are the best way to go over the much more broad search engine Google provides.
Note though, that despite this, I do realise that much of these "specialized resources" were discovered through Google, so perhaps I am in circles on this one.
If you mainly look up documentation, DevDocs[0] is a great app to use. It's browser based, but you can make it offline.
[0]: http://devdocs.io/
[0]: http://devdocs.io/
Very nice, thanks!
If I'm using a language and platform that I'm very used to, then not very often. In that case, I'd only use Google if I hit a weird bug in the platform that I haven't seen before or wanted to use a new capability.
When I'm just starting out on a new platform I'll Google a lot though. I find it's good to keep a blog of everything with a new platform that took more than an hour to figure out.
These days, there's a definite lack of appreciation for rote learning of frequently used information.
When I'm just starting out on a new platform I'll Google a lot though. I find it's good to keep a blog of everything with a new platform that took more than an hour to figure out.
These days, there's a definite lack of appreciation for rote learning of frequently used information.
More often than Bing?
In the olden days you had to write a lot more stuff from scratch. This would be in a language that could be explained in a relatively concise manual. So everything you would need would be in that manual.
You could learn from things others did with the same manual/hardware by seeing the end result, but the art required for that result wasn't open source, you would have to work it out yourself and RTFM as often as needed. Magazines were as good as it got.
The knowledge to program wasn't easily obtained, for starters computer kit could cost many thousands. Computers weren't really networked back then either. Floppy disks were the distribution medium. Also computer screens actually flickered in glorious 1024 x 768. Plus they were noisy. You read your code in printouts side by side with the manual, probably hand-writing code before typing it in.
Back then it must have been possible for someone to actually know a language such as 'C' (or BASIC, or an 8 bit assembly language) completely as in know all the commands and understand all the concepts. This would be learning by rote to a certain extent as the 1-2 manuals would be memorised to all intents and purposes. I don't know if that sort of mastery of a subject is easier to obtain today.
In the olden days you had to write a lot more stuff from scratch. This would be in a language that could be explained in a relatively concise manual. So everything you would need would be in that manual.
You could learn from things others did with the same manual/hardware by seeing the end result, but the art required for that result wasn't open source, you would have to work it out yourself and RTFM as often as needed. Magazines were as good as it got.
The knowledge to program wasn't easily obtained, for starters computer kit could cost many thousands. Computers weren't really networked back then either. Floppy disks were the distribution medium. Also computer screens actually flickered in glorious 1024 x 768. Plus they were noisy. You read your code in printouts side by side with the manual, probably hand-writing code before typing it in.
Back then it must have been possible for someone to actually know a language such as 'C' (or BASIC, or an 8 bit assembly language) completely as in know all the commands and understand all the concepts. This would be learning by rote to a certain extent as the 1-2 manuals would be memorised to all intents and purposes. I don't know if that sort of mastery of a subject is easier to obtain today.
I usually force myself to use the documentation of a Language/Framework/Library/etc. with a tool like Dash[1], because I don't always have Internet Access.
I try to restrict myself to use google only for troubleshooting.
[1] https://kapeli.com/dash
I try to restrict myself to use google only for troubleshooting.
[1] https://kapeli.com/dash
On any given day I use any combination of the following languages: Ruby, Python, JavaScript, CoffeeScript, Haskell, Bash.
If I could remember how each language handled list operations and JSON/Base64 encoding I could probably code much faster, but the real efficiency gain wouldn't come until I stop reading HN :P
If I could remember how each language handled list operations and JSON/Base64 encoding I could probably code much faster, but the real efficiency gain wouldn't come until I stop reading HN :P
I've joked that if I only had a small program that would take my compiler errors, grab the important part (especially when C++ pukes a mountain of text) and automatically feed it into Google, my productivity would take a huge jump.
Now I'm wondering if there's a business model for it.
Now I'm wondering if there's a business model for it.
I have often wanted something similar for comments. Before I write a new function I write the comment of what it is supposed to do and what it returns. For fun I sometimes copy and paste the comment into Google to see what other people have written. It would be great to have a side window showing all the Google matches to your comment as you are writing it.
Google is obviously missing a trick. Instead of working as a search engine, it should work as an online compiler and code repository.
Then it could apply machine learning and AI to predict code before it's typed.
Maybe Google Code was an early prototype?
I regularly wonder how much code is repeated effort. I get the impression that some very non-trivial percentage of global business effort is thousands of different developers writing their own versions of code that does the same few things - especially in web land.
For some reason frameworks seem to make this problem worse instead of fixing it.
Then it could apply machine learning and AI to predict code before it's typed.
Maybe Google Code was an early prototype?
I regularly wonder how much code is repeated effort. I get the impression that some very non-trivial percentage of global business effort is thousands of different developers writing their own versions of code that does the same few things - especially in web land.
For some reason frameworks seem to make this problem worse instead of fixing it.
I think it's all repeated code now.
The moment I get an error the first thing that crosses my mind is "someone has had this problem before, I just need to find the forum where they discussed it."
The moment I get an error the first thing that crosses my mind is "someone has had this problem before, I just need to find the forum where they discussed it."
Memorizing documentation and obscure bash tricks is the last thing a developer should be expected to do.
Even reading the documentation (in its 'raw' form) can sometimes be harmful, because you miss out on the contextual information that a search engine provides. Especially if you're new to a language or domain, it's easy to fall victim to the XY problem [0] - you comb the docs trying to implement your perceived solution, when a simple Google search or Stack Overflow answer would give you the solution you're really looking for in seconds.
If something is important to you, you'll absorb it over time anyways.
[0] http://www.perlmonks.org/?node=XY+Problem
Even reading the documentation (in its 'raw' form) can sometimes be harmful, because you miss out on the contextual information that a search engine provides. Especially if you're new to a language or domain, it's easy to fall victim to the XY problem [0] - you comb the docs trying to implement your perceived solution, when a simple Google search or Stack Overflow answer would give you the solution you're really looking for in seconds.
If something is important to you, you'll absorb it over time anyways.
[0] http://www.perlmonks.org/?node=XY+Problem
Over 30 years in. My second monitor is for google search when it's not moved due to multiple putty sessions overflowing the first :)
I still have my original Kernighan and Ritchie. When I went to the bookshop there where two books, K&R and a Byte book on C. I used to remember many of the pages numbers of things I looked up a bit. Next I moved on to help files. I made my own CHM files or scabbed them.
Now we have google, why not. I agree with the point. I use python all day now but still do a bit of JS and use google for the same things, size, len, .len(), .size, len(x).
This is how we rolled: https://goo.gl/photos/VRyNYQMyVLxJjYVq7
This is how we rolled: https://goo.gl/photos/VRyNYQMyVLxJjYVq7
I don't even bother committing some easy stuff to memory. Living in a polyglot environment, there's just too much going on to worry about the little details that Google and StackExchange can give me in a moment.
I feel the same way. It worries me that it may come back to haunt me in an interview environment where the fact that you don't have something in RAM could make you look incompetent, when in fact it's just a conscious choice on where you are going to store your knowledge.
Have to disagree with this. If you live and work in a language for a timescale measured in years, you're just going to know that certain things "look weird" compared to others. Example: almost everything in Ruby is a member function of an object. You don't do len(x) in Ruby (that's a Pythonism) because Ruby (and its intellectual parent, Smalltalk) are on the whole more hardcore about OO than the Python/C/ALGOL family.
On the other hand, I agree that a lot of "programming" today doesn't require deep competence, and that languages can be learned. But there can be value in knowing something really well vs. having a mere passing understanding.
On the other hand, I agree that a lot of "programming" today doesn't require deep competence, and that languages can be learned. But there can be value in knowing something really well vs. having a mere passing understanding.
Grep was my google in the old days.
I kept a library of code I liked or found useful. For example, a bunch of nicely written code on SGI's that came free by guys like Paul Haeberli was quite useful say if looking for opengl examples.
I kept a library of code I liked or found useful. For example, a bunch of nicely written code on SGI's that came free by guys like Paul Haeberli was quite useful say if looking for opengl examples.
I miss the days where you could become an expert in one language and work completely offline. Things have changed so much though, with everyone expected to be "full stack" and have a working knowledge of a wide variety of constantly changing APIs. Now, having n years experience in one language no longer seems relevant. Your value comes from your ability to understand requirements and marry different pieces of technology together. I don't feel as smart having to constantly look things up.
There are still jobs like that; right now, Indeed.com has 2000 COBOL jobs offers. I wouldn't trade it, though.
If you never have to look anything up, you're likely not actually getting better. The last thing a developer can afford is to stagnate for extended periods of time (i.e. years rather than weeks).
The likelihood that you already know everything there is to know about your niche and that you will be able to stay in only that niche for your entire career is extremely low.
The likelihood that you already know everything there is to know about your niche and that you will be able to stay in only that niche for your entire career is extremely low.
To quote a great hacker, Joe Armstrong, ``The reason we write code is because we can't find it on Google.''
One thing I appreciate about good autocomplete like Intellisense is that for problems like the length example, I can guess and confirm with the autocomplete even faster than going to another window and googling it. Even lets you know if it's a function or member.
All this raises an interesting question: what tools does Google offer it's developers ,to search for help and code ? is it better than what we've got ?
Also ,the same goes for tools for patents and engineering knowledge search.
Also ,the same goes for tools for patents and engineering knowledge search.
You can see a public version running on the Chromium source here [1], which is pretty nice. Notice that it understands symbols and so forth, which essentially involves building/compiling all the code. I think it is ahead of what you'll get elsewhere, at least for C++.
https://code.google.com/p/chromium/codesearch#/
https://code.google.com/p/chromium/codesearch#/
I develop android apps and use Google to catch device specific bugs ie the mention of bugs and workarounds that way I only have to pay for one android device rather than have about 25 devices
A lot.
Simply because it's impossible to remember everything unless you use it on a day to day basis. Every useful link I find is tagged and stored in a repository for future use.
Simply because it's impossible to remember everything unless you use it on a day to day basis. Every useful link I find is tagged and stored in a repository for future use.
I write PHP and javascript for a living and C# and C++ for fun and school, so in my experience, a lot.
Google is my hive-mind.
Stack Overflow* is where I find the most real answers.
* and sister sites like programmers.stackexchange.com
Stack Overflow* is where I find the most real answers.
* and sister sites like programmers.stackexchange.com
wasting time remembering the unimportant fine details is a sign of a bad programmer imo.
good programmers use software to make themselves better and google is a very reliable alternative to excessive memory (but not understanding, or problem solving skills)
good programmers use software to make themselves better and google is a very reliable alternative to excessive memory (but not understanding, or problem solving skills)
Very rarely. In general, we use DuckDuckGo.
Well, from my perspective, it was! It was a horrible pain! Sometimes you'd spend way too much time debugging a simple error or looking up in some magazine that you are sure you read somewhere a statement that you are pretty sure would help you out in this particular scenario. Oh, it was tedious.
On the up side, at the time I didn't use nearly as many complex technologies as I use today. Quite literally today I have written in Java, a bit of Ruby, a bit of Perl, and some bash. If we expand out to this week we can add in HTML, CSS, Javascript, and SQL. Back when I started I used Basic for long stints, or C for long stints, and that was it!
Google (or in my case DuckDuckGo), StackOverflow, and the like are AMAZING. I am grateful every time I get to use one of them to help me quickly solve a problem and move on to the exciting part, which for me is making working software.