Hacker News new | comments | show | ask | jobs | submit login
The best programmers are the quickest to Google (framebase.io)
486 points by vu0tran 1694 days ago | hide | past | web | 197 comments | favorite



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.


Let me give a non-programming example.

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.


I cannot upvote you enough - especially on the first point. All the googling in the world is worthless without knowing what to Google for.

The "trick" of expert[^1] programmers is to know the difference, and to slowly expand the base they can build on.

[^1] An expert is merely a person who has learnt from more mistakes. There's nothing magical about it, as much as the cult of the rock star programmer would have us believe otherwise.


And this is the unstated meta problem implied (but usually ignored) in that Einstein quote.

Sure, you don't need to remember anything you can look up in a book (or Google), but you do need to know how to get to the right book again.

Beginners aren't characterised by not knowing how to type queries into Google's search box, it's that they don't know _what_ to type. Being an expert isn't about being able to solve problems without outside knowledge, but it is very much about having enough awareness of a large body of outside knowledge that you've got the right terminology in your head to know what words to start typing into that search box. A beginner trying to format a number as currency is going to spend a lot more time looking than the programmer who knows they just need to type "perldoc -f sprintf" at the command line.


"Sure, you don't need to remember anything you can look up in a book (or Google), but you do need to know how to get to the right book again."

Well, I would actually say you need to know "why" you're looking for said book/solution first. Then after you've found the right book/solution then its a matter of how to get there.

In my case, its all about having a good plan of attack. If you know where you're going, then its easy to Google for that solution to get to the next step in your plan.


I find knowing what to search for isn't that crucial. The brain is a very powerful pattern matching system, so you just look for something vaguely similar and search for that. Those results will virtually always lead you to the right terminology, at least in my experience, at which point you can modify your search query and drill down further.

I suppose learning how to use Google this way is a skill in itself though.


"Good judgement comes from experience. Experience comes from bad judgement." I think Nasrudin?


This is a great point and a great example.

I find:

I google things I understand but don't remember.

I read books about things I know about but don't understand.

I read blogs and other streams to learn what I don't know about.


This post helped me reach clarity. Thank you.


> 3. Hire a professional while you go and do revenue generating work.

Nothing wrong with acquiring a new skill. And next time you know how to do it.


YAGNI. There's nothing wrong with not acquiring new skill either. It depends on how soon/often you will need to use the skill in the future. Also on how urgent you need to do it if the need arises.


The trick is having enough skill to be able to evaluate the professional you're going to hire. I've been bitten by this before both in my personal and professional life. If you don't know enough about the field even someone with only a marginal amount of knowledge about the topic can seem like an expert.


As programmers we see this all the time when non-technical people make very bad hiring decisions. It's a chicken and egg type problem for a non-technical (co-)founder to build a good team because(or find a technical co-founder) he/she needs a good programmer to evaluate potential hires but they can't make that evaluation themselves.

I would expect myself to encounter exactly the same problems others encounter when trying to hire good programmers when I'm trying to hire some other kind of expert in a field I have little experience in.


It also depends on the amount of revenue you can generate if you hire a professional and get on with your work.

If we assume that the professional's fee is constant (doesn't depend on your income), then someone with very high income can waste only minutes on the task before it would have been cheaper to hire a professional, whereas someone with low income can devote a few hours to learning how to do it themselves and still make up for lost earnings by avoiding the cost of hiring a professional.


You an other comments seem to only balance cost and time lost, but doing your own curtains, for many people, is also fun, rewarding, interesting, and a very good way to change focus from professional or personal issues.


I find most of the benefit of learning new skills is in how they supplement other skills. I may very well never need to drill into masonry or have dry lined walls - by knowing that they exist, I can ask better questions.


To update the punchline of the old joke for a new era:

  Invoice
  For performing 1 (one) Google search: £0.01
  For knowing exactly what to Google: £999.99


I've always believed that being a software developer taught me not to DIY my home improvement. I recognize the finer points are subtle enough that I'd rather be coding instead of frustrated by messed up drywall. I'll call an expert. Or at least a practiced layman.


Yes, but the thing is you didn't build the drill, you didn't cast the fixings, you didn't design the drill bits.

It's one thing to google for a sorting algorithm, find one that doesn't work correctly, and learn about it in the process. And from your post it sounds like you learned a bit about hanging curtains just from your google experience.

The article is arguing against thinking "I need to hang curtains" and gathering together bits of materials that you have lying around the house to try to make it work. Someone has made the drill, and maybe you don't know which drill it is you need, but the right answer is most definitely not "build your own drill".

In programming, people will quite often go and build their own drill. I guess this is less of a DRY problem than a NIH problem.


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...


It's more broad than that. I'm pretty sure that's just what it means to be an expert at anything. You have a set of heuristics at work as an expert. To a beginner, everything has the same emphasis. They won't even be able to differentiate correct from incorrect in many cases.

Watch a lawyer scan through a contract or a copyeditor edit your essay -- same thing. They catch in a second something you'd never catch in hours and hours, if ever.


It's funny because that's perfectly backwards. :)

Machine learning is a model of this thing we observe in ourselves. Don't mistake a picture of a pipe for the pipe itself.

http://en.wikipedia.org/wiki/The_Treachery_of_Images http://en.wikipedia.org/wiki/Reification_(fallacy)


I'm not sure what your point is. What is the image, and what is the actual object?


I was replying to wting, but HN doesn't let me reply to a reply by the same author as a way to combat back-and-forth style arguments, I guess.

He said that experts doing that is "trained pattern matching gained through experience, i.e. machine learning."

But that's backwards: machine learning in this style is a model of something we observe in ourselves. The thing that's in us is the pipe, the machine learning algorithm is the picture.


You have to either wait a few more minutes till the "reply" link appears, or simply click on "link" link(!) and write your reply there.


Thanks! I've been an HN member for ~5 years and I didn't know this. :D


It's trained pattern matching gained through experience, i.e. machine learning.

What you said in the GP post stands true, it's important that beginners learn the correct patterns (look up documentation for idiomatic examples) and not false ones (blindly copy and pasting code).

You see this all the time in casinos; their goals is to reinforce poor pattern matching behavior. From roulette tables' results signs to bad poker players chasing terrible odds, the human mind has the ability to disproportionally increase the significance of selected memories.


It's not only knowing how to filter the results, but knowing what to Google for in the first place. Often results will be different if the search uses slightly different terminology, and knowing what the right terminology to use is requires a little bit of domain knowledge. Once you have the domain knowledge, not only is it easier to determine what results are more likely to yield useful information, but you also get better results in the first place through better search terms.


I see it more as a Family Feud style of reasoning. It's not just "how to ask the question" but "how other people would ask the question." Being able to model how other people would ask the question (empathy) is a key skill.

In my mind using jargon or appropriate domain-specific terminology is an instance of that.


Yes, my first steps in learning about something new are to search usin the words I know to find terms, then use those terms to find other terms, and to keep going until I have hit bottom. Then I read the books the people using the most expert terms recommend.


It's about knowing what you don't know. There are unknown unknowns and known unknowns.


I agree with this. I was recently amazed when a front-end developer came up with a google query that had much better results for a problem I was having.


Yes it's funny when they are paying me to do tech support and the first thing i do is google their exact error message, but I know how to hone in on relevant information.


The interesting thing here to me is that this represents a failure of Google to present you with relevant information and only the relevant information.

It's an opportunity. Not an easy one, by any means, but still an opportunity.


This is something only someone who was already on their way to being an expert would say. :)

A beginner with a broken, incomplete, or confused model of the world won't be able to accurately assess whether a new piece of information is consistent with that model. The information could directly address their issue and they won't even realize it. The expert, standing over their should, is dumbfounded: "Your answer is right there! You scrolled past it five times!"

This isn't something unique to programming. It's true of all human understanding. How long were humans relatively comfortable with magnetism and electricity before we understood the relationship between them?

The effects of electricity are all around us. It's why we can't put our hand through the table. But you have to have a deep understanding of electromagnetism to see how that "obvious" fact is related to the this magical voodoo thing we call electromagnetism.


To recognize an answer you almost have to know it. Somebody unfamiliar with the right solution will not recognize it even if it is staring them in the face.


>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.

This filtering is definitely crucial. I think when you're on your own, you don't even tend to realize how much is just being ignored. I've also had people look over my shoulder and say "what about that?" and point at obviously useless results that I had skipped over. Explaining why you skipped that link and don't think it's worthwhile can be a challenge.


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.


Yes! It's developing the judgement that separates an expert from a non-expert. Effective use of Google is a consequence of that judgement, not a cause.

More formally, it's nothing more complicated than a standard fallacy of the converse. We have "being an expert implies being the quickest to use Google." This does not imply the converse: "being the quickest to use Google implies being an expert."


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?


I have no idea, unfortunately. One of our fundamental theses is that much of what we teach is difficult-to-impossible to teach outside direct human-human interaction.

So, try to solve that first, c.f., http://www.quora.com/What-is-the-most-useful-programming-lan...

Second, if it had to be one overarching thing, I'd say learning about "fixed mindsets" vs "growth mindsets," as Carol Dweck calls them, and applying the scientific method to your own patterns of thought, emotions, and systems of understanding without judgement, shame, or super ego.

Everything we do, curricularly-speaking, follows from principles like that.


Get yourself a book like "How to design programs" and a computer, and hack away.


Fantastic insight, thank you!


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"


I'm not talking about loop syntax or stdlib argument order. I'll google around for algorithms or concepts or data structures too. I'll bring up the docs and study them to figure out what data structures I've got so as to do the least amount of work. Do you want to test the things I've already learned, or how quickly and neatly I can actually get things done?

And it's far too easy to start going down a long and winding dead end path when you can't incrementally run an algorithm. I've had a couple whiteboard interviews where I get the sense that I've gotten something wrong early on that's causing me trouble, and while stopping and pondering on it doesn't immediately reveal a problem (and oh shit, I've only got 10 minutes left in the interview, gah, well, guess I'll just keep trucking), running it once to see the output could easily do so.

It's nothing like real-life coding, is my point.

Also:

> A good whiteboard interviewer will be those things for you.

Would that they were all good ones...


I applied for a job posting at Khan Academy and ran into exactly this kind of interview.

It shows absolutely nothing about me other than I am not a good test taker, and without incrementally debugging my programs I am a fairly worthless programmer.

I dont see how putting someone on the spot like that really extracts any knowledge about the type of person they are.

All of my peers describe me as 'the best programmer they know' yet every programming interview I've ever gone to in this style doesn't work out for me. Frustrating.


Yes. A good whiteboard interviewer should constantly stipulate things that seem intuitively right, and let you use obvious helper functions that should exist in your environment, without penalizing you for getting the _name_ wrong. I.E. if we're talking java, you should be allowed to use anything that "feels" like it should be in java.util, without having to name it correctly. Because that part can be quickly googled for.

Sometimes interviewers even let me just define the signatures of helper functions whose behaviors are tedious to write out, but in words we can cleanly go over the expected behavior. I have a habit of writing "pre" and "post" documentation for functions that specify finer grained types than the porous Java type system; chalk this up to my love of OCaml, but it greatly pacifies interviewers who know that I am mentally type checking, and will let those helper functions go unimplemented.


Whiteboard interviews have another fundamental flaw. Introverted people (typical for programmers) tend to perform terribly when they're watched and being evaluated. Even when you're provided with Google, docs and REPL the most important tools may still be missing: your mind and your ability to focus. Whiteboarding sessions are useful for many things, but coding is not one of them.


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.


My best explanation is that a lot of programmers have Asperger's syndrome, and in a pinch, some of them will be called upon to take part in an interview loop.

I once had an interview where the interviewer asked me to write him a partial template specification in C++. Any time I gave him anything that wasn't exactly right syntactically, he would just say "uh uh," with no further feedback. I did eventually get it, at which point he moved on to bit manipulation questions, which I must admit were somewhat outside the box of what one normally expect from an interview, so I'll give him credit for that. Needless to say, I didn't get the job.

Later that day, I Googled the interviewer, and found his home page, which had a collection of clever bit twiddling hacks he'd collected over the years. I guess that's important or something.


That's how we operate technical interviews at Grubwithus. After a short phone screen and a ~2 hour test for basic competency, we invite candidates into the office to work with us on a 1 to 2-day project where both we and the candidate get to see how we like working with each other. We get the chance to evaluate the candidate's ability in a (sort of) normal working environment as they tackle actual problems they'll face in the day-to-day job, as opposed to a high-tension technical interview with irrelevant/meaningless questions.

https://www.grubwithus.com/escape-the-cold


The problem with this is that it can take a significant amount of the candidate's time. Scheduling a project (here's a spec, you have 3 days) is a major inconvenience for a lot of candidates.


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 agree, we do the whiteboarding but what I really care about is how well you can take a problem and make a solution (that's a big part of my application process http://www.pagerduty.com/jobs/engineering/growth-and-interna... )


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.


Just out of curiosity, were you working at Fog Creek? What you said reminded me of an article[1] by Jeff Atwood.

1: http://www.codinghorror.com/blog/2006/09/has-joel-spolsky-ju...


Nope not FogCreek, it's possible the origins of our made-up language was done for similar reasons


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.


No.

I've been contributing to the Rust compiler in my spare time, and needless to say documentation is quite lacking. In fact, the Rust source code itself and git diffs are probably the best documentation available since everything is still changing.

In this context, you don't have the luxury of using Google for examples of common actions.

I'm also an undergraduate security researcher. In this position, you are at the forefront and Google doesn't help. Reading papers helps a little, but there's always the chance that someone else beats you to the punch and publishes first (happened to me 4 months ago).


Even in large, well documented projects. People often overlook how good source code can work as documentation.


You've worked at a startup? Documentation is usually the last thing people do unfortunately, at least in any kind of useful way. Sometimes there was documentation, but when only 10 people in the world are using a language there ends up being undocumented behavior or things that you can only discover when it happens to you or you ask the guy around the corner who created it...

edit Also wanted to say there is a huge difference between being able to Google and "Copy-Paste" a solution vs Googling the source documentation and figuring out the problem. We definitely could not have copy-paste programmers.


Heck, that attitude about documentation is everywhere, not just startups. It's just that good documentation is one of the things that separates the good shops from the bad shops.


"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.


My doctor said "I don't know, I have to go look that up".

He's probably going to stay my doctor for a very long time for that one sentence.


I suffer from a cross disciplinary illness, in which very few doctors have experience (because it doesn't fit into one of the major well defined specialties). You can't imagine how happy it makes me when a doctor tells me "I have to go look that up", as opposed to.. no.. there's nothing to worry about, you're just imagining that, or whatever


Absolutely. Doctors are particularly egoistic and don't deal well with long-tail problems. But that doesn't make yours the best doctor; the best doctor wrote the original material. Willingness to research the answer just makes your doctor an effective doctor, because they ultimately deliver the correct answer.


No single doctor wrote the original material. The doctor who wrote the original material for one area may be completely useless outside his area and ineffective at looking them up.


I agree... but the "best" doctor is also 5k miles away from me, and out of my immediately budget, since insurance doesn't cover it.. so.. I'll settle for "effective"


the best doctor wrote the original material

I agree with everything else in your comment, but that doesn't make sense. How do you arrive at that conclusion?


I am, admittedly, handwaving here. "Best" is so subjective that's hard to define, so I define it as "the ones who move the field forward with original work." In other contexts it could mean something completely different.


I see. Well I'd differentiate between a researcher and a clinician. The best researcher may not be the doctor you want diagnosing and treating you.


I don't know, it's almost a little unnerving to think that a doctor would always go completely from memory and never look at any reference material.


That's what parent said.


Two commenters read my comment backwards. Wonder why.


apologies.. I completely inverted the meaning of your comment... and yeah, I think the other commenter is right.. the second line would be an appropriately sarcastic response if it actually said what my brain interpreted it as.

That said, given the number of upvotes, it seems like a ton of people misread your comment as well.. quite interesting...


Because the second line sounds sarcastic.


I think that is cultural;

a practician in Latin countries (in Europe) would loose any credibility by acknowledging they have to check a knowledge base (although it does make sense). In a similar fashion a teacher would literally loose face in front of his student for recognizing he does not know the answer to a question on his subject from the top of his head.

That said, and by experience, I have seen plenty doctors checking their books on illness to match symptoms, but they did that in such a serious manner, you would believe they were just needing confirmation of memorized knowledge. Whereas I have seen plenty teachers/lecturers just dismissing the answer as obvious or the question as irrelevant.


Yeah you're way off here. If my doctor said "I don't look things up" I'd run out the door. A doctor who looks things up is a doctor who cares to get things right.


>Yeah you're way off here.

You read my comment exactly backwards.


Depends on the situation - a doctor can take his time during say, a cancer diagnosis, but not in the ER.

Do you want a doctor who's trying to patch up your innards after a serious accident to look up where your pancreas is located?

Inexperience leads to a lot of wasted time searching for things along the way. The more you know in your head, the better.


>Do you want a doctor who's trying to patch up your innards after a serious accident to look up where your pancreas is located

Do I want a surgeon who'd stop look something up and rescrub if that was the best thing to do? YES.

That inexperienced guy is going to get experience at one time, perhaps on me. If he needs to stop, and the stopping is less dangerous than him NOT stopping, I want the stop to occur.

Do I want a fucking moron who can't do basic parts of his job, of COURSE not.


If I were going in for surgery, however, I would like my surgeon to have recently researched the best current way to perform whatever he is going to do.

The surgeon (or programmer) who thinks he knows everything isn't the best one for the job.


> Are the above statements true?

Yes. Google not strictly being Google itself, but searching other resources. Doctors do research. Scientist read papers. Everyone references something else.

So don't think of it as merely Googling because you don't know. It's Googling because you know someone else has solved this, or something similar, and you want apply someone else's knowledge to what you are doing.


Absolutely.

My doctor, who is a hotshot young doctor at a hotshot medical school, impressed me by telling me she needed to look up my symptoms and then showing me what she found (and, to be fair, also referring me to an expert).

Depending on field, part of being an expert is also knowing where to look for field-specific expert information. Google is a much better search engine than the NCBI PubMed interface, but I know as a biomedical scientist that I should use PubMed or else I'll miss important research.

(Though part of being a scientist is also realizing that you're trying to understand totally new results, and google is of no use past some point. I imagine this is also true of engineers. You're building on previous work but at some point you have to move past what's been done before.)


My friends daughter was born with a lung disorder that showed up in the first week after leaving the hospital. The local hospital almost killed her in incorrect diagnosing and panic and she was emergency flighted to Childrens. Two of the doctors there quickly came back with a preliminary diagnosis of congenital lobar emphysema after a few internet searches on the symptoms. They had printed what information they could find off of a few websites at the time. Based on that they talked to surgeons that had experience in the field and within a day the surgery had been performed and all was well.

What I see is 3 information tiers. 1. You should know this off the top your head to be a professional. Common information, kind of like daily use of your first language. 2. Information that is not common or you shouldn't be expected to remember because of its rare usage. The type of information this thread is about. 3. Information you make, what you state at the end of this thread.


Google (and others like IsabelHealthCare) help you catch the zebras you missed while looking at the horses.


Since Google is written by programmers, it's a very good search engine for finding stuff about programming. I'm sure there are medical publications and search engines related to the medical field, and that 'Good' Doctors will quickly use them when something falls outside of their memorized knowledge.

http://www.nytimes.com/2012/12/04/health/quest-to-eliminate-...

Note: there is a diagnostic program named Isabel that would be the Google equivalent.


Any doctor who says he knows everything/a lot of things is plainly lying or just BS'ing his way through.

The doctor's way of googling is if the patient falls under common pattern of diseases, like say common cold, cough, fever etc kind of diseases or some thing like commonly known infection that is spreading around to everyone. Treating such patients is a cake walk as there is a well defined treatment protocol to follow that works flawlessly with near 100% success rate.

When faced with a disease rare enough to warrant deep diagnosis thought process and further investigation. They simply put the patient on a 'safe mode' go do their homework and come back Or send him to a specialist.

Emergency cases are a little different. But besides that anything beyond a well known problem, a general doctor will know as much as what a Google search would tell you.


Good doctors are pattern matchers. In complex cases they do research by reading books or asking others, but they already have a good idea in what's going on.

A doctor that can only recognize diseases like the common cold is not a good one. Your example is exaggerated and also, the patient may already be dead by the time the investigation is over, which is worsened by the fact that aggressive treatments (like strong antibiotics) can do even more damage, so a good doctor has to have a pretty good grasp on what's going on already.


>>Your example is exaggerated and also

No,

This is the normal trend here in India. And unfortunately lives are cheap here. Its not like in US that you can sue people, in other parts of the world things are a lot more different. There is practically no regulation in countries like India.


Well I wasn't talking about particular health-care systems, but rather about good doctors, of which you can find everywhere, albeit in a minority.

I don't live in the US. I live in Romania, which has a ruined public healthcare system, but even here I've met medical personnel that's worth their salt.

As an example my now 3-year old suffered from a severe allergic reaction called "Lyle's syndrome" (look it up). We went to the hospital in the early stages and the doctor that took the case immediately recognized it, even though at first it looked like some kind of severe cold/flu (coming in combination with tonsillitis and fever).

After several hours of being hospitalized, his skin pealed off in certain areas, but he was already on both antibiotics and corticoids and so the reaction wasn't so severe as it could have been (imagine your whole skin pealed off, with the same effect as second or third-degree burns). And the problem with weird allergic reactions is that antibiotics from the cephalosporins class or other medicine that produces allergic reactions can kill you.

Also, our doctor went basically blind for the whole time, because the blood tests you perform when the patient is under treatment are mostly useless, being used only to discover how well or not the patient is responding to treatment. For instance she discovered a bacterial infection, which is known to cause Lyle's syndrome, but was it an external infection that caused it or because of an imbalance of intestinal flora due to antibiotics? We also gave him antibiotics before hospitalizing him, that might have also caused this reaction. Lyle's syndrome is known to be caused by both antibiotics and bacterial infections.

The root cause in the case of Lyle's syndrome is extremely important because the treatment and severity of the reaction differs. Our doctor basically took a guess based on how his skin looked.


Probably, but they needn't advertise the fact. I go to a specialist for Cystic Fibrosis, and when one of my doctors responded to a question I had with "I Googled and learned that..." it didn't sit well with me.


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.


Research never stops being in play on really hard problems. Sometimes though, the research isn't in search indexes in a way you'd suppose.


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.


I have yet to see a good email regexp while using Google. Most of them have huge troubles - either not having proper Unicode support (http://en.wikipedia.org/wiki/Email_address#Internationalizat...) or not allowing the +label thing that Google is doing for instance. If you want to validate an email, make sure that there is an '@' character in there followed by some chars and a '.' with some other chars at the beginning and the end :)

If you really really want to validate an email then force the user to verify it.


Getting a precise email regular expression straight is much harder than most questions about algorithms you will ever be asked in an interview.


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.


Not everything we do is cutting edge. You may be working on the cutting edge and there may be no answers for you. However very likely there are some notes that this or that is so cutting edge that there are no (known, good) answers.

Most often, however, you are just querying the database wrong. You either don't know the specific jargon or you are searching for an overloaded term.

Its kinda like when I get pitched by non technical people who are keen on starting up and they come with this "revolutionary, never seen before webapp" idea. Usually within two Google queries I will have some established players already working on the specific market, or at least digital corpses of some previous players. When I get no results, even after an hour or two of searching - that usually means that there is no market, where the would be founders are seeing it.

"Cutting edge" is often a synonym for "not having a clue" :D.


To quote the article under discussion: "If you need to implement something in code and it’s not cutting edge technology, Google it first."


Even if you are working on the cutting edge, you are still building on top of previously learned knowledge. Google is more than just quick fixes or simple solutions. If your expecting a problem to be solved by a recipe, it's not cutting edge.

However, reading papers and studies that relate to what you are working on will provide you with a better foundation to solve the problem.


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.


Yes, because the ones in the standard library are very cleverly optimized and they are usually a hybrid of related algorithms.(For example qsort in C isn't exactly quicksort) But if you have a novel problem of algorithmic nature, having already built an intuition should help.


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.


Funny, in the future there will be adults that have never lived in a world without Google. Instead of the word 'Google', just say fast, well indexed internet searching.

It depends where you were. In a university or large business you could go to where the other computer people were and ask, or go to the library, and if you were lucky maybe a BBS where a few experts were. If you had the right contacts you could pick up the phone and call someone (god long distance was expensive back then). Things didn't occur at the rate they do now. You might have to push a problem out for a week or two to get an answer, or maybe a manual shipped via mail. That, or you pissed around and tinkered with something till it worked by yourself.


University libraries were like magic gardens back in the day, and they generally weren't overly picky who used them (sometimes it helped to have a university ID, but usually it could be any university, and expired was fine)...

In the early '90s I was unemployed, and so spent a few months basically just going to engineering library of the local university (University of Washington) every day and reading journal articles all day long. A very pleasant memory... :]


A lot of reinventing the wheel and a lot of 'small lookups' that delay you for a few days instead of a few minutes - while you get the relevant info from a non-local person or a book that you don't have on your desk.


There are these things called books.


When I started learning programming it was book (often terribly shitty ones, full of mistakes and non-working listings) and hear-and-say.

I started at 11 years old or so. I didn't yet have a modem (not before I was 16 or so).

So it was trial and error and trying to figure things out. I remember printing a huge assembly program on a dot-matrix printer and going to a friend's place with the listing, explaining him that the routine would work for a few seconds then crash. Then he read the stuff and after a while he found the error : I was using 'jsr' instead of 'jmp', leading to an eventual stack blow.

And there were also "scene disks" or "news disk" from the scene or whatever they were called that we would copy from our friends. I remember one from some scandinavian group (I was in France), in english, where they were explaining various sorting algorithms and where/when we should use them in intros / demos (before cracked games).

It was all a "black art" because these stuff (learning assembly to code intros / demos / cracktros [but they weren't called cracktros yet IIRC]) weren't in books, nor in magazines.

Then came my first modem (9600 bauds) and pirate BBSes (and writing intros for these BBSes) and suddenly a whole world of knowledge opened to us. It was magic.

Then came my first Internet ISP. Long before Google and no need for Google : old search engine were sufficient to find gems (Like Fravia's tools of the trade tutorials to learn how to pirate games on the PC, very convenient when you just arrived from the C64 / Amiga scene).

And of course there was Usenet. Usenet and a good kill files was immensely more useful than StackOverflow. Heck, the amount of knowledge on Usenet still probably dwarfs SO today.

I'd say DejaNews (later bought by Google and more or less became part of Google Groups) was the most important search engine of them all when it came to code. A good Usenet reader was useful to stay up to date and to ask/answer question while DejaNews contained all Usenet's archive (and a search engine).

That's what I remember, more or less... : )


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!"


You can't be a good computer scientist if all you do is search for solutions using Google, but you can be a pretty good product shipper.


You might want to make that Google lower case, because as it currently stands, it seems to suggest that the fastest programmers go to Google.


Was looking for a comment in that spirit to avoid creating a redundant version and there it is.


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.

What matters is getting things done.


Is a great memory a requirement for great programming? http://stackoverflow.com/questions/572620/is-a-great-memory-...

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...


Let use an analogy in education:

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.


If I worked at Microsoft?

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...


>why in the world would you want to spend 2 hours trying to figure it out yourself?

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.


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.


This is fine for your own projects, but not on my time. I would expect you to look for an existing solution before writing something from scratch.


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.


Google is one of many tools that can be used to solve problems. IMO it's generally one of the more efficient ones.


> Excluding for fun and educational purposes


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]

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


You should have googled 'how to validate required fields before passing them to SQL because someone will click the button without having added an email...'


No, the best programmers have done it before, and documented it. Every good programmer should have an Evernote or failing that, a Tiddlywiki for all non-trivial information.

Googling is hit or miss--that great source for how to set up ssh certificates in Apache might rank poorly tomorrow, and pages which don't do show how to make a pem might be top ranked tomorrow.

Evernote has saved me tons of time... I look at it as a digital extension of my brain.


I feel the same way about my bash history.


From my experience of not doing this early on, the quicker you take this advice, the quicker you will build really cool things.


IMO, school worries about plagiarism cause young engineers to be overly adverse to looking and seeing if the problem is already solved before attempting their own solution

Too much NIH syndrome, and NIH among those least qualified to invent it usually


Most annoying thing ever was doing IT work at a company where internet access was not granted to employees below a certain paygrade.

The amount of times I'd run into a problem and then instinctively fire up the browser just to get the "cannot connect to google.com" message.

They handed out ringbinders full of notes to staff insisting that everything we needed was in there.


Such thinking can only take you up to a certain level of excellence. Having admired some c++ standard committee members in action, I can say that if they had to google every harder bit, their skills would've been mediocre.

If you want to be one of the best, you need to have a local data cache instead of fetching knowledge from a remote resource.


I agree to an extent, and I do use Google a lot when programming. However, I'm a systems administrator by trade and not a programmer. I have been in cases when I've wanted to write code in a cabin in Nova Scotia with no internet and wasn't able to get everything accomplished because I was unable to Google and didn't have the docs on hand.

I'd be really wary of telling people not to remember stuff and rely on the internet. The primary reason being sometimes you can't access the internet. As a sysadmin it's my job to understand this and document everything. It was personally embarrassing when I realized all I had to do was download a couple pdfs and I'd of been fine.

You may not need to keep everything in your head. However, having direct access to knowledge is important. If it's not in your head, then keep it in a local file or what I'm really fond of, get the book.


I'm sorry but no. This article should be called "The best programmer I know can quickly understand things he finds from google, but I don't really know what he's doing that makes him so awesome".

Sure googling something fast can be a nice little boost to productivity, but only if you know what you are doing. If I drag and drop code from my web browser instead of using copy paste, I might save a few seconds after doing it 50 times; but if I totally fuck up my code-base because I don't know what the code is doing, then productivity is going to decrease significantly when the entire team gets backed into a corner and has to take the time to figure out where the bugs are, if/how to rewrite core systems, and hopefully this wont happen, but where the security holes are that let a hacker pwn your DB or worse.


The one thing that this post completely overlooks is that storing knowledge, even Googleable knowledge, can be very beneficial.

Knowledge can help develop intuition, to know which pieces connect to each other. For example, in a programming competition you could google various algorithms to determine solutions. But Google won't tell you "which" algorithms to look for, or give you the intuition you need to piece the correct solution together.

A good analogy is chess. Before computers could beat humans, it was a pure game of human mind vs. human mind.

Then the computer was able to dominate humans.

And now, we're discovering that a human paired with a computer, can beat either alone. But that human still needs to have the intuition, experience, and knowledge to know how to work with the computer.


Yeah, we need to always be learning new stuff and the way you learn is by RTFM. The point is that now Google is TFM. Or at least it's the index into every manual published. So unless you are already an expert in every server program, every library and every language that you are using, the way you acquire the knowledge of how to accomplish whatever specific task you are working on is to refer to the manual. You still need to know the technical term for what you are trying to do so you know what to search for and you have to know how to evaluate and select different technologies and how to fit them together, but the details of how to work stuff and solve many specific issues is best found on the Internet.


Many of the best programmers I've seen google stuff. So do many of the worst I've seen.

The difference is the former won't type a single statement without knowing what it does first, while the latter will just copy and paste something that seems to work, regardless they understand it or not.

The last time I came across some copy-pasted code that was giving some troubles, and after asking the owner of that code what some stuff did, he was unable to tell me, after claiming it was just fine, because the code he copied was from a trustworthy source. This, I guess, is a bad practice of how googling things should work.


> chances are, unless you’re an absolute genius, the collaborative efforts of an open source project will beat whatever you can do in 8 hrs.

It depends. There could be an information asymmetry that leads most people down the wrong path, and an open source team could be subject to groupthink that leads them down that path faster.

A lot of what distinguishes experienced programmers from inexperienced ones, is that experienced programmers generally know how to mitigate non-obvious risks. What distinguishes great experienced programmers, is that they know how to mitigate such risks more efficiently.


Agree and disagree. I'm very good at finding solutions fast with Google, but those solutions only work for me because I know what I'm doing. I know several developers (or designers who do a bit of development) who rely too heavily on other people's code for every problem they encounter. As a result their work is often riddled with conflicts and often doesn't work quite the way they originally intended. Everything becomes a work around. When everything breaks they have no idea how to fix it. Lately I find if I know how to build it from scratch I'd much rather do that


I have seen too many people copy pasting from google and introducing bugs in the code just because they don't understand what is going on.

I know that HN is really focused toward web apps and mobile apps. However, sometimes is good to remember that there is plenty of software done also to control machines and perform mission critical tasks. In those cases often is better to have control over the whole software stack. That is why so many High-Tech companies have their own software libraries, for example for image processing. In addition there is an IP and licensing question.


When I was learning Ruby & Rails my co-founder told me about http://ruby-toolbox.com, and while it's still not perfect for beginners, it goes a long way to solving the "what to google / what to use" problem. If you have a very basic idea of what you're trying to do it can generally suggest a few options to use (gems). I've also used it to work out the category of the problem I'm trying to solve.

I'd love suggestions regarding more sites where you can search in a problem space as opposed to a specific bug or issue.


When I interview a candidate for a hacker-like position, I provide give them the problem constraints and hand them my computer.

I tell them to lookup anything they want.

The portion of time spent on Google directly correlates to their success.


Maybe there should be another programmer maxim: DRO (dont repeat others)


Just what I thought!

One thing to point out: there's a fine line between what is and what is not repetition. You may/will find a tool that's perfect for what you want to do sans one or two features. Your ability to adapt that tool to exactly what you want so you don't have to repeat the 99% of things which are already finished is important.


You must repeat the doing but not the inventing. I propose the following maxim:

Good programmers invent, great programmers copy.


A wise man that I once worked for said "The best code is the code you can steal."


Agreed, but now I think of it there is a level beyond the copying/stealing of code: "The best code is the code you didn't write".

Of course, it is even better to beat a complex program with a small amount of shell-fu.[1]

[1]: http://franklinchen.com/blog/2011/12/08/revisiting-knuth-and...


and when Google fails, a well posed question on Stack Overflow can get results in 10 minutes. I worked my way through a whole Scala project that way - Stack Overflow Driven Development.


I love that I am starting to see more and more SO answers at the top of my Google results.


haha SODD, thats so me!


If I've been solving a specific type of problem using similar technologies for 10 years I'm going to code circles around you while you're off googling stuff.


This has to be one of the widest pricing plan spreads I've come across:

$99, $699, $4999

https://framebase.io/pricing.html


There are a few problems with that in my experience: you cant use all open source projects in a proprietary context and open source projects all have different dependencies. The former flat out stops you from using the code (and you shouldnt even read it to avoid any accidental lawsuits). The latter is a big problem because you dont want to use eight different frameworks in one projects.


The platitude sounds like something I can get behind but it's so much more than knowing how to search -- it's knowing where to search. I know programmers who are great at searching but have no idea which online information sources to avoid, which is at least half the battle.

In a world of copy/paste programmers, bad code gets worse as it's regurgitated around the web.


I'm not quite sure what is so revolutionary about this post. If you don't know something of course you will Google it. However, a good programmer can make better queries precisely because he/she knows more background about the problem than a less experienced programmer, so in the end, it's still down to who has internalized more information.


I can't speak to the author's intentions, but it feels like a typical HN-baity title to get eyeballs on the blog. The real estate dedicated to the startup's call to action (on the bottom and sidebar) is almost as big as the blog post. I, like many, have similar "blurbs of brilliance" that I'd love to post, but I feel that if I don't have at least several paragraphs with substantive information then I'm merely adding noise to the Web.


Top down thinking is the #1 most underrated skill in large scale problem solving. However, there is an equally important need for fixing narrowly defined problems which need detailed focus. In the end you need both the engineer that projects the entire car and the one that builds the door handle.


I thought from the title that you meant that Google, the company, thought that faster coders are just better.


The best programmers may be the ones that work at Google as they are very quick at mining for search requests, such as gleaning what other software developers are working on. This may be what gives Google a competitive advantage.

Spread that competitive advantage around. So as not to give our secrets away only to Google, I may search for programming help using duckduckgo and other search engines.


Does anyone else find themselves Googling the same question over and over again? How do you deal with that?


Keep a blog where you "document" any issues you keep running into. By the time you're done with the post you'll either remember it or if you don't you'll know exactly where to find the answer if you need it.


I would actually recommend Wiki (specifically wikimedia) software for this doing this.

It can act very much like a blog, but also brings along features of many Knowledgebases, like versioning of information. Sometimes problems evolve, and being able to keep track of that is beneficial.


And how will I find stuff in my own pile of notes? Googling :)


Happens to me all the time.

I use Evernote to keep track of the most common bash commands, API calls, syntax specifics, etc. Flash card format, e.g.

Title: Check if object is in a NSMutableArray Content: containsObject:


"So unless you’ve already memorized that sorting algorithm by heart..."

That's a bad example. Nobody does that, unless they are really trying to solve a sorting problem.

This article comes down to: "don't reinvent the wheel", without really any supporting examples to guide you further than that.


The flip side of this is that deep understanding of fundamentals helps dramatically when it comes to asking the right questions and filtering results.

In my experience, google is often secondary to first-class reference materials (language documentation, man pages, etc.)


I think the key takeaway here is not just being the quickest to Google, but the quickest to google well.

It's so frustrating to see people trying to google a problem, but fumbling with a poorly written query and/or focus on the wrong search result hit snippets.


People call it Google-Fu for a reason.

You could probably tell a lot about a candidate by how they Google for things. To effectively search, you have to effectively define the problem. Often that means having the understanding to redefine your specific problem into a more generic one that you can search for. Ineffective searchers will struggle to do that, or worse, simply throw words into the search bar and expect a magical answer.


With this title I was really expecting some kind of study, not an anecdote from one person.


"the collaborative efforts of an open source project will beat whatever you can do in 8 hrs" is often untrue.

You need to have the ability to read and understand at least part of the code to make sure said project doesn't have fundamental flaws or sub-par code.


I Google everything right away. I guess this makes me the bestest programmer!


Even faster than googling it up is searching through evernote or whatever app you've used to organise your cheatsheets. Evernote has become my external and more organised storage for my brain.


The best programmer I knew was quick to google, but so was the worst programmer I knew. If you're slow to google maybe it's the sign you are an intermediate programmer.


More like: the most clueless programmers are the quickest to Google. If you know what you are doing, there isn't always an urge to look for ready-made solutions.


I have been away for a while. Has HN fallen so low in the meantime? Time to change its name to Code Monkey News, maybe?


Its not only resourcefulness but the ability to know what pieces you need to build the project. That is harder to find by Googling.


Makes me wonder then why Googles presses so much on academic CS knowledge during their interviews.


The best ones are those who know _solutions_ exist or what to google for.


The best do not have all the answers, but they know how to find them.


But the slowest to cut and paste what they find there.


I sat with a newbie programmer the other day. We sat there and made good use of third-party libraries, frameworks and code to get things moving, and concentrate on the core problem at hand.

Now, we had to Google a bit to install the third-party and dependency stuff, and tinker with configuration to get it all ready.

Eventually we delivered the GUI version of 'Hello World', and the newbie programmer had already progressed several steps when he remarked: "So, modern programming is basically building my code on top of other people's code, without really knowing how it all works, if it is really any good, and hoping it all works well enough to make the whole thing work".

Any he was right. Long gone is the time when we understood all the components and code for our entire domain.

And we are often the poorer for it.


The newbie's statement sounds like a romantic platitude.

You should've shown the newbie programmer that programming is the art of abstraction and that there was never a pre-modern era where "we" were all toiling away with omniscient domain knowledge.

We lean on other people's abstractions because we're mortal and the things we decide to abstract have a surface area that overwhelms the problem we're trying to solve.

Rather than being poorer for it, we're immensely enriched with the ability to solve the problems of our domain with the same vernacular that expresses our problems. Total providence.


Be the quickest to Bing or DuckDuckGo; They are less spammy




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: