111–120 of 205 posts
Does anyone else find themselves Googling the same question over and over again? How do you deal with that?
>why in the world would you want to spend 2 hours trying to figure it out yourself? I am sure a large portion of HN-ers (myself included) enjoy doing exactly that. I want to spend my day solving problems , not googling shit.
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 :)
What was life like before Google? Sure there was documentation, and code comments, and senior devs you could ask. But surely that was less than Google? Or perhaps the scale of problems were less vast compared to now, so the amount of info you would get by Googling now was unnecessary back then.
Earlier quoted context omitted.
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.
Depends on the situation - a doctor can take his time during say, a cancer diagnosis, but not in the ER. Do you want a doctor who's trying to patch up your innards after a serious accident to look up where your pancreas is located? Inexperience leads to a lot of wasted time searching for things along the way. The more you know in your head, the better.
The surgeon (or programmer) who thinks he knows everything isn't the best one for the job.
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: h…
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"
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...
Does anyone else find themselves Googling the same question over and over again? How do you deal with that?
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:
Does anyone else find themselves Googling the same question over and over again? How do you deal with that?
Keep a blog where you "document" any issues you keep running into. By the time you're done with the post you'll either remember it or if you don't you'll know exactly where to find the answer if you need it.
I'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.
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…
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…
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.
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 pro…