Wednesday 7 June 2017

freeCodeCamp.com/Jeremy Gunter: Google not, learn not: why searching can sometimes be better than knowing

Homepage
freeCodeCamp

    HomeDevDesignDataLearn to code for free

Go to the profile of Jeremy Gunter
Jeremy Gunter
I’m a software engineer, voracious reader, and an aspiring writer. When I’m not learning computer languages, I like to dabble in human ones. T: @mynameisflop

Jun 1

Google not, learn not: why searching can sometimes be better than knowing
Credit: Unsplash.com

A few months ago, I was reading through some of the posts in my home town’s freeCodeCamp study group. I came across an intriguing post.

One of the campers expressed her frustration with not being able to immediately come up with solutions, and questioned whether this will ever gets any easier. At the end of her post, she lamented needing to google for answers — as though this were something to be ashamed of.

I remember exactly what it felt like to be in that situation. I was angry with myself for not being able to rattle off code on demand. I felt like using Google to search for answers was a sign of defeat. Something that, in my mind, signified I was incapable of thinking like a programmer.

Fast-forward 18 months, and I’m currently employed as a full-stack Software Engineer. I spend a considerable amount of time asking Google for help with my day-to-day work. I no longer see it as a weakness when I search StackOverflow for an explanation. It’s actually one of my first steps towards a solution.

So what caused this change of heart? A lot of things. But here are a couple major insights.
Insight #1: Memorizing everything is a waste of your time and brainpower

Don’t believe me? Check out this Quora question, where hundreds of other programmers all responded with basically the same opinion on the matter.

Not good enough, how about a quote from this guy you may have heard of:

    “Never memorize something that you can look up.” — Albert Einstein

This is not a conclusion I arrived at easily. After spending hours upon hours poring over blogs and talking with professional developers, I finally came to realize something unexpected: the best in our profession don’t methodically scan and memorize documentation. Most, in fact, don’t bother memorizing anything they don’t have to.
The rare situation where you would actually need to have memorized syntax. Comic by XKCD.

Think about all the words you know in your native tongue. I’d be willing to bet you know a lot more words than you use on a daily basis. If you forget the meaning of a word, what do you do? Just ask Siri or crack open a dictionary and move on with your day. You don’t sit there and beat yourself up for not remembering a word.

Let me clarify my meaning a little with a quick story.

I was listening to a panel discussion at CSSDay in Phoenix this past December when I heard a panelist give a tip that I’ve heard more than once in one variation or another:

    “Only memorize the things you use every day. Everything else, just memorize how to look it up.”

This concept, and the internalization of it, has been the single greatest boon to my confidence and progress as a developer.

Early in my journey, I struggled to retain anything. The concepts, syntax, best-practices, they were all incredibly difficult to grasp. I’ve always considered myself a smart person, and a quick learner, but I truly believed I had come up against the first intellectual challenge of my life that I might not conquer.

Then I had a crazy idea: “Stop caring about how to write it, and just focus on understanding what it should do.” I stopped stressing over syntax and started happily writing out extensive pseudo-code. Then once I felt I had fleshed out the core parts of the solution, it was off to the search-engines I went!

This had exactly the effect I hoped it would. I was no longer spending my study-time struggling to remember what method to use to add an item to the end of an array, or if the key in a Javascript Object Literal needed to be wrapped in quotes like its JSON counterpart (it doesn’t).

Instead of going mental trying to remember method names, I focused on what action I needed to perform. When I wanted to add an item to the beginning of an array, I found it easier to google the phrase “add item to beginning of array JavaScript” than to try and use my own memory to differentiate between shift(), unshift(), and pop().

In addition to this reduction in time spent trying to generate answers from my own head, it had a couple of other distinct benefits:

    I found myself able to pick up on new (to me) languages much faster than I would have ever imagined, because (surprise, surprise), most of these concepts are found in every language, and
    I realized my understanding of these concepts was rapidly deepening. Thanks in large part to forcing myself to read more about the topic, and thus accruing less technical debt.

Aside from the aforementioned positives, which I had hoped would be the result, there was another huge bonus that I didn’t expect at all.
Insight #2: You can learn from the mistakes of others without having to make those mistakes yourself

When you start googling for answers to a problem you are facing, you quickly learn that you are not the only person to deal with this, and that other people will come up with vastly different solutions to the same problem.

Reading through a few different questions and solutions on Stack Overflow will open your eyes to different ways of thinking, or perhaps highlight flaws in your own methodology.

In doing so, you give yourself a chance to learn from other more experienced developers, and see how they work through a problem. This insight has been invaluable.

I no longer search blog posts or Stack Overflow questions with the intention of finding an exact solution. Now, I do these things so I can learn different ways to think through problems.
You learn a lot more by searching

I’m literally programming my brain to tackle problems from perspectives other than my own. I’m making myself better by understanding how someone else would write something, and merging their knowledge with mine. Their struggles become my triumphs.

