Rick Strahl's Weblog  

Wind, waves, code and everything in between...
.NET • C# • Markdown • WPF • All Things Web
Contact   •   Articles   •   Products   •   Support   •   Advertise
Sponsored by:
Markdown Monster - The Markdown Editor for Windows

The Search Engine Developer

On this page:

Scott Hanselman yesterday posted a piece on how easy it is to become what I call a Search Engine Developer. His post really hit home with me as I've done a lot of research for various development challenges in my last few work weeks where Google was a mainstay. I don't know about you, but I find myself using an ever increasing amount of intellectual content by searching for solutions online, which is a change from how I used to work not all that long ago. That doesn't just mean finding code and cutting and copying, but also searching for ideas and problems solved and applying that knowledge to my particular programming problems. Nevertheless, when I compare how I used to work in the days prior to the Internet and the mountains of shared programming knowledge today, it sometimes feels like I've become a slacker at best and a plagiarizer at worst as I don't have to stretch as far to solve common and not-so common problems today by using a search engine and the many developer resources available on the Internet.

To put this into context, here's a good one to ask yourself: If you had a job interview tomorrow and had to answer a bunch of heavy duty technical questions without Internet access, could you do it? To be honest, I'm not so sure I could - I've come to rely on being able to look up information online whether it's in search engines, code repositories or even my own blog. The concepts and ideas are all in my head, but many of the details and implementation issues often are not. I commit very little detail information these days into permanent memory it seems. My actual memory retention rate is probably very low outside of the commonly used stuff I use day in day out.

I suspect I'm not the only one…

How did we get here?

But it's not always been this way though at least not for me.

I've been doing software development for nearly 30 years now (scary thought that!) and I can remember the times back then when I didn't have any online resources. The only way I learned stuff was by going to school, reading a book or magazine article (lots of that for me) or going to a user group meeting to discuss programming in person with a few other like-minded souls. In those days there was a lot of 'discovery' on my own, even of small and common things, simply because there was no easy way to look things up. The 'offline', off-memory storage simply wasn't there - you either had it in your head or in a book or magazine buried in a pile at the back of a closet somewhere. :-) Sounds like fun dunn'it?

In a way looking back at it, it was fun. You really *had to* learn stuff and figure it out on your own very often - there was no easy cheating. No going online to snake a RegEx expression for validating a phone number, or finding an easy to use SMTP library in FoxPro, or easily do something as simple as base64 encoding in C. You had to sit down and figure it out on your own.

This went on for a long time too - it wasn't really until the end of the 90's that more development content than documentation started coming online. Most of it came from big vendors with product documentation, published articles from classic print magazines as well as the messy content from various developer forums that was difficult to wade through.

Then in the early to mid 2000's things changed as blogging started getting popular, and that's when online programming content really started taking off. It was free form user participation and the ability to pick your own topics to write in detail, about often complex technical content, that really got massive amounts of quality content online and started driving the Search Engine Developer paradigm.

Then in the late 2000's we started seeing more collaborative sites like StackOverflow for question and answer style conversations, and the proliferation of source code sharing sites like GitHub, CodePlex, BitBucket etc. that really brought code sharing to the general masses.

Today it's easy to find solutions to a fair percentage of programming problems that help both for troubleshooting and the learning process. If you look back and think about how far we've come especially in the last 10 years, it's pretty amazing how much of an impact the amount of online programming information and the ability to search it has brought us.

Hail the Search Engine Developer

One of Scott's points in his piece is that it's easy to get lazy and lose some of your edge by being purely a search engine developer. There's definitely something to be said for creating something from scratch, learning from the experience, pushing your knowledge limits, the thrill of discovery and for working through an idea from concept to completion on one's own.

But, this sort of coding seems to get less and less common, as there are fewer solutions that have to be worked out from scratch like that. I know it's true for me - I used to build lots of components and utilities from scratch. I still do to some extent but not nearly as in the past. Today a lot of those kinds of things are much more easily picked up through some utility code in a shared library or code snippet found online and modified and directly integrated into code.

Now I'm not suggesting that pure cut and paste or library integration is always great idea. It's always a good idea to understand the code you're integrating to some extent.

But to be honest - especially with libraries that's not always the case. When I look for a QR reader library to integrate into an application, I'm not going to ask too many questions on how it works for example. OTOH, if I find a short code snippet for integration I usually spend a bit of time experimenting around with that code and usually end up modifying, customizing and abstracting it before integrating to mitigate the 'external code' aspect.

The obvious advantage is that in that process you understand the concepts involved and the code you're working with isn't just a black box. I think that's useful when already so much of the code we use from vendors and tools/libraries that we have very little control over, even if source code is provided. While the QR library I used recently might be open source, I have no innate desire to dig into that source since I have no particular interest or even the background to deal with that sort of interface.

We may joke about the Search Engine Developer and Cut and Paste Development, but the truth is that we are much, much better off NOT having to reinvent the wheel for all these little programming problems. While it may not be very complex to build some string translation routines that extract text easily with a few parameters, even simple code like that that is reliable and works in many different scenarios does take some time to create if you had to do it from scratch. Is it be better to create it from scratch or use somebody's (hopefully) tested and already written solution? I think we all know what the answer to that is, ideals be damned. It's perfectly acceptable to not reinvent that sort of wheel. Getting some of the trivial things taken care of by searching and *adapting* code found online lets us focus on things that really matter in an application rather than the mundane plumbing code that is necessary, but not necessarily a key piece of the application.

With all this shared code available we have more time to build new solutions, come up with new ideas and expand the wealth of knowledge that is already out there. As they say, we can stand on the shoulder of giants to extend the reach of our skills even further.

It's fun to wax nostalgic about 'back in the day' stories, but I don't miss those days one bit. I don't think anybody does - having more information, at least for our jobs as software developers is definitely beneficial and it allows us to focus on doing the work in our problem domain and leaving the little things to solutions that have been solved a million times over.

As one commenter on Scott's post - Nathan - pointed out:

"Never commit to memory what can be easily looked up in books"
   - Albert Einstein

In today's terms, Einstein's books are the Internet. It's much easier to 'store' and access information there. Whether you write it down for later retrieval - in a blog post perhaps - or whether you search, there's no shame in using the Internet as a retrieval source and an extension of our somewhat limited memory store.

'Already been done' Syndrome

These days I find myself doing much less development truly from scratch. I'd like to, but the reality is that it's getting much harder to justify and build something truly unique. The Internet is a vast place, and there's so much stuff out there already that's already been done. If you think of some sort of problem you need to solve, chances are pretty good that somebody's already thought of it and has tackled that problem and solved it.

It's also very easy to fall into the trap that that that's already been done. In some cases that's a great thing - if it's something trivial or non-relevant to your main problem domain then that's already been done is a godsend.

In some cases however, it can also lead to giving up on good ideas. If you have some smart new idea and you check around on the Internet to see if anybody else has done this already, you may find a previous implementation and simply decide it's not worth to build your great new idea out. The problem with this thinking can be that some good ideas are not getting the benefit of alternate and possibly much better implementations. An opportunity lost.

I know there've been a few things I've wanted to do in the past that I didn't, simply because there were already similar solutions out there. Even if those other solutions weren't perfect and I felt that maybe I could do better, it's hard to get motivated with existing solutions out there and then playing catch-up and probably ending up having to compete with an incumbent. I suspect a lot of new development never happens because of this.

But sometimes it definitely makes sense to reinvent a wheel and do a better job. We've all seen really bad libraries or applications out there that could benefit from somebody with a different point of view and maybe more dedication taking a stab at it.

How are your Search Engine Skills?

If you are a good developer today, you have to be good at using search engines to make yourself productive in your work. Being good at searching and finding answers to development questions is one of many critical skills these days. Today's software development involves so many technologies, tools and environments that there are very few - if any - people around who can keep it all in their heads. Information overload is a problem and you probably have a core set of that you use regularly that are always 'just there', but for the rest of it you might as well use The Google to help you jog your memory.

I'm always amazed however that a lot of developers are not very good at coaxing useful information out of search engines. I often feel like sending people off to Let me Google that for you. In this day and age, especially with the wealth of cumulative Q&A knowledge available in StackOverflow there's no reason not be searching efficiently and finding answers to a lot of developer information. Yet I still find developers who are not actually managing to get useful information out of search queries.

There are several things that are critical here. You need to be able to:

  • Find the right keywords to search on - get familiar with advance search options
  • Narrow down search results
  • Differentiate the good from the bad results
  • Use what you find responsibly - learn from the code

One important point about any code you find is that cutting and pasting code blindly without actually understanding it is a recipe for disaster. Always play with code you find and learn from it, then integrate. I find it's often a good idea to review the code then implement it by typing it in (preferably without peeking at the original) instead of cutting and pasting. This helps understanding and also retention of the code that was just snatched and integrated into an application. For more complex pieces like full libraries that's not always an option or even desirable, but especially with shorter solutions like stuff you find on StackOverflow this is good advice.

The big problem with sites like StackOverflow or tons of open source code available to plug in, it's not easy to avoid the simple solution of just using cut and paste or plunking in a library and forgetting about it. And unfortunately that temptation often results in untested or misunderstood code getting integrated into solutions. Bottom line is: make an effort to understand what you're integrating.

Best of both Worlds

We live in an information rich world - it's not 1995 any more and the Internet and the ability to search its vast resources are here to stay. We can choose to stay sharp and build our skillset the old fashioned way and as Scott so frequently suggests we should Sharpen the Saw to keep learning and improving on what we already know. Search engines are another powerful tool in our arsenal and we can and should let them help  us do our job and make that job easier. But at the same time we shouldn't let them lull us into a false sense of security - into a sense of thinking that all we need is information at our fingertips. Mad Skillz is still a desirable feature for the modern developer and keeping up with those skills is an important part of being a developer.

Posted in Musings  

The Voices of Reason


August 24, 2013

# re: The Search Engine Developer

I think that this is a similar question to tests and exams that we all had to take. We have to memorize so much information to pass a test, and usually after a short while you remember nothing. I always ask myself: "why? what is it good for?". In the real world, even in the days prior to the internet, if you needed information or dates you sought it in books, libraries and other resources. You didn't have to sit at your desk trying to salvage it from memory. So what are "closed tests" good for?

Same goes for development. You can argue whether you can write a code without Googling for it, but why would you? You can code using a notepad and a compiler, without IDE and intellisense, but why would you? You can write Assembly or C instead of C# or Java, but why would you?

There are probably endless examples similar to this.

Today's world is an internet world and I see no reason to go back. Naturally, this doesn't mean that you have to copy-paste everything. You must understand what you are doing and you must understand what you are coding. But doesn't mean that you shouldn't look up code in the internet. I don't know where the boundary is and whether there should be a boundary at all. Personally I prefer to try and write code myself and use the internet as a reference only.

Doug Dodge
August 24, 2013

# re: The Search Engine Developer

Rick, a nice thoughtful post. I see several issues you have brought up. I'll use a couple analogies here.

1. Pioneers - Some folks just have to be the ones that find the trail ('Pioneer'- Honeytree - song) You're driven to do this. Early on (I have also been programming for around 30 years) we had to be able to not only build the structure we needed to find the place to put it, cut the trees down, fight off the bears and so forth. That was ADVENTURE. Doing something new. Discovery as you put it.

2. Now, we go to Home Depot to get the parts and the 2x4 is exactly 1.5 x 3.5 inches. And we have to get permits; and inspections. But we still can in some cases have a say in the design and materials used. I live in a custom-designed (me) and built home. I would have a lot of trouble living in, say, Irvine CA where there are so many rules you can't leave your own car in your own driveway for more than about 4 hours. No thanks.

3. How buildings are built. Even now you still need to understand the basics and mechanics of the process. This hasn't changed though the materials definitely have. So, rather than use oiled hemp and lead to join two cast iron sewer pipes together we use schedule 80 PVC and a hacksaw and glue. BUT water still needs to run downhill.

4. So if someone is a Search Engine Developer WITH a background in how things should get built - I see that as a potential efficiency booster. But for someone who doesn't know the basics (using the building analogy) of how to build things they will be just as inefficient, or more so by virtue of being overwhelmed with their options. IOW, they won't know what NOT to use because they don't have those painful experiences yet.

So, for me, the search engine is a huge potential productivity booster. I can still get overwhelmed by the number of options but I have some experiences that help me remember to slow down a little and think things through. Right now I am looking at the ServiceStack offerings. They may (or may not) turn out to be good additions to my tool belt. But, I know I need to keep the number of tools to the right number and mix. Search engines don't always help there because I may need a slightly different set of tools for what I do.

You are a pioneer Rick. You need the adventure and discovery. I do too but these days I find that the joy of discovery has not been lost - just found from different sources. Google will never replace the user group interaction but it does provide a great set of reference books - just delivered in a different manner.

You still think and create and produce and find new 'stuff''. I have watced you for many years now transition from one technology to newer approaches and I have been amazed and impressed and, candidly, grateful for your efforts and the result of them. I still use your products and they are still great offerings.

But while the old territory where we found the original thrill is long gone the thrill is not. I still have a pile of some 15-20 books to the left of my desk on the floor that are waiting for me to get to them. That part never stops and I am glad for it. I look forward to the continued grand adventure.

Pioneer - that's for me. What is over that next hill? I want to go look.

August 24, 2013

# re: The Search Engine Developer

I think this is all a result of the open source movement. Since so much code is freely available, a developer looking for answers would be a fool not to see what is currently available before doing something from scratch. Todays culture is all about productivity and leaning on someone else work is a good way to be productive.

August 25, 2013

# re: The Search Engine Developer

We Google because we can, which of course has it's pros/cons. We may do so because we don't own the right book, we prefer a different explanation other than the vendor's, we are in a hurry, or just lazy. It's the world we are in.

Many years ago, programming referred to a more narrow set of skills than today. Efficiency of algorithms and memory management mattered more. Today it's javascript, CSS, HTML, C#, Linq, SQL, innumerable frameworks, and on and on. We are abstracted away the importance of good design. How many Linq/SQL or Linq/Entities developers check their query plans to remove clustered index scans?

Developers should practice solving problems with algorithms -- if nothing else other than to see if they remember how to.

Perhaps more philosophically, developers are shaped by their UI, their tools, vendor marketing, the buzz. The number of moving parts in a modern day business application is embarrassing.

This post tempts me to pull out my copy of Turbo Pascal and write a doubly-linked list (if I had a PC with a floppy drive :-) ).

Rick Strahl
August 25, 2013

# re: The Search Engine Developer

@steve - "The number of moving parts in a modern day business application is embarrassing." - a very telling statement that makes me wonder sometimes when we tout our so called improved development paradigms today.

August 25, 2013

# re: The Search Engine Developer

The role of a developer is to find out which code needs to be written and write it. The most productive developer will be the one that accomplishes with least work what is necessary to adequately solve the problem, which means not solving every problem that has been solved before.

With this in mind it worries me when @steve says that developers should practice solving problems with algorithms. Developers should solve problems with algorithms if they need those algorithms in their line of work. If they don't, they don't have to.

Obviously these are extraordinary statements since most problem solving for developers involve "algorithms" of some kind, to phrase the problem in the form of a program if nothing else. But to tick off things because "that's what we do" is troubling. If that is what "we do" and people get on without it, what does that mean? Does it always necessarily mean that people are choosing to solve their problems in suboptimal ways? Are you specifying in excruciating detail what could be expressed otherwise and be easier to maintain?

Don't get me wrong. Part of being a good developer is to be able to dig one or several layers down in order to have the tools to fix something. But this is strictly pragmatic and can be derived from the formulation of the problem - it's necessary to solve the original problem.

Taking an interest in the foundations and trying to work out different ways of doing things are great fun, a good way to build your own capabilities and necessary for the progression of the craft. I enjoy them myself and I am not saying to not do them; the willingness to do this is one more useful tool in a set of skills. But they are not themselves essential to being a developer other than as may be needed from time to time. Always insisting on everyone's submersion and mastery in as many principles as possible, disjoint from actual need, is nothing less than chest hair-driven development.

In so far as there is a problem, it's that people are not being taught how to frame what they want to accomplish in code, and why different ways of solving a problem has different upsides and downsides. Design patterns are a particularly ham-fisted way of trying to solve this. If we taught cooking like we taught programming, cooks would know their favorite six or seven utensils by heart and how to do the individual motions like separating eggs or reducing sauce, but never had given serious thought to composing a meal. Which is why if these people go into the world and end up using the microwave a lot, I don't think that's the root of the problem.

Rick Strahl
August 25, 2013

# re: The Search Engine Developer

@Jesper - Yup - I think the problem is the temptation that you rely too much on 'research' and not enough on actual problem solving.

I imagine software developers learning to code today have a completely different learning path than I did back in the early eighties. I think it's a different approach, but clearly we're still managing to crank out lots of brilliant kids that know how to innovate and create new stuff. Innovation will never die although for the bored masses things might look a little different.

It's definitely an interesting discussion.

August 25, 2013

# re: The Search Engine Developer

That's an interesting point. The line between researching libraries and trying to implement your own is not only plastic and highly context-sensitive, it can't be drawn objectively correctly even under controlled circumstances. It comes down to a judgement call every time and it'll differ based on who makes the judgement. Faulting someone else's judgement in hindsight, especially when you think you know more than them, is terribly easy and you'd have to really go to the zoo to be completely incorrect. Even if you're aware of it, it can be difficult to stay away.

Keith Nicholas
August 25, 2013

# re: The Search Engine Developer

Essentially this is not a lot different from electronics design where you look for reference designs, and pre packaged components that will do what you want. You then have to take an engineering approach to elegantly weaving all this into a solution that works.

A lot of being a developer these days, beyond coding skills, is simply being aware of all kinds of ways of approaching problems and knowing there is something to search for!

Joe Brinkman
August 26, 2013

# re: The Search Engine Developer

I remember 20 years ago when I worked in IT. A Microsoft consultant told me that if I only learned one thing that it should be to learn how to search TechNet. This is true of so many professions. Whether you are a lawyer, doctor, architect or programmer: the acquisition of knowledge is an important first step in many endeavors. What separates the average person from gifted individuals is in the application of that knowledge.

Luke Sigler
August 26, 2013

# re: The Search Engine Developer

@Keith Nicholas

Agree about the knowing there is something to search for part. That seems to be the new separation between "jr" and "sr" now. At least in my experience.

I remember when I first picked up a copy of "ASP.NET in 21 days". I remember the days of Googling ".net" and getting back like 7 results. Frustrating indeed. I also don't want to go back to them.

The part that I guess is comforting to me is the fact that we live in such a, for lack of a better word, greedy society. Back in the early 20th century, the thought was that people would only have to work 12 hours a week because technology would automate everything. That has not been the case. The easier something gets, it is now just considered required.

Everytime I go to Github, it makes me realize that the days of standing on the shoulder's of giants is gone. I view it more as being carried around by an army of ants.

Tim Booker
August 26, 2013

# re: The Search Engine Developer

Programming is a skill, not just an accumulation of knowledge. Job interviews that ask for a shopping list of technical information rather than testing for actual programming ability entirely miss the point. OK, while we are busy coding we acquire knowledge along the way, this is known as "experience" and is definitely a useful thing to have. But whether we keep masses of information in our heads or frequently refer to Google, it's absolutely vital to keep practicing and refining our skills. In your day job, no problem, use the library or StackOverflow post that already provides a solution. The library is perhaps fairly mature, or the StackOverflow answer has been reviewed and upvoted. But there is no shame in practicing your skills by creating something that may already exist. Choose a language and a project and just make something. As Scott mentioned in his original post, we grow when we are outside our comfort zones. At worst you will just be refining your skills and gaining experience, but you may be building a better mousetrap. And don't forget that each time you Google something you might just be becoming a better Googler.

Dariusz Lenartowicz
August 28, 2013

# re: The Search Engine Developer

Today you say 'Google it' not search. So, 20 years ago you Google books, magazine, etc. Technology gives us more ways to search informations. Nothing was changed then.

August 29, 2013

# re: The Search Engine Developer

"I find it's often a good idea to review the code then implement it by typing it in (preferably without peeking at the original) instead of cutting and pasting."

Heh, that's more or less what I said in a comment on Scott's original post. But it's rock solid advice - because it forces you to actually understand the code you just lifted; personally I more often than not get it wrong especially when I do an on the fly refactor when typing in someone else's code, which then forces you to understand it even better so that you can fix it; and it has happened before that this leads to uncovering bugs in the original posted code, thereby improving the total sum of code quality in the universe. \o/

Pity SO doesn't have a "strict" mode that won't let you copy code unless you manually turn off the setting...

August 30, 2013

# re: The Search Engine Developer

One thing not yet mentioned in the comments is the effect of Google on our youth. I too have been coding now for thirty years (which is beyond scary because i feel like I am 12 at best inside). In fact I have been building WWWC apps for close to 15 years (even scarier). I learned what OOP was with Rick's tools. Rick is my Gates or Jobs because without WWWC I would be working for the man, and we all know how much THAT sucks.

Ok, back to the youth comment. My son is 12. He pays games that I could only have dreamt of playing when I actually had time or the desire to play a video game. His entire world is screen based. There is not a single activity he prefers that does not involve some sort of screen. His brain does not really 'think' because as discussed above, why bother? Just GET, or rather SEARCH, or GOOGLE the info.

I find it really really sad to be honest. Rick uses the term DISCOVERY above and I believe the word 'thrill' was used as well. I still get a rush when I see an app I wrote DO something useful. When a tedious and time consuming process is reduced to a button push. That is my porn.

Then there's my son. He gets off on killing zombies in a virtual world that is more real than the real world or building bricks in Minecraft instead of building something by hand. I try to teach him a few chords on the guitar or piano, and he's like 'what a waste of time, watch this' - minutes later he's assembled a kick ass 'beat' on his computer that in the past would have taken an expert recording engineer and producer along with top notch session guys to create in an expensive studio.

