Yes and no. I'm a co-founder of http://devbootcamp.com so I see this every day in the context of people learning to be programmers.
"The best programmers I know understand how to architect and build large projects piece by piece. They can focus on the macro because don’t get hung up in the pieces. They know how to use Google to find solutions fast. DRY."
I agree with the first and second bit and strictly speaking the third. That is, when students first watch me code they're surprised both that I'm looking up this-or-that ActiveRecord method and at the speed with which I do it. They assume expert programmers have a book of magic spells they've memorized, so to see what I haven't in some ways makes it more magical.
What am I doing, then, if not memorizing every last little thing? What makes me a "better" programmer?
The key to becoming a non-beginner are the first two bits, not the third. It's developing that filter experts have which separates relevant information from irrelevant information. Lots of beginners use Google in a backwards sort of way, having been trained to "look for the solution." Google is like the great universal answer key for them.
It can't be about memorization, then. Being an expert is more like having this amazing compression algorithm at your disposal and we can evaluate very quickly whether some piece of information is compatible with that compression algorithm.
It's made worse by the fact that they see experts do it, sometimes. Or worse, that experts tell them, "I use Google all the time, you should, too." But Google is worse than nothing if the beginner finds code, copies it blindly into their project, and shuffles characters around until it does what they want. They are robbing themselves of the opportunity to abstract out common patterns, recognize similar problems in different guises, and generally setting an impossible bar of having to memorize too much.
Lots and lots of students have been trained to see software development as THAT.
It took me the best part of the weekend to drill twelve holes for curtains - because it is not enough to Google for the answers.
Now, if you knock on a wall and it sounds hollow - you just google for hollow wall fixings. Great. I'll go buy some of those.
Drill into the wall. And hit brick behind the plaster.
Err... Ok they have invented a new type - dry lined Walls. The gap is so small my umbrella fixings cannot open up behind the board.
So I will get longer screws to go in the wall. But now my masonry drill slips on hard stones and gouges chunks from the plaster. Try harder - is that smoke coming from the drill? Eventually I find a consultant ( in the DIY store)
Aha - it's not masonry drill bits you need - you need aggregate drills. And a new drill.
Eventually I bought new drill bits, a new drill, six inch screws and I can do chin ups on the damn things.
The lesson
1. Until you understand the fundamentals of the problem, you will make poor choices time and again. Google correctly told me where to buy masonry drills and plasterboard fixings. It did not know to ask if I had the right walk for that.
2. New technology changes "embedded knowledge" - I learnt to drill brick walls from my father, But new ways of using the old can change everything.
3. Hire a professional while you go and do revenue generating work.
But they key to becoming a non-beginner are the first two bits, not the third. It's developing that filter experts have which separates relevant information from irrelevant information. Lots of beginners use Google in a backwards sort of way, having been trained to "look for the solution."
It's not about memorization, then, it's about this compression algorithm we call "being an expert."
I think this goes pretty much for everything that you do using Google, not just programming. I do some on-site user support on the side, fixing end user PC problems. Most people watching me over my shoulders are usually shocked to see that I have to Google the solutions for most problems.
Once the shock wears off, they are actually fascinated by how I seem to be able to instantly filter between relevant and non-relevant content and search results. Some even tell me that they've Googled for hours for a problem that people who have this "filter" ability can probably find a solution for in under a minute...
Correct. If I'm understanding you, I'd summarize the distinction as follows:
Google should be used as a reference. It should not be used in place of educated judgement.
This goes along with the ideology that you should not trouble yourself with monkey-memorization. When learning to program (for instance), concepts are far more important and useful, as you are constantly faced with making educated decisions. Decisions should not be made based on reference material alone.
I really agree with this analysis of the OP. It is pretty interesting to notice that as you watch other programmers you are teaching look for things on Google. That filter comes probably out of more and more googling combined with more and more programming to see which posts lead to a good solution.
Sorry for being off topic, but what resources would you recommend to someone who wants to learn everything that is taught in dev bootcamp but cant attend?
This is something that bugs me about whiteboard-style interviews - they test almost none of the typical day-to-day aspects of programming. Without Google, without docs, without a REPL, without the code-run-debug cycle, how is it that you think you're assessing how effective I am in real life?
EDIT: not to mention that you're also not testing me for one of the most important abilities of a coder in a software shop: how well I learn new things.
A good whiteboard interviewer will be those things for you. And language details are less important -- "well, let's both agree a for loop has this syntax for now"
Is anybody going down the path of giving the candidate X hours yo complete a project, shoe iterations via source control history, showcase documentation and the overall build - plan? I would think you'd find the high performers easier in this light.
Not being a programmer by day but proficient in bash and Python I was in an interview last year where the person asking the questions did just not get it. In one example he asked me to count the number of files that had a specific string in the name. I excluded the file descriptor based on his ask. So, he said I got it wrong. I explained the way it was presented I was making the problem harder, and more exact, but he wouldn't budge. The point being, I could easily do what he asked, but wasn't actually measured on that.
Having gone through a handful of whiteboard-style interviews recently, I found that the opposite is true. If you can't remember the interface for hash tables in Java, for example, they usually let you make one up that you think makes sense. If you can't remember that "=" means assignment or that for loops need curly braces around them, you'll be in trouble, of course, but they'll help you with the details.
When it comes to REPL and the code-run-debug cycle, they usually ask you to explain how to code would run to them step-by-step, which simulates having a computer run it. They do the same and pipe up if you miss something. So it's not the same as running the code, but it's similar enough and it also shows how well you understand the code you're writing.
I do think that the major flaw of whiteboard interviews is that it does not show a programmer's ability to organize large amounts of code. In most programming, you won't be solving logic puzzles as much as organizing several parts and sticking them together. The organization is far more important in the long run than the individual code itself, especially since the code will likely be changed later on (which is made easier if it is well organized).
One of the most effective coding interviews I ever had involved giving bringing in my own laptop and mirroring it on an external monitor. I was asked typical "whiteboard" questions, but I was able to program in the style I've grown accustomed. This accomplished both the typical negative-filter (fizzbuzz) as well as enabling me to build something higher level and more complex than typically posssible during a 1hr interview.
I've always believed this, of course then I worked at a company that wrote it's own programming language for it's product, and there was nothing to Google for (I still don't understand why they did this but stay with me).
In that environment, you learn quickly what skills separate a good programmer from a bad one. The traits I found the most useful:
-Learning speed (ability to quickly grasp a completely foreign concept)
-Creativity (without a template of how others do it, you are the trail blazer)
-Patience, because the really bad programmers wouldn't even try, they would curse it as stupid and leave or get someone else to do the work.
Surely the programming languages, libraries, and platforms you were using had documentation. It's not the point whether you are using www.google.com, mycompanyintranet.com/wiki, or yelling across the room to ask a question.
By the way, the three attributes you just stated are what makes anyone good at almost anything.
"The best doctors are the quickest to Google."
"The best scientists are the quickest to Google."
"The best engineers are the quickest to Google."
Are the above statements true? Quite possibly. I would argue that the best in their fields are those writing the answers that are indexed by Google to be found by others.
However, usually the best in their fields are also good at using Google. Unfortunately, the worst in their fields also use Google extensively, so it's not a strong signal.
EDIT: My definition of "best" is admittedly very subjective. The author could define "best" as "most effective", for exmaple. My only point is that you shouldn't use Googling to determine who is "best" because the "worst" also can be quick to use Google. It's a useless signal. More situationally appropriate metrics should be used instead.
True story, but it's not just being the first to do a google search. From personal experience I've also seen that how you use google and what variants of your search terms you can come up with that make the biggest difference in getting to the right answer/method.
The problem is: when you get to a certain level of skill, or are working on very obscure problems, or are working with hightech (even yet-to-be-released) stuff, not even google will help you anymore. That's where how good of a programmer you really are comes into play.
Additionally, you need the skill and knowledge to be able to tell a good solution from a bad one in the many results you'll get back from a given search.
So...if you're working on a really obscure problem, I'd consider you a researcher before considering you a programmer. (Or perhaps a programming researching). That skill set is immensely different from the standard programmer's skill set. Google skills are still vitally important, but interpreting the results quickly become the dominating factor when you're doing something no one has done before.
I agree. Those that know the right questions to ask are those that understand their problems, understand their deficiencies, and are just looking for a targeted piece of knowledge that they may be missing.
I couldn't help but read this and think about technical interviews that involve the candidate being asked to write code on a whiteboard - no Google, no code linting/hinting/completion etc.
I'm very much in favor of candidates being asked to write some code under more realistic conditions, including finding solutions to parts of the exercise online. Of course, they should then be able to explain to the interviewer(s) why they chose a particular solution and walk the interviewer through the code they borrowed/adapted.
Agreed. Nowadays in technical interviews, I make it a point to say that I would google the problem. Not googling just because it's an interview is exactly the kind of thinking that gets people stuck on real problems -- i.e. inside the box, instead of outside the box thinking. If you were given a real problem, would you limit your problem solving approaches to those implied by the context? That's exactly the kind of person I don't want to hire.
While this may be good for code under 100 lines, anything more requires using Google. Either it be simple trivial things like email regexp (for those who don't have the luxury of having premade libraries for them) or harder things like algorithms.
It depends on what you're working on. If you're working at the cutting edge, you will find that Google often doesn't have the answers you need... simply because they aren't out there.
To be honest I completely agree with the quote. The most important thing should be the ability to reason about Computer Science and programming.
On the other hand, I've written and implemented tons of Algorithms and DTs for the sole purpose of learning. I have a lot of accumulated toy code.
"So unless you’ve already memorized that sorting algorithm by heart, why in the world would you want to spend 2 hours trying to figure it out yourself? "
For the sake of learning. I may not memorize the entire code of merge sort but I will sure as hell know how the merge procedure is implemented. Additionally you develop a feel and intuition for it. However, when it comes to showing off your coding skills I would recommend building useful apps, I doubt any employer is going to be impressed about toy code that implements DFS.
I think the article has an implied context of "for work."
Implementing data structures and algorithms is a great way to learn about them and to get better at programming. But in the context of work, where I need to get stuff done, I'm not going to implement a low level algorithm if I don't need to - I'm looking for a pre-built solution in the standard library, or heading to a search engine to find a third party library.
That's not to say some training time at work isn't a good idea, but it'd be silly for a person's business to fail because they got caught up implementing all of their low level data structures for coding practice.
What was life like before Google? Sure there was documentation, and code comments, and senior devs you could ask. But surely that was less than Google? Or perhaps the scale of problems were less vast compared to now, so the amount of info you would get by Googling now was unnecessary back then.
This seems like a controversial topic. Some people seem to think that if you don't know something code specific without Googling than you're something like a Duct tape programmer (although I may be stretching the term away from what Joel talks about http://www.joelonsoftware.com/items/2009/09/23.html). Being a college student it's interesting to see articles like this, that I agree with, and then hearing from my professors "anyone can google you can never be a good _computer scientist_ if that's all you do!"
Your googling skill plays a big part in problem solving, and most of the time you are required to know what exactly is your problem.
I personally google stuff a lot when building a side project, I dont google for solution for a given problem, this is where your programming skills come in . You need to know what exactly you are looking for to get the correct answer from google. It cant be a blanket statement ("parse data from json"). Most of the time the answer is split across multiple sites and which you put together n solve your problem.
Re framing this a little- "The best programmers are the quickest to discover things".
When I was a kid, and when I first heard about open book exams I was amazed. Well if they allow you to carry your textbook to the exam hall you should ace through the exam through flying colors, right?
Not quite, later when I studied the question paper I realized it was so framed, that the test was not to copy the facts from the textbook and answer as such. But the questions were basically problems and you will be forced to look up the text book as a reference with your own problem solving ability being the core test being tested here. In such cases it makes far more sense, to simply allow the person to carry the textbook to the exam hall.
Its easy to get access to a textbook/google/documentation/manual/whatever. And spending your effort to remember facts is a waste of time and energy which are often in short supply. Now extending this same philosophy, what if the solution patterns to large number of problems is readily available?
In such a case it makes more sense to focus on a) Quantity of problems one can solve b) Quality of problems one can solve. Instead of learning the solutions to the problems, use the solutions to do something big, or use the solutions to do a lot of things.
If you are wondering why the CS illiterate guy next to you is as equally productive as you who has read some thousands of pages of CS literature, its because when solutions are available easily and for cheap- Putting everything in your brain is a pointless exercise.
Alan Kay: in programming there is a wide-spread 1st order theory that one
shouldn't build one's own tools, languages, and especially
operating systems. This is true—an incredible amount of time
and energy has gone down these ratholes. On the 2nd hand, if you
can build your own tools, languages and operating systems, then
you absolutely should because the leverage that can be obtained
(and often the time not wasted in trying to fix other people's not
quite right tools) can be incredible.https://docs.google.com/viewer?url=http://www.vpri.org/pdf/m...
A professor in college might allow the class have an open book exam, however you still see a number of people who might not pass that exam. Why? Well, there were two kinds of people in that class:
1. The smart ones who actually know the material.
2. The others who know nothing about what had been taught so far in the class.
The students in the first category will pass the exam but the second crowd perform poorly, because even though the book is in front of them, they don't know what to look for, especially in a timed test.
So the way I see this is that googling will help those who already have knowledge of the programming concepts, not those who have no idea of what they are trying to implement at all. In reality those who can use google to get what they want can also figure it out without google, even though it might take longer of course.
Microsoft recruiters are doing their rounds for Seattle, and I was just asked over the phone how I would implement a quick sort. The answer I wanted to give would have been something like this blog post. As a developer I would never waste valuable time trying to roll my own version of an algorithm that's probably available on Wikipedia and optimized for every programming language imaginable. I guess what they were looking for was some buzz words like "divide and conquer" and "big oh n log n time". I understand interviewing community college graduates with no experience like this, but young adults with 6 years of SE behind them? Ridiculous.
I'd implement a Quicksort by checking within the existing codebases that I had access to and that were in the same language to see if it had already been done, then patch what I found to match my needs for comparisons, etc.
Note: one big reason for this is licensing - if it was developed in-house, odds are that licensing issues are a non-factor but if it came from "The Internets" then life may get strange. Strange is bad.
This has side effects. In my case I was becoming more and more lazy and never bothered thinking about the problem properly and taking a chance at coming up with a solution. I became expert at search and finding solutions. Ex search: 'display uitableview in a grid view' came up with lots of libraries... I did end up using one of them. But I wish I took sometime to do it myself or at least try to understand how this library is working. As I continue to use more and more libraries I realized I was becoming more lazy and more prone to searching for solution as first thing rather than giving my brains a chance. I felt dumb...
You want to spend your day solving problems. OK cool. Which ones? All of them?
In terms of work efficiency, you generally want to focus quite tightly on a specific part of the solution space. The part which adds value and is novel or advances the state of the art.
Everything else is fodder for judicious library use, outsourcing to third-party services, and occasionally recipes or gists.
Google is just the user-interface for code re-use in 2013.
On the other hand, recreationally, why yes I do enjoy inventing a better wheel from time to time :)
Doing that occasionally between projects, or regularly on your own time (a.k.a. sharpening your saw) is essential to improving as a programmer
But in the context of programming as a job (which is the topic of the post), if one repeatedly spends hours solving already solved problems simply because "one enjoys it", it's a waste of the team's time.
[using old-fashioned "one" here instead of "you" not to make it personal]
I agree, the pleasure is arriving at the solution yourself. That's why CS is so appealing to so many people. It's fun and when you correctly solve a tough technical problem you feel great.
I'm glad I finally saw someone say this. It seems like we're a dying breed: those of us who got into CS for the sheer enjoyment of solving problems. Making fancy things happen on the screen is simply a positive side effect for us. I abhor that development these days is 90% Googling shit and 10% actual creativity. I go out of my way to keep my day job interesting.
Before I really started coding I worked in electronics (designing mixed-signal design kits at the semiconductor level) and I remember I used to judge programmers by how much "better" at google they were than me. Since I've switched over and become a full-time coder (and co-founder which is a whole different exercise) I have become far better at searching for solutions to my problems than I was in the past. That being said I don't think it's the fact that I default to searching that makes me a good programmer. I think it's like some of the other comments have mentioned, the ability to filter what information is useful or not quickly and then apply and test the useful information so that you do not have to re-derive every action. This has led me down a rabbit-hole a few times where I would be testing different solutions when just building it myself would have been much faster, but overall I definitely think it is part of what makes me work at the speed at which I do.
I'm reminded of Mathematics from college. When first learning something it's difficult and simply seeing the solution won't improve your ability to recognize it. But once you figure it out once, you may not immediately remember how to apply it when faced with a similar problem, but recall is very quick because your brain has already wired the pathways of understanding.
I Googled "how to handle error messages in php" for your co-founder and came up with this http://www.w3schools.com/php/php_error.asp, since clicking on the "Get an invite" button (on https://framebase.io) while leaving the email field blank throws an exception error:
Error:
exception 'Exception' with message 'MDB2 Error: null value violates not-null constraint, _doQuery: [Error message: Could not execute statement]
[Last executed query: EXECUTE MDB2_STATEMENT_mysql_8edec1a3e8682362d38c86df48ba2cd8 USING @0, @1]
[Native code: 1048]
[Native message: Column 'email' cannot be null]
[+] [-] jfarmer|13 years ago|reply
"The best programmers I know understand how to architect and build large projects piece by piece. They can focus on the macro because don’t get hung up in the pieces. They know how to use Google to find solutions fast. DRY."
I agree with the first and second bit and strictly speaking the third. That is, when students first watch me code they're surprised both that I'm looking up this-or-that ActiveRecord method and at the speed with which I do it. They assume expert programmers have a book of magic spells they've memorized, so to see what I haven't in some ways makes it more magical.
What am I doing, then, if not memorizing every last little thing? What makes me a "better" programmer?
The key to becoming a non-beginner are the first two bits, not the third. It's developing that filter experts have which separates relevant information from irrelevant information. Lots of beginners use Google in a backwards sort of way, having been trained to "look for the solution." Google is like the great universal answer key for them.
It can't be about memorization, then. Being an expert is more like having this amazing compression algorithm at your disposal and we can evaluate very quickly whether some piece of information is compatible with that compression algorithm.
It's made worse by the fact that they see experts do it, sometimes. Or worse, that experts tell them, "I use Google all the time, you should, too." But Google is worse than nothing if the beginner finds code, copies it blindly into their project, and shuffles characters around until it does what they want. They are robbing themselves of the opportunity to abstract out common patterns, recognize similar problems in different guises, and generally setting an impossible bar of having to memorize too much.
Lots and lots of students have been trained to see software development as THAT.
[+] [-] lifeisstillgood|13 years ago|reply
It took me the best part of the weekend to drill twelve holes for curtains - because it is not enough to Google for the answers.
Now, if you knock on a wall and it sounds hollow - you just google for hollow wall fixings. Great. I'll go buy some of those.
Drill into the wall. And hit brick behind the plaster. Err... Ok they have invented a new type - dry lined Walls. The gap is so small my umbrella fixings cannot open up behind the board.
So I will get longer screws to go in the wall. But now my masonry drill slips on hard stones and gouges chunks from the plaster. Try harder - is that smoke coming from the drill? Eventually I find a consultant ( in the DIY store)
Aha - it's not masonry drill bits you need - you need aggregate drills. And a new drill.
Eventually I bought new drill bits, a new drill, six inch screws and I can do chin ups on the damn things.
The lesson
1. Until you understand the fundamentals of the problem, you will make poor choices time and again. Google correctly told me where to buy masonry drills and plasterboard fixings. It did not know to ask if I had the right walk for that.
2. New technology changes "embedded knowledge" - I learnt to drill brick walls from my father, But new ways of using the old can change everything.
3. Hire a professional while you go and do revenue generating work.
[+] [-] mobweb|13 years ago|reply
I think this goes pretty much for everything that you do using Google, not just programming. I do some on-site user support on the side, fixing end user PC problems. Most people watching me over my shoulders are usually shocked to see that I have to Google the solutions for most problems.
Once the shock wears off, they are actually fascinated by how I seem to be able to instantly filter between relevant and non-relevant content and search results. Some even tell me that they've Googled for hours for a problem that people who have this "filter" ability can probably find a solution for in under a minute...
[+] [-] prawks|13 years ago|reply
Google should be used as a reference. It should not be used in place of educated judgement.
This goes along with the ideology that you should not trouble yourself with monkey-memorization. When learning to program (for instance), concepts are far more important and useful, as you are constantly faced with making educated decisions. Decisions should not be made based on reference material alone.
[+] [-] janson0|13 years ago|reply
[+] [-] arcadeparade|13 years ago|reply
[+] [-] windexh8er|13 years ago|reply
[+] [-] nollidge|13 years ago|reply
EDIT: not to mention that you're also not testing me for one of the most important abilities of a coder in a software shop: how well I learn new things.
[+] [-] MBlume|13 years ago|reply
[+] [-] windexh8er|13 years ago|reply
Not being a programmer by day but proficient in bash and Python I was in an interview last year where the person asking the questions did just not get it. In one example he asked me to count the number of files that had a specific string in the name. I excluded the file descriptor based on his ask. So, he said I got it wrong. I explained the way it was presented I was making the problem harder, and more exact, but he wouldn't budge. The point being, I could easily do what he asked, but wasn't actually measured on that.
[+] [-] teebs|13 years ago|reply
When it comes to REPL and the code-run-debug cycle, they usually ask you to explain how to code would run to them step-by-step, which simulates having a computer run it. They do the same and pipe up if you miss something. So it's not the same as running the code, but it's similar enough and it also shows how well you understand the code you're writing.
I do think that the major flaw of whiteboard interviews is that it does not show a programmer's ability to organize large amounts of code. In most programming, you won't be solving logic puzzles as much as organizing several parts and sticking them together. The organization is far more important in the long run than the individual code itself, especially since the code will likely be changed later on (which is made easier if it is well organized).
[+] [-] eldude|13 years ago|reply
[+] [-] ultrasaurus|13 years ago|reply
[+] [-] ry0ohki|13 years ago|reply
In that environment, you learn quickly what skills separate a good programmer from a bad one. The traits I found the most useful:
-Learning speed (ability to quickly grasp a completely foreign concept)
-Creativity (without a template of how others do it, you are the trail blazer)
-Patience, because the really bad programmers wouldn't even try, they would curse it as stupid and leave or get someone else to do the work.
[+] [-] benaiah|13 years ago|reply
1: http://www.codinghorror.com/blog/2006/09/has-joel-spolsky-ju...
[+] [-] abraininavat|13 years ago|reply
By the way, the three attributes you just stated are what makes anyone good at almost anything.
[+] [-] codex|13 years ago|reply
Are the above statements true? Quite possibly. I would argue that the best in their fields are those writing the answers that are indexed by Google to be found by others. However, usually the best in their fields are also good at using Google. Unfortunately, the worst in their fields also use Google extensively, so it's not a strong signal.
EDIT: My definition of "best" is admittedly very subjective. The author could define "best" as "most effective", for exmaple. My only point is that you shouldn't use Googling to determine who is "best" because the "worst" also can be quick to use Google. It's a useless signal. More situationally appropriate metrics should be used instead.
[+] [-] SchizoDuckie|13 years ago|reply
The problem is: when you get to a certain level of skill, or are working on very obscure problems, or are working with hightech (even yet-to-be-released) stuff, not even google will help you anymore. That's where how good of a programmer you really are comes into play.
[+] [-] jmvoodoo|13 years ago|reply
[+] [-] cpfohl|13 years ago|reply
[+] [-] amitparikh|13 years ago|reply
[+] [-] gte910h|13 years ago|reply
[+] [-] JohnBooty|13 years ago|reply
I'm very much in favor of candidates being asked to write some code under more realistic conditions, including finding solutions to parts of the exercise online. Of course, they should then be able to explain to the interviewer(s) why they chose a particular solution and walk the interviewer through the code they borrowed/adapted.
[+] [-] jonnytran|13 years ago|reply
[+] [-] zv|13 years ago|reply
[+] [-] dlo|13 years ago|reply
[+] [-] nnoitra|13 years ago|reply
[+] [-] jlarocco|13 years ago|reply
Implementing data structures and algorithms is a great way to learn about them and to get better at programming. But in the context of work, where I need to get stuff done, I'm not going to implement a low level algorithm if I don't need to - I'm looking for a pre-built solution in the standard library, or heading to a search engine to find a third party library.
That's not to say some training time at work isn't a good idea, but it'd be silly for a person's business to fail because they got caught up implementing all of their low level data structures for coding practice.
[+] [-] Apocryphon|13 years ago|reply
[+] [-] SmileyKeith|13 years ago|reply
[+] [-] Pent|13 years ago|reply
[+] [-] why-el|13 years ago|reply
[+] [-] gala8y|13 years ago|reply
[+] [-] vignesh_vs_in|13 years ago|reply
I personally google stuff a lot when building a side project, I dont google for solution for a given problem, this is where your programming skills come in . You need to know what exactly you are looking for to get the correct answer from google. It cant be a blanket statement ("parse data from json"). Most of the time the answer is split across multiple sites and which you put together n solve your problem.
[+] [-] kamaal|13 years ago|reply
When I was a kid, and when I first heard about open book exams I was amazed. Well if they allow you to carry your textbook to the exam hall you should ace through the exam through flying colors, right?
Not quite, later when I studied the question paper I realized it was so framed, that the test was not to copy the facts from the textbook and answer as such. But the questions were basically problems and you will be forced to look up the text book as a reference with your own problem solving ability being the core test being tested here. In such cases it makes far more sense, to simply allow the person to carry the textbook to the exam hall.
Its easy to get access to a textbook/google/documentation/manual/whatever. And spending your effort to remember facts is a waste of time and energy which are often in short supply. Now extending this same philosophy, what if the solution patterns to large number of problems is readily available?
In such a case it makes more sense to focus on a) Quantity of problems one can solve b) Quality of problems one can solve. Instead of learning the solutions to the problems, use the solutions to do something big, or use the solutions to do a lot of things.
If you are wondering why the CS illiterate guy next to you is as equally productive as you who has read some thousands of pages of CS literature, its because when solutions are available easily and for cheap- Putting everything in your brain is a pointless exercise.
What matters is getting things done.
[+] [-] 6ren|13 years ago|reply
Alan Kay: in programming there is a wide-spread 1st order theory that one shouldn't build one's own tools, languages, and especially operating systems. This is true—an incredible amount of time and energy has gone down these ratholes. On the 2nd hand, if you can build your own tools, languages and operating systems, then you absolutely should because the leverage that can be obtained (and often the time not wasted in trying to fix other people's not quite right tools) can be incredible. https://docs.google.com/viewer?url=http://www.vpri.org/pdf/m...
[+] [-] joshualastdon|13 years ago|reply
A professor in college might allow the class have an open book exam, however you still see a number of people who might not pass that exam. Why? Well, there were two kinds of people in that class:
1. The smart ones who actually know the material. 2. The others who know nothing about what had been taught so far in the class.
The students in the first category will pass the exam but the second crowd perform poorly, because even though the book is in front of them, they don't know what to look for, especially in a timed test.
So the way I see this is that googling will help those who already have knowledge of the programming concepts, not those who have no idea of what they are trying to implement at all. In reality those who can use google to get what they want can also figure it out without google, even though it might take longer of course.
[+] [-] alainbryden|13 years ago|reply
[+] [-] fencepost|13 years ago|reply
I'd implement a Quicksort by checking within the existing codebases that I had access to and that were in the same language to see if it had already been done, then patch what I found to match my needs for comparisons, etc.
Note: one big reason for this is licensing - if it was developed in-house, odds are that licensing issues are a non-factor but if it came from "The Internets" then life may get strange. Strange is bad.
[+] [-] xoail|13 years ago|reply
[+] [-] pav3l|13 years ago|reply
I am sure a large portion of HN-ers (myself included) enjoy doing exactly that. I want to spend my day solving problems, not googling shit.
[+] [-] xyzzy123|13 years ago|reply
In terms of work efficiency, you generally want to focus quite tightly on a specific part of the solution space. The part which adds value and is novel or advances the state of the art.
Everything else is fodder for judicious library use, outsourcing to third-party services, and occasionally recipes or gists.
Google is just the user-interface for code re-use in 2013.
On the other hand, recreationally, why yes I do enjoy inventing a better wheel from time to time :)
[+] [-] nandemo|13 years ago|reply
But in the context of programming as a job (which is the topic of the post), if one repeatedly spends hours solving already solved problems simply because "one enjoys it", it's a waste of the team's time.
[using old-fashioned "one" here instead of "you" not to make it personal]
[+] [-] nnoitra|13 years ago|reply
[+] [-] michaelwww|13 years ago|reply
[+] [-] hackinthebochs|13 years ago|reply
[+] [-] spohlenz|13 years ago|reply
[+] [-] vu0tran|13 years ago|reply
[+] [-] ramirez60|13 years ago|reply
I'm reminded of Mathematics from college. When first learning something it's difficult and simply seeing the solution won't improve your ability to recognize it. But once you figure it out once, you may not immediately remember how to apply it when faced with a similar problem, but recall is very quick because your brain has already wired the pathways of understanding.
[+] [-] hotshothenry|13 years ago|reply
Error: exception 'Exception' with message 'MDB2 Error: null value violates not-null constraint, _doQuery: [Error message: Could not execute statement] [Last executed query: EXECUTE MDB2_STATEMENT_mysql_8edec1a3e8682362d38c86df48ba2cd8 USING @0, @1] [Native code: 1048] [Native message: Column 'email' cannot be null]
Executed SQL: INSERT INTO `waitlist` SET `email` = ?, `created_at` = ?;' in /var/www/.submodules/TinyDb/TinyDb/Orm.php:630 Stack trace: #0 /var/www/.submodules/TinyDb/TinyDb/Orm.php(194): TinyDb\Orm::check_mdb2_error(Object(MDB2_Error), Object(TinyDb\Sql)) #1 /var/www/.submodules/TinyDb/TinyDb/Orm.php(165): TinyDb\Orm::raw_create(Array) #2 /var/www/.submodules/Framebase-Models/FSStack/Framebase/Models/Waitlist.php(20): TinyDb\Orm::create(Array) #3 /var/www/Includes/FSStack/Framebase/Controllers/register.php(38): FSStack\Framebase\Models\Waitlist::create('') #4 [internal function]: FSStack\Framebase\Controllers\register->__post_waitlist() #5 /var/www/.submodules/CuteControllers/CuteControllers/Base/Rest.php(25): call_user_func_array(Array, Array) #6 /var/www/.submodules/CuteControllers/CuteControllers/Router.php(28): CuteControllers\Base\Rest->route() #7 /var/www/index.php(47): CuteControllers\Router::start('/var/www/Includ...') #8 {main}
...thought that might help