The best programmers are the quickest to Google
blog.framebase.io
blog.framebase.io
"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.
Invoice
For performing 1 (one) Google search: £0.01
For knowing exactly what to Google: £999.99I 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.
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.
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).
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).
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.
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.
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.
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.
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.
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... :]
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... : )
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.
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.
Alan Kay: in programming there is a wide-spread 1st order theory that one shouldn't build one's own tools, languages, and especially operating systems. This is true—an incredible amount of time and energy has gone down these ratholes. On the 2nd hand, if you can build your own tools, languages and operating systems, then you absolutely should because the leverage that can be obtained (and often the time not wasted in trying to fix other people's not quite right tools) can be incredible. https://docs.google.com/viewer?url=http://www.vpri.org/pdf/m...
A professor in college might allow the class have an open book exam, however you still see a number of people who might not pass that exam. Why? Well, there were two kinds of people in that class:
1. The smart ones who actually know the material. 2. The others who know nothing about what had been taught so far in the class.
The students in the first category will pass the exam but the second crowd perform poorly, because even though the book is in front of them, they don't know what to look for, especially in a timed test.
So the way I see this is that googling will help those who already have knowledge of the programming concepts, not those who have no idea of what they are trying to implement at all. In reality those who can use google to get what they want can also figure it out without google, even though it might take longer of course.
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.
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]
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.
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
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.
Too much NIH syndrome, and NIH among those least qualified to invent it usually
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.
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'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.
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.
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.
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.
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.
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.
I'd love suggestions regarding more sites where you can search in a problem space as opposed to a specific bug or issue.
I tell them to lookup anything they want.
The portion of time spent on Google directly correlates to their success.
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.
$99, $699, $4999
In a world of copy/paste programmers, bad code gets worse as it's regurgitated around the web.
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.
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:
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.
In my experience, google is often secondary to first-class reference materials (language documentation, man pages, etc.)
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.
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.
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.
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.