Art without Photoshop? Really...

What will become of the young adult trying to make it in the tech world in 2023? Will writing code really be necessary by then? Will any web app not be available as SAAS?

I think if I boil it all down, I think we are heading towards the movie I will link you all to below. As i said above. It is pretty sad.


Rick Strahl
August 30, 2013

# re: The Search Engine Developer

@MB - I hear 'ya on the 'screen based reality'. I totally understand what you're saying and I can feel the pull of that myself even though I've lived through the time of a no-screen life. And yes I think it is scary as we all become more and more consumers of information and materials, rather than producers and innovators.

The other issue with that is that it gives enormous control to companies like Google, Apple and Microsoft, the gaming companies, and by extension - our nefarious government that is now openly spying on all of us. We've basically sold all of our rights out to this new electronic reality.

There are lots of related issues to this, but not to be all negative, there is still innovation and ingenious discovery and most of that wouldn't be possible without the easy access to information. As with most things technology is a double-edged sword that we need to learn how to wield appropriately.

Maybe that's another topic for a future blog post.

August 31, 2013

# re: The Search Engine Developer

Boy you've struck a nerve. I myself over the past five years have struggled with the issue. As my employer has thinned out the herd and placed more work on those left behind, I find myself searching for a solution rather than building from scratch (even if if only gets me 70% there, I'll finish it up). The time and pressures of getting the work done sooner provoke me to be a search engine developer. I also find myself working for extended times on one platform, that I sometimes forget how to do the simplest things on another.

September 01, 2013

# re: The Search Engine Developer

@MB - as someone who has had to actually remove all of the fuses from my own son's stuff from time to time, just to force him outside*, I sympathize with you! But, surely if your son is building things in Minecraft then it's somewhat analogous to us when we were kids with our Lego and whatnot - building a castle out of lego *is* a tedious time consuming task.

How can we on the one hand bemoan using google to help us develop kick ass apps, whilst at the same dumbing down other's lives with these same apps? The reality is, we can't, and we shouldn't, because what dumbing down is to some is lifting a burden to others....

Of course we want them to appreciate their tools, to understand the principles behind what they are doing, but by the same token did we all build our own houses, or dig our own wells? Could we really do that if we wanted to? Why would we even want to engage in that mind numbing drudgery (and believe me, I know, digging a well is NOT fun)

I would personally be of the opinion that as long as our kids are creating things, the medium really doesn't matter - because what they're doing is using that medium as an expression of their own thought processes. And that expression can only lead to more questions; some will choose to use the internet to find the answers, some will figure it out by themselves and some will give up and go outside and figure out something else. But as long as the creative spark is there, they'll create. And that can only be A Good Thing.

And remember - you can always take out the fuses!

*And be happy if he replaces them himself....

Jay R. Wren
September 02, 2013

# re: The Search Engine Developer

https://en.wikiquote.org/wiki/Albert_Einstein#1920s 6th major bullet

[I do not] carry such information in my mind since it is readily available in books. ...The value of a college education is not the learning of many facts but the training of the mind to think.
In response to not knowing the speed of sound as included in the Edison Test: New York Times (18 May 1921); Einstein: His Life and Times (1947) Philipp Frank, p. 185; Einstein, A Life (1996) by Denis Brian, p. 129; "Einstein Due Today" (February 2005) edited by József Illy, Manuscript 25-32 of the Einstein Paper Project; all previous sources as per Einstein His Life and Universe (2007) by Walter Isaacson, p. 299
Unsourced variants: "I never commit to memory anything that can easily be looked up in a book" and "Never memorize what you can look up in books." (The second version is found in"Recording the Experience" (10 June 2004) at The Library of Congress, but no citation to Einstein's writings is given.)

April 14, 2014

# re: The Search Engine Developer

I think what is being debated here is actually knowledge (ie facts and figures) vs understanding. If you have knowledge without understanding you will get nowhere. What the internet has achieved is the "outsourcing" of knowledge. You do not need to know everything anymore, as long as you can figure things out. In fact it would a little silly to try to memorize what Google can give you in a second or two. But if you don't understand the code snippet you are looking at you cannot even begin to evaluate whether it can be of use to you or not.

In some countries, especially at University level, you are allowed to bring all the books and calculators you want into your exams. Why? Because the exams test your understanding of the problem, not your knowledge. No book or website is going to help you figure out the solution to the problem posed in the time allowed, unless you already have the necessary understanding.

West Wind  © Rick Strahl, West Wind Technologies, 2005 - 2024