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.
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.
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.
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.
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.
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
"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.
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...
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.
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 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"
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.
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.
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.
>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.
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.
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.
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.
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.
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.
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.
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.
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!"
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.
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."
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...
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.
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 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.
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.
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.
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.
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.
>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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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 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.
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 :)
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.
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]
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.
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.
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"
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
204 comments
[ 2.8 ms ] story [ 216 ms ] threadThe 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.
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.
Good programmers invent, great programmers copy.
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...
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.
Too much NIH syndrome, and NIH among those least qualified to invent it usually
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.
He's probably going to stay my doctor for a very long time for that one sentence.
That said, given the number of upvotes, it seems like a ton of people misread your comment as well.. quite interesting...
I agree with everything else in your comment, but that doesn't make sense. How do you arrive at that conclusion?
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.
The surgeon (or programmer) who thinks he knows everything isn't the best one for the job.
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.
You read my comment exactly backwards.
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.
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.
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.)
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.
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.
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.
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.
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.
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.
I tell them to lookup anything they want.
The portion of time spent on Google directly correlates to their success.
"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.
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.
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 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...
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.
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.
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)
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.
It's an opportunity. Not an easy one, by any means, but still an opportunity.
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.
In my mind using jargon or appropriate domain-specific terminology is an instance of that.
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.
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.
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.
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.
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.
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 suppose learning how to use Google this way is a skill in itself though.
Nothing wrong with acquiring a new skill. And next time you know how to do it.
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.
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.
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.
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.
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.
If you really really want to validate an email then force the user to verify it.
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.
However, reading papers and studies that relate to what you are working on will provide you with a better foundation to solve the 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.
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.
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.
1: http://www.codinghorror.com/blog/2006/09/has-joel-spolsky-ju...
By the way, the three attributes you just stated are what makes anyone good at almost anything.
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.
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).
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.
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.
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 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.
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 :)
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]
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.
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.
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.
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...
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.
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.
https://www.grubwithus.com/escape-the-cold
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.
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).
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.
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: