How Much Does an Experienced Programmer Use Google?
two-wrongs.com
two-wrongs.com
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.
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.
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.
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?
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...
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.
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.
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)
i,n = 1, 50
while i < n:
doSomethingElse(i)
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. :)
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 had help files and terrible books. :P
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.
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.
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.
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".
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.
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.
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.
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.
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.
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?"
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 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.
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.
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.
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...
[Not that I'd call myself an experienced programmer, but I'd say the same is true of scientific research and many other things.]
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.
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.
[0]: http://devdocs.io/
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.
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 try to restrict myself to use google only for troubleshooting.
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
Now I'm wondering if there's a business model for 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.
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."
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.
This is how we rolled: https://goo.gl/photos/VRyNYQMyVLxJjYVq7
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.
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.
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.
Also ,the same goes for tools for patents and engineering knowledge search.
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.
Stack Overflow* is where I find the most real answers.
* and sister sites like programmers.stackexchange.com
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)