And you know what? It works…really well. After starting down this path to become a programmer in May of 2015, I accepted my first position as a full-stack software engineer in September of 2016.

In less than 18 months, I had gone from an extremely basic understanding of HTML, to writing Ansible scripts, backend APIs in Ruby on Rails, and creating front-end components using React.

I don’t consider myself an advanced programmer by any definition of the word, but I do feel much more confident in my ability to learn new concepts quickly, and be able to search for the syntax on-the-fly without ever missing a beat.

Very few programmers will remember every method name or function call the first time they see them. Even fewer still will rely solely on their memory to face the challenges in their daily work.

The best advice I can offer you is that you should never be afraid to admit you don’t know something, and seek to correct it using whatever means necessary.

There is only one cure for ignorance, and that will always be asking questions.

    ProgrammingTechCodingLife LessonsProductivity

Go to the profile of Jeremy Gunter
Jeremy Gunter

I’m a software engineer, voracious reader, and an aspiring writer. When I’m not learning computer languages, I like to dabble in human ones. T: @mynameisflop
freeCodeCamp
freeCodeCamp

Our community publishes stories worth reading on development, design, and data science.
More on Programming from freeCodeCamp
Create Android Recyclerview adapters like a boss with MultiViewAdapter
Go to the profile of Riyaz Ahamed
Riyaz Ahamed
Related reads
A fast new way to find people in your city to code with
Go to the profile of Quincy Larson
Quincy Larson
Responses
Recommended by Jeremy Gunter (author)
Go to the profile of Ruben Izmailyan
Ruben Izmailyan
Jun 1

Great insights Jeremy Gunter. Another point I’d add is that languages and frameworks change so fast these days that memorizing syntax is not just inefficient but potentially dangerous as what you remember may not be best practice or even a good way to do something.
Recommended by Jeremy Gunter (author)
Go to the profile of Bertil Muth
Bertil Muth
Jun 1

I agree. On a similar note, when I started programming C, I used every bit of exotic syntax there is. I tried to compress a lot in a single line and thought my code was concise. Back then, I thought it showed my mastery of syntax. Later I learned that simplicity trumps vanity.
Recommended by Jeremy Gunter (author)
Go to the profile of Ronaiza Cardoso
Ronaiza Cardoso
Jun 1
In less than 18 months, I had gone from an extremely basic understanding of HTML, to writing Ansible scripts, backend APIs in Ruby on Rails, and creating front-end components using R...

The same thing happened to me.
Conversation between siddharth nagavarapu and Jeremy Gunter.
Go to the profile of siddharth nagavarapu
siddharth nagavarapu
Jun 2

I partly disagree. I spend a good amount of time googling and using stack overflow but I try to have it as a practice to refer to the official documentation of any framework during development and not Google immediately. I’ve seen myself more impatient for result when am googling during development . I think having a cognitive strain is good and developers can rely on good ide’s to help them out .
Go to the profile of Jeremy Gunter
Jeremy Gunter
Jun 2

I agree that documentation is probably the best place to look when struggling with syntax, and I would encourage anyone who is learning to program to familiarize themselves with using the docs. However, once you get past syntax and need help with implementation or best-practices, the docs will leave you high and dry. Perhaps we could agree that both…
Recommended by Jeremy Gunter (author)
Go to the profile of Roxanne Henkle
Roxanne Henkle
Jun 1

I base my company on making searches. Searches for anything our clients need answers for. Performing searches, you are asking questions. Questions and searches light up your brain. Going further into your inquiries by reformulating, building onto or expanding upon the answers found is a great way of problem solving.
Recommended by Jeremy Gunter (author)
Go to the profile of bklau2006
bklau2006
Jun 1
the best in our profession don’t methodically scan and memorize documentation. Most, in fact, don’t bother memorizing anything they don’t have to.

The ironies of these is yet our interview process(coding and algorithms hazing) reeked of this memorizations…
Recommended by Jeremy Gunter (author)
Go to the profile of Silas Santos
Silas Santos
Jun 2
When you start googling for answers to a problem you are facing, you quickly learn that you are not the only person to deal with this, and that other people will come up with vastly ...

This is the amazing! But, all “users” need to cultivate the habit of write about their discovered. I need make that
Recommended by Jeremy Gunter (author)
Go to the profile of Ski Bum
Ski Bum
Jun 1

Nobody can be an expert at everything. Yes, you do learn more by searching. Often, you gain insight into side effects, common failures associated with the technique you are searching, as well as best practices and alternate ways of achieving the solution. A good employer will value the ability to learn (and use tools) over just knowledge expertise…
Conversation between matt wilkie and Jeremy Gunter.
Go to the profile of matt wilkie
matt wilkie
Jun 2

I probably search a thousand times a day (hmmm, be a fun thing to do, quantify that). I pride myself in being an efficient searcher, above average (he thinks to himself, for himself). However I find myself caught in the mindset of searching embarassingly often. Forgetting that a few moments, or even many moments, of thinking and Reading The Fine…
Go to the profile of Jeremy Gunter
Jeremy Gunter
Jun 2

I agree, searching is just one tool to put in your belt. I’m a sketcher myself, and usually draw out elaborate flow charts to help me think my way through a problem. By no means am I implying that you should ONLY use google, but rather that it shouldn’t be something that is looked down on.
Recommended by Jeremy Gunter (author)
Go to the profile of Wayne Werner
Wayne Werner
Jun 1

Google is a far better information retrieval system than our brains. And the Internet contains orders of magnitudes more information about software development than I can fit in my head.

I find a broader knowledge base with the ability to dive deep is typically much more valuable than knowing one specific thing.
Conversation between Daniel S. Kim and Jeremy Gunter.
Go to the profile of Daniel S. Kim
Daniel S. Kim
Jun 2

As someone who is 10 weeks in a 15 week coding bootcamp, I think many of us beginners feel like we MUST memorize code or think we need to be able to summon code logic in an instance because we fear the technical interview.
We know we can’t flip out our smartphones or use a computer during the interview so we resort to memorizing things like how to…
Go to the profile of Jeremy Gunter
Jeremy Gunter
Jun 2

In my opinion, that just shows a failure in the hiring practices of employers. There won’t come a time in your career where someone will expect you to produce solutions to any typical problem w/o use of documentation at the very least. I’ve personally never had to face a whiteboard interview or the like, but I am sympathetic with how daunting that…
Go to the profile of Daniel S. Kim
Daniel S. Kim
Jun 2

That is great to know Jeremy, thank you for your input.
In the end, getting a programmer job is mostly a numbers game so I hope I can meet an employer early on who understands that.
Recommended by Jeremy Gunter (author)
Go to the profile of Aymen Toumi
Aymen Toumi
Jun 2

Learn the basics and look for the rest. The easiest way to accomplish and develop.
Recommended by Jeremy Gunter (author)
Go to the profile of Robear
Robear
Jun 2

Something a professor of mine told the class in college (waaaay before the Internet) has stuck with me all these years. He said “It doesn’t matter how much you know, as long as you know how to find the answer”.

How true.
Recommended by Jeremy Gunter (author)
Go to the profile of Amit Shaiwale
Amit Shaiwale
Jun 3
Never memorize something that you can look up.” — Albert Einstein

Vell said !
Recommended by Jeremy Gunter (author)
Go to the profile of Bill Bragg
Bill Bragg
Jun 1

I agree with the points made in this article. An unfortunate truth, though, is that many in charge of hiring in IT insist on wrought memorization and fact regurgitation in interview processes. Hopefully, HR and IT managers will eventually learn how to hire.
Conversation between Pablo Castro González and Jeremy Gunter.
Go to the profile of Pablo Castro González
Pablo Castro González
Jun 2
Very few programmers will remember every method name or function call the first time they see them. Even fewer still will rely solely on their memory to face the challenges in their ...

However, from time to time it seems like companies are looking for that kind of “freaks”, judging the way their interviews and evaluations work. I’ve seen many questions regarding the differentiation of functionalities according to specific versions of frameworks, languages, etc… so nonsense.
Go to the profile of Jeremy Gunter
Jeremy Gunter
Jun 2

From what I’ve noticed of interview prep videos, most of the time interviewers that use that style are more interested in hearing you speak your thoughts out-loud so they can understand your process, not assess your memory. Don’t allow those types of situations to stress you out, many times they aren’t testing you in the manner you expect. Here’s a…
Conversation between Emilio Estevez and Jeremy Gunter.
Go to the profile of Emilio Estevez
Emilio Estevez
Jun 2

Thank you for this article. I experience this self-inflicted struggle everyday. I don’t like to consider myself a programmer/developer because I have to google different syntax.

I’ve worked with programs in C, Python, JavaScript, PHP/HTML, Etc and have always been able to accomplish my goal with a little bit a research.
Go to the profile of Jeremy Gunter
Jeremy Gunter
Jun 2

I’ve been lucky to have a boss that is more interested in hearing me talk out a problem to show I understand it than worrying about how I’m going to implement it. Once I run through the problem verbally with him, he lets me alone to dig around on the web or in books and come up with a solution. Then once I submit the work, he’ll review my pull…
Conversation between Darren Burgess and Jeremy Gunter.
Go to the profile of Darren Burgess
Darren Burgess
Jun 1

You mention a Quora thread, but there is no link. Can you please post that link or fix the post?

Here:

“Don’t believe me? Check out this Quora question, where hundreds of other programmers all responded with basically the same opinion on the matter.”
Go to the profile of Jeremy Gunter
Jeremy Gunter
Jun 2

Thanks for pointing that out! I’ll go in and make sure the link is in there, but here it is:

https://www.quora.com/Do-developers-memorize-all-tags-classes-and-functions

No comments: