
Am I really a developer or just a good Googler? - reinhardt
http://www.hanselman.com/blog/AmIReallyADeveloperOrJustAGoodGoogler.aspx
======
markbnj
>> Third, try programming for a day without Googling. Then two days, maybe a
week. See how it feels. Remember that there was a time we programmed without
copying our work.

It's not usually, or even often, about copying work for me. I google because
there is no freaking way I can remember all the details of linux, python,
bash, regular expressions, flask, elasticsearch, redis, haproxy, postgresql,
mongodb, Google Cloud Platform, kubernetes, logstash, kibana, Java... that's a
real list from my last project. If you were going to hire me for a position
doing roughly the same thing, and you stuck me in a room and picked questions
off a list related to those things I set out above, with the understanding
that I am good enough for you if I can answer the question, and not good
enough if I can't... it's a crapshoot. 100%. I may have spent hours preparing
for the interview. You may have spent hours preparing for the interview. And
then you ask me something like "In an elasticsearch mapping template how would
you retain the untokenized value of a string for use in a returned list of
aggregates?" and maybe I did that yesterday and remember, or maybe we should
just both go back to whatever we were doing before we met.

I'm interviewing right now, and if you can't tell it's frustrating. I'm not
valuable unless I am experienced and capable with a huge list of technologies,
and hey, as a reward you the interviewer get to pick anything you want from
that huge list and try to trip me up with it! ;)

~~~
gregpilling
In real life, without an internet connection (say 1980) you would have had
books. Life is an open book test, as the saying goes.

~~~
anexprogrammer
Yes, but chances are you'd have a fairly static set.

For serverside, you'd have K&R, Stroustrup or the Sun Java books, W Richard
Stevens, perhaps Design & Implementation of BSD and maybe a domain book or two
and you're good to go - for years and years. There'd perhaps be some
ludicrously expensive object library that's needed for some domain detail -
but it was bought as 1.9, and will stay 1.9 forever because ludicrously
expensive and management. You didn't much care that there was a new C++ or C
standard release, until addison Wesley put out the book to go with it and
management got around to buying tech the relevant updates.

Now you're mucking about with serverside and there's 20 different
technologies, all being updated and security patched constantly. The project
you did 6 months ago relies on some deprecated function set, and the prev
release of SomeThing and PostreSQL, and half a dozen other toolsets and
libraries. The next project is going to use WizzyNewTech0.8 as well. You
either Google constantly, or fail and go crazy.

There were advantages to the 90s - you'd have newsgroups for support that were
free of spam, and full of techies. You could spend much more time solving
actual problems than mucking about deciding on and changing the framework set.
You didn't get pwned by 0 days if you didn't update your tech constantly
either.

------
iamben
Been talking about this a lot with friends/peers recently. Personally I think
half the skill is knowing _what_ to Google.

My mum's husband is a painter and decorator. Every house is different, but he
has built up a set of skills over the years he's been active that allow him to
broadly apply his knowledge to understand _how_ to solve a problem.

Similarly, I can't always solve the problem, but I do know where to start
asking questions, and I do know how to follow those up _efficiently_. Is this
when I Google for the docs, for answers to a problem, for a place to find
help? And then after that, it's about knowing the next steps, knowing which
part is likely to be the next relevant thing to Google/research.

Do I get stuff done? Sure. Do I remember how to do it next time? Sometimes.
But sometimes it's just enough to know how to start solving the next problem.
I think we just feel a bit fraudulent because Google is easier. I'd be
surprised if anyone ever said "Am I good at xxxxx or just good at going to the
library, choosing the right books and reading the required parts?"

~~~
49531
I'd say it's also worth mentioning that after knowing what to google is
knowing how to apply what you've found. Most of the time an answer on
stackoverflow isn't something you can copypaste and have work sans unintended
consequences.

~~~
grogenaut
I've sent my brother (non-programmer) many code snippets and google results to
help him learn python. They don't help because the problems he's trying to
solve are about 8 levels of programming knowledge above what his current
knowledge level is (trying to understand a for loop). Conversely he asked me
to automate some java application workflow for him and even though I haven't
done swing in 8 years it was trivial for me to do. It might have taken him
months even with googling.

~~~
CydeWeys
Totally. I've been programming for twenty years now. The way I learn a new
language/framework/API is by Googling for examples. I've found it to be the
fastest way to pick up something new, to the point where I stop reading the
official documentation if it isn't heavy on code samples and go search for
something someone else has written that is.

You can pick up so much about a new tool so quickly simply by applying an
existing broad knowledge base of programming information to a few examples.

------
shrugger
I feel like the whole impostor syndrome thing has gone too far. At this point,
we have legitimately talented developers questioning whether or not they are
'good' enough and it is actually quite frustrating to see.

I sort of understand it from the students' perspectives, because they have a
professor to compare themselves to and aspire to, I think in that scenario it
spurs self-improvement but in the workplace it seems like it would only be
counterproductive at best to compare yourself to other coworkers or even other
people in the field.

I remember when I first started, I never thought "Shit, will I ever be as good
at Scheme as Sussman?" I just worked the exercises and kept moving forward.

Nowadays, there seems to be a real strong pressure to be aware of all the new
technologies, newest libraries, and all this material that nobody could ever
possibly have time to completely understand, and it drives people crazy, I
think.

~~~
hashkb
Have to point out: we also have legitimately terrible developers using
Impostor Syndrome as a political tool to keep their jobs and write whiny blog
posts.

Everyone should have a healthy way of dealing with feeling inadequate, besides
whining. (e.g. learning things)

~~~
jjoonathan
If your answer to FOMO / imposter syndrome is "learn more" then you'll quickly
find yourself mired in analysis paralysis. It's a strategy that simply doesn't
scale to today's world where there is more to learn than can be learned. A
better strategy is to develop a sense for the marginal value of learning so
that you can decide at some point to stop learning and start working (or,
equivalently, choose the right mix of the two). This still leaves the
psychological problem unaddressed, so solutions that tackle it head on have
their place.

The solution for dealing with actual imposters is to fire them. If, somehow,
they manage to use "imposter syndrome" as a deflection (I haven't seen this
play in the wild and I'm not convinced it's prevalent or even could be made to
work), then gather evidence that they aren't pulling their weight and proceed
to use it. If that doesn't work, it's not because of some stupid blog post,
it's because there's stronger politics at play. Abort/retry/ignore as
warranted.

~~~
tetrep
I think that by "learn more" they meant ensure that you're always learning.
It's not that you should learn everything, but rather just ensure you're
always learning _something_ , always growing. This is something imposters
don't do.

~~~
jjoonathan
> ensure that you're always learning

That's a good idea in general, but it doesn't address the specific problem of
imposter syndrome.

> This is something imposters don't do.

If you believe that this is true then it addresses the problem of imposter
syndrome. The danger is that you might then have to deal with cognitive
dissonance if you were confronted with someone who ramped so slowly or started
from so far behind that they couldn't be expected to make a net positive
contribution to the team within a reasonable timeframe. It's entirely possible
to try and fail, and while we should all admire the "try," that doesn't mean
you or your employer should be on the hook for funding it.

------
88e282102ae2e5b
I feel ridiculous saying this, but my secret is that I read the documentation
of whatever tool I'm using. Google answers beginner questions so well that I
never even thought to do this when I was first learning, and when googling
started to fail me I would just fall back on the scientific method to figure
out how a library worked. Perhaps it was a good exercise in critical thinking,
but it was terrible for productivity.

~~~
alistproducer2
Yep, documentation and source when googling begins to fail.

~~~
zo1
And occasionally you'll happen to come across a bug in a library you thought
was beyond your understanding/comprehension.

~~~
buu700
I've found this to be the case much more often than "occasionally" since I've
started habitually comparing third-party software's behaviour to relevant
specs/documentation rather than assuming whatever the implementation does is
correct.

I've caught and reported several Chrome vulnerabilities this way just in the
course of normal usage, and have to work around bugs in libraries that my code
depends on (often involving poking around said libraries' code for insight
into the problem) on a fairly regular basis.

------
Manishearth
As someone who has been programming in Rust since before 1.0, I have been
through the probably rare experience of working with an un-Googleable
language. I relied solely on docs and occasionally the mercy of helpful folks
on IRC, and it turned out OK.

A side effect of this is that I still never Google for Rust answers, even
though there are tons to be found now.

However, if I was programming in Javascript, which has been the language I've
known for the longest and done the most in, I would still Google everything
because I'm lazy. I'm pretty sure I don't need to, it's just faster. It's
possible to be a Google-programmer out of laziness and not necessity.

Diving into an un-googleable language (or ecosystem -- many closed-source
ecosystems at work would be un-googleable or undocumented; I recall that
understanding the codebase for my internship required me to either read tons
of code or ask people with arcane inside knowledge) can help hone these
skills. Or just promise to not use Google for something.

~~~
programLyrique
For rust, although there are now lots of answers, many use uncompatible
versions of rust with the current one in my exprience, so still rather un-
Googleable.

------
tmpanon1234act
People need to focus more on getting results. We're collectively so steeped in
posturing about technology stacks and idiosyncratic decisionmaking that we've
missed the bigger picture: get something done. For instance, anyone who says
they factored in all the tradeoffs and then chose Haskell isn't trying to get
things done or build a sustainable business - they're trying to orchestrate a
technological boondoggle.

At the end of the day no one cares if you're a good developer. They care that
the service looks good and works well. Googling is how you build a better
service ergo do it and don't worry about it.

~~~
smileysteve
> We're collectively so steeped in posturing about technology stacks and
> idiosyncratic decisionmaking that we've missed the bigger picture: get
> something done.

> At the end of the day no one cares if you're a good developer. They care
> that the service looks good and works well.

Those decisions lead over time to an architecture that can good or bad, and
assuming your software has patches or improvements over time, that's
important.

Context: I've worked with too many startups with non-dry untested code that
are now getting past "looks good and works well" to needs to drastically
expand feature set or change underlying features.

~~~
tmpanon1234act
We do heavy backend unit/integration testing, less so on the frontend and a
lot of UAT. It's good enough to move fast with some confidence but yes
sometimes you have to do tough things and that comes from experience. I
recently wrote a distributed, cache-coherent session store for instance.
Googling is necessary not sufficient.

------
CydeWeys
Not gonna lie, I couldn't make heads nor tails of this blog post until I
reached the very end, and realized they were using "Googler" to mean "doing
Google searches". I kept thinking "Why would being a good developer and being
a Googler be mutually exclusive?!"

~~~
melling
I didn't read the article and I knew what he meant.

20 years ago I'd buy books to learn Java, Linux, etc. These days if I want to
learn something, I just start Googling.

I still think organized and structured information is helpful. We just need to
devise a better way. I'm using Github for some things:

[https://github.com/melling/ComputerLanguages](https://github.com/melling/ComputerLanguages)

And for Swift and iOS where I want to go deeper, I'm creating my own Cookbook,
and perhaps my own search engine:

[http://www.h4labs.com/dev/ios/swift_cookbook.html](http://www.h4labs.com/dev/ios/swift_cookbook.html)

~~~
CydeWeys
You didn't grok the point of my comment, so let me expand on it.

Someone who works at Google is called a "Googler". When you are used to
constantly hearing a word used with meaning A, and almost never meaning B, it
can be quite confusing when you hear it in a context where someone uses
meaning B, especially when meaning A sort of fits. So you can imagine my
confusion when I parsed the entire article as "Why would being a good software
engineer and [working for Google] be mutually exclusive? They usually go hand-
in-hand!"

~~~
melling
I did understand your comment. I know someone who works at Google is called a
Googler. However, from the context of the subject, I knew a person who worked
at Google would not have such a worry, while someone who learned how to
program by Googling would have such a worry. Many programmers are self-taught.
It's gotta be quite common to wonder if you know enough to do a particular job
if you're Google'ibg your way to proficiency.

~~~
CydeWeys
Actually, imposter syndrome is more common at Google than most other
companies. This makes sense; imposter syndrome comes from a mismatch of
judging your own talents versus that you perceive from your peers, so you are
more likely to feel unsure of your own abilities when your coworkers are
world-class leaders of their field than if they are just random average
engineers. A lot of attention is paid to raising awareness of imposter
syndrome during new employee orientation, and all new employees are assigned a
mentor to help guide them through their initial months, again with lots of
emphasis placed on ensuring that people feel like they belong.

------
bikamonki
Say you'd like to upgrade your laptop but you are limited to maybe a few (not
easy) hardware tweaks where gains are really not that significant. You'd have
to work really hard for a few extra cycles, a few extra MB. So, through the
years you just become very efficient at using these limited resources at
particular and highly specialized tasks, after all, more than 8 programs
running at the same time just freeze the poor thing.

One day you discover a new gadget, an external HD. That is great news, you buy
one and move tons of unused data to the gadget. Your laptop is not faster now
but you can do software tweaks to virtually give you more performance.

Just some years later you discover something awesome: many others have decided
to hook their HDs together and share information stored on them. With this
discovery you realize that your laptop can now be almost completely devoted to
running algorithms, almost no resources are wasted in saving and retrieving
data from internal memory. You even develop a program to search and find data
on the hooked HDs which brings the responses almost instantly, allowing you to
become even better at running your algorithms. Even more so, this search
program constantly learns and improves at finding the right answers. At some
point you just code a few scripts to go get the answers of recurrently asked
questions, why saving the answers you say.

This laptop upgrade works dandy...until The network of HDs break :(

Did I answer the question?

------
sarreph
Can anybody shed light on how Googling for programming answers is seen in the
workplace?

I've always been a solo / start-up developer (for now), and sometimes I sit
back and think about how my (often zealous) use of SO and Google would bode
with a team of developers in an office.

Would I be considered (to use a loaded term) an _impostor_ if I was seen to be
using SO a lot, even if I produced good results?

\-- I think that last point — of good results — is key, but I am curious to
how co-workers perceive this kind of productivity...

~~~
pessimizer
As somebody who has worked in small and medium-sized businesses, I don't even
understand the discussion. If I can find on the web some way or some better
way to do something that I want to do, I literally put the link in the
comments to my code.

~~~
exodust
Wow, you actually go that far? Adding links in code? I was with you on "not
understanding discussion" because absolutely everyone in the workplace
searches and uses SO to find cool solutions, new tricks etc.

But adding those links to code I have never ever heard of! Not judging, but if
I were working in your team I'd be like "ok, what clown is putting stack
overflow links in the code!!"

~~~
jestar_jokin
I do it for attribution, partly out of respect to the original authors, and
partly to help resolve any licensing issues that may arrive - e.g. "This code
was taken from a site with no clear license on its use, so we may need to
replace it at some point."

~~~
exodust
Licensing issues? I'm not talking about entire plugins, and I didn't think
others were talking about that either. I thought we were talking about Stack
Overflow, where we learn the best way to iterate an array backwards or
something that amounts to a small component of what you're doing.

In that circumstance (which is what Stack Overflow is mainly used for) links
would not be necessary in your comments.

~~~
JdeBP
> _Licensing issues? [...] I thought we were talking about Stack Overflow_

Xe probably was.

* [https://meta.stackexchange.com/questions/272956/](https://meta.stackexchange.com/questions/272956/)

* [https://meta.stackexchange.com/questions/271080/](https://meta.stackexchange.com/questions/271080/)

* [https://meta.stackexchange.com/questions/25956/](https://meta.stackexchange.com/questions/25956/)

* [https://news.ycombinator.com/item?id=10905009](https://news.ycombinator.com/item?id=10905009)

~~~
exodust
That's quite sad. Most of the time SO is a source of learning a new technique
rather than copying code snippets letter for letter. We are shown a cool way
of doing something with fewer lines of code for example, and we apply that
method to our own projects.

If someone wants attribution for code, it better be something self-contained
with its own home on github or at least a blog somewhere with a unique name:
"my awesome plugin v1.0".

------
LoSboccacc
I programmed before google and before stack overflow. The povotal change was
that nobody post the forumization of support bothered to write documentation
worth reading. You didn't need google for simbian or for the java runtime of
for stdio. Everything was laid out in beautiful completness including race
conditions to watch out for and all valid parameters enumerated before your
eyes.

~~~
drumdance
Well, Java was still in beta as late as 1996 and the Internet was a huge part
of why it was attractive. I built my first company using it. Big mistake. It
was extremely buggy and slow. Something like StackOverflow would have been a
huge help to our development team.

------
pistle
Flip the question. Am I being a good developer if I'm not Googling it?

You are a creative problem solver. You have to understand your problem and put
together a solution. Within defined constraints of time, budget, and quality,
you must solve your problem.

Solid understanding of good developer practices and general algorithm or
application design principles marries WELL with talent in processing
information from the web. Bringing them together, you get past "solved"
challenges in completing your current task or project done.

I'd argue that being adequate at both is better. Relying too much on either
facet is worse than being good at both with a talent for bringing the two
together.

------
chiph
If I'm doing something I don't normally do (data access code, XML parsing,
etc), yeah, I'm going to look it up. And not feel any shame about it.

This might be because I started out in the engineering program in college, and
one of the tenets there is "don't trust your memory - look it up. Otherwise
people die."

------
askyourmother
A good developer will Google for direction to help get a little clarity on a
problem, maybe to review alternative ideas and solutions.

A bad developer will blindly copy and paste and use that. Painting-by-numbers,
Coding-by-google.

I have seen the problems with the latter, where a team of offshore devs built
a monster Java codebase by "doing the needful", which in this case was cutting
and pasting from the first result in Google. One of the devs was different, he
would cut and paste from bing. Fun times.

~~~
paganel
I guess that's a +1 for Google's SERPs when it comes to programming, unlike
how bad they do in other search sub-domains. But I'm biased, I'm an off-shore
programmer who has copy-pasted code snippets from Google searches countless
times (they were SE links in 99% of the cases). Of course I could have copied
the code by hand in order to feel morally superior, but as I am lazy I didn't
see any need for that. At least I always made sure to include a link to the SE
page from where the code snippet had been taken, so lets hope that SE won't
change their link structure anytime soon.

------
samsonradu
I think it would be a mistake to try programming without Google in the first
place. A smart developer should make the best out of the tools available.
Besides interviews I really can't imagine a real-world situation where you are
forced to develop without access to information (Google).

Also, our brain does not need to act as a data storage, it actually sucks at
it and we solved that problem a long time ago, by writing down information.

------
zw123456
This topic is very interesting to me from a little different perspective. I am
a senior member of technical staff at a very large company and often managers
will have me sit in on job interviews with candidates to cover the technical
side. Recently, I sat in an interview and I had my list of questions. It was a
telephone interview (1st round, not uncommon), I noticed that I could hear
subtle typing in the background as the manager asked various questions. When
it came time for the technical questions, I could hear a lot more typing. It
occurred to me that the candidate was probably googling the answers. After the
interview I mentioned it to the manager and she said "so, isn't that how you
guys do it anyhow ?". I was a little taken back and have to admit I did not
have any response. But, at least for this manager, how good someone is at
googling the answers is a legitimate point of evaluation for a prospective
candidate. I admit I use google, stackexchange and etc. to find answers, but
it is not my primiary source of information and I just don't think it is a
substitute for knowledge, is it ? This bothered me very much.

~~~
hackinthebochs
> but it is not my primiary source of information and I just don't think it is
> a substitute for knowledge, is it ?

I think this is the real problem of the "just google it!" culture in
programming. Expertise is devalued, even seen as wasteful. But ultimately
you'll never create anything genuinely new if you don't have a strong base of
knowledge to work from. Googling the details is great, but you have to have an
idea of what to google if you're doing anything beyond the most basic
development.

------
hashkb
Wait... big difference between Googling, even a lot; and copying code. If you
mindlessly copy code and it works, even once, without really understanding
(e.g. could you teach the pattern/trick/concept/etc to a teammate?) you are a
bad developer.

All things being equal, if you are a great Googler (or doc reader, or
whiteboard question asker) that is an aspect of being a strong dev.

------
phamilton
I've recently started defining my skill set as an engineer rather than a
developer. The difference, to me at least, is one of execution vs
implementation. Implementation can be done by a good Googler. Execution
requires good communication, recognizing and challenging assumptions, making
worthwhile tradeoffs, etc.

It's been a little bizarre to see how this focus has changed my development. I
sit in on team discussions about coding style and design patterns and find it
quite uninteresting. I code as much as the next person on the team, so I'm not
aspiring to be an ivory tower architect or anything, but I find weighing in on
engineering decisions adds far greater value.

~~~
turaw
For comparison, I would normally define an 'x' developer (depending on
specialty) as anyone who writes code and a software engineer as a developer
whose job description involves engineering, per the American Engineers'
Council for Professional Development [1]:

"The creative application of scientific principles to design or develop
structures, machines, apparatus, or manufacturing processes, or works
utilizing them singly or in combination; or to construct or operate the same
with full cognizance of their design; or to forecast their behavior under
specific operating conditions; all as respects an intended function, economics
of operation or safety to life and property."

In my ideal world, every developer would do what you're describing as
engineering, and the software engineers would be those who far exceed those
requirements.

------
rebootthesystem
Walk into any large engineering organization and you'll see stacks of
engineering books and reference materials everywhere. Companies also send
engineers to courses, seminars and conferences.

Reaching for reference materials and guidance is as much a part of engineering
as it is to remember the theory. If you don't have the implementation for a
Finite Impulse Response filter or a Binary Genetic Solver committed to memory,
that's OK. I care far more about whether or not you understand when and how to
apply them than whether or not you are a living engineering database.

So, yeah, Google away.

------
alistproducer2
A good engineer uses any tool that makes them a better engineer. You think
people who can recite algorithms also have the ability to learn a api,
library, or framework without googling or reading documentation?

------
BatFastard
Being a googler will often reveal solutions to specific problems. However it
rarely reveals if you should choose that solution, or the architecture that it
fits in, or anything larger than an algorithm.

------
colund
This kind of "imposter syndrome" in software development is for me rather
foreign. I've never been born with a silver spoon and I've seen lots of people
who are math and programming geniuses but I've worked very hard at learning
development and know how to do a good job now. I find it waste of energy to
philosophise on whether one is good or not. To my ears it sounds almost like
humble brag. Or a question from a girlfriend "am I ugly?" where the correct
answer is not yes... :)

------
ball_of_lint
Let's say we need to fix a car. We know that the yellow sprocket is broken and
needs to be replaced, but you don't know how to do it off the top of your
head. If you knew you could google how, would you fix it yourself? Now, would
you call yourself a mechanic for being able to google how and do it?

Google is an excellent tool. Programming, which can use google heavily, is
still a skill.

------
Xcelerate
It's the same thing when people ask me for help with computer problems. The
first thing I ask is "Did you Google the error message?" And then I normally
Google it for them and the first result is typically a forum post with someone
else who had the problem, and someone else has usually posted a solution.

~~~
enraged_camel
I used to feel the same way. Then I realized that it's not just about
Google'ing the error message. It's also about having enough experience and
knowledge to figure out which of the suggested solutions are both safe to try
_and_ likely to solve the issue.

It may seem silly, but most people who work with computers are genuinely
worried about doing the wrong thing (e.g. clicking the wrong button) and
permanently breaking something. This is why, at the first sign of trouble,
they come to us geeks with their tails tucked between their legs.

~~~
Xcelerate
> they come to us geeks with their tails tucked between their legs.

That's fine with me; I do the same thing when my car breaks or there is an
electrical problem. Some things I don't mind tinkering with — for other things
I would rather take the "simple" problem to an expert, even if it costs me a
lot.

------
sehugg
I learned programming by reading user manuals, books, and magazines. It was
kind of like Googling, except less random-access. But your documentation was
much more complete, because the tools were comparatively smaller.

Now fast-forward to 2016, and take something like Docker, which seems
conceptually simple but has lots of sharp corners like capabilities for
mapping mounts to userspace fuse volumes. The documentation would go obsolete
while it was being printed.

So don't be so hard on yourself -- most of us are just hot-gluing components
together, and if you are lucky enough to get paid writing that red-black tree
they interview for at Google/Facebook, then consider yourself lucky, and also
consider ripping someone else's version with unit tests.

------
shanselman
Gosh, this is a pretty old post. Maybe add (2013) to the title. Source: I
wrote the post.

------
voidr
I google for solutions all the time, does that mean I can be replaced by
anybody who can type a question into a search box? If that would be the case
then, companies would not hire highly skilled developers, they would just hire
people who can type.

You need to know:

* what the actual question is

* how to pick the good answer

* how to integrate the solution with what you already have

Being a good googler means you can solve almost any problem because you are
able to learn the solution on the fly, which can make you more effective than
people who have a lot more knowledge in their head but lack the skill to find
solutions to new problems.

------
spo81rty
As a developer you can't know everything about everything. We commonly have to
solve problems we are have never solved before. We have to use APIs we have
never used before. Google makes a huge difference in learning how.

------
buckbova
15 years with positions from analyst, engineer, to architect and I still
Google something for work every day. I don't feel bad about this at all.

I remember when I couldn't Google. Those were tough days.

~~~
Roboprog
Products in the 80s and early 90s usually came with books. Some of which were
pretty good, if you could get access to the books.

------
mwfunk
This is basically the Stack Overflow debate that comes up every few weeks on
HN, but I think it's a false dichotomy.

The implication is that "real developers" don't need SO/Google/etc., and that
our profession is plagued by incompetents who somehow get through the day by
copy/pasting code they found on the Internet without understanding how it
works.

Thing is, SO/Google/etc. are critical resources for most developers. Not using
the web as a research tool when appropriate is incredibly inefficient. No one
knows everything, and no one can know everything. Those resources don't just
help us find solutions for our problems, they're critical to learning.

I think the to-Google-or-not-to-Google debates are really people bothered by
other people who copy/paste things from SO without understanding the code they
are pasting. You should be getting 2 things from that exercise: you find the
solution to your problem, and you learn how it solves similar problems in the
future.

This isn't just for your benefit, it's for the benefit of the other people you
work with, and for the benefit of the shared code base if there is one.
Especially if it's a large, complicated code base that will live on long after
you move on to other things.

Everyone does the first part (using the solution), and almost everyone does
the second part (understanding the solution) to one degree or another.
However, there are a few people who will not only deny any responsibility for
the second part, but will actually be proud that they're not "wasting time" by
internalizing what they just did. Instead they're moving on to the next
problem to solve that they don't understand. They're optimizing for quantity
over quality of output, and for the appearance of efficiency over actual
efficiency.

So we all have a That Guy in mind when we feel guilty about finding solutions
on SO ("I don't wanna be That Guy, but this solves my problem so I should
probably use it..."). We may also have worked with one or more That Guys on a
shared codebase and gotten burned by it. It sucks to inherit code from That
Guy, because That Guy optimizes for scripted demos and perceived
functionality.

TL;DR I propose that the eternal debate about whether or not Google and SO
ruined software engineering is really just one group of people complaining
about That Guy, and another group of people who think they're being unfairly
accused of being That Guy. The fire is fueled by a small number of actual That
Guys sprinkled throughout the industry, but they are usually not participants
in these debates.

------
ozy123
Also writing good code (easy to maintain, few bugs, easy to extend) is a craft
not something you do spontaneously when you need to fix a problem. It takes
time to develop and get a good sense for it. This is the key thing I see with
all these bootcamp grads - they know the terms and they know how to throw crud
apps together but they struggle to write clean code that adheres to SOLID that
isn't littered with antipatterns.

~~~
bobbytherobot
The bootcamp grads. They'll use more libraries in a simple take home problem
than we use in a medium size project.

------
SCAQTony
My sorry attempt at wit: Was Vermeer a painter or a photographer who traced _?

Is it not the product and/or result that counts; not how you got there?

_Vermeer traced his subjects using optics; it was not painted freehand:
[http://www.vanityfair.com/culture/2013/11/vermeer-secret-
too...](http://www.vanityfair.com/culture/2013/11/vermeer-secret-tool-mirrors-
lenses)

------
ThomPete
It doesn't matter.

As long as you can do what you want to do with code you are a developer.
Whether looking up code on google or in a reference book.

~~~
exodust
I agree. Especially when by "Google" we basically mean Stack Overflow. I end
up there a lot, and the benefit is often in the comments and different takes
on a problem.

I've learned so many good Jquery tricks from that place, I owe the network and
users a great debt. One can often learn why something is the wrong answer too,
which is valuable information.

With web frontend, often the best solution is a combination of Jquery and good
old vanilla JS, and getting that balance right... come on, let's face it, we
need to help each other get there.

------
georgeecollins
As an old guy who used to program in the 1980's, I can't explain how amazing
stack overflow is. How we lived before it: \- Used tools and systems we knew
and knew worked. \- Found people with experience and made friends with them.
\- Read books. (To be fair, certain bookstores used to be much better.)

------
icedchai
Good developers _are_ good Googlers.

~~~
GrumpyYoungMan
But are good Googlers necessarily good developers? Most likely not.

------
JohnIdol
Google is just an extension of our memory nowadays - it's not worth it
memorising stuff you know you can google, eventually if you google it often
enough it'll stick. And googling will do you no good if you have no idea what
you are doing.

------
unclebucknasty
Programming itself has changed. It used to be more about logic and design.
Now, it's more about gluing together an ever-proliferating bunch of open
source libraries, frameworks, and tools.

It's no wonder devs need to keep Google at the ready.

------
blazespin
protip: flashcards. If you ever find yourself reaching for a detail you think
you should know offhand, make sure you add it and study on a regular basis.
You'll stop feeling like an impostor.

------
argumentum
I suppose at some level how good of a Googler you are affects how well of
whatever you want to be good at .. So you might say being a good Googler is
part of being a good developer.

------
13of40
I think this hits on a tenet of modern development, which is that if you find
yourself actually implementing an algorithm, be it a sort, compression,
crypto, or whatever, you're probably programming badly. That's not to say that
your implementation won't work, but that there's already a library that does
it and a well-worn design pattern that takes advantage of it, and you can find
both of those in a few minutes on google / stackoverflow.

Edit: I am in no way saying you shouldn't try to understand the algorithm.
Coding it yourself is fine exercise for a rainy Sunday morning, but it's
(usually) not the best way to do your day job.

~~~
Xcelerate
I don't know. You'd be amazed how many common algorithms don't have good
libraries for them (particularly for newer languages).

------
skuunk1
Not sure if it makes any difference, but I tend to Google syntax rather than
solutions...

I often know "what" I want to do, I just can't remember the "how".

------
zerr
A question for Win32 API developers - are you able to program [with Win32 API]
without literally copy/pasting the code from MSDN, SO or other sources?

------
logicallee
I propose an extension to DRY (don't repeat yourself) called DRO (don't repeat
others), meaning if anyone has ever done it you shouldn't have to do it again.

Then it's easy to tell whether you're googling or developing: "am I writing
something nobody did EVER /trying to improve the state of the art of xyz?"

If yes, you should understand deeply and "develop", if no you should be
searching and changing variable names.

If you're writing a new framework - then by all means! actually understand the
code.

If not, you shouldn't have to.

~~~
shrugger
I don't agree with this. Developers should try to always understand the code
they are working on. Keep your stack small, understand it as best you can, and
use that knowledge to solve problems. That's what programming _is_.

Smushing a bunch of frameworks together until the code works isn't going to
help anybody improve, and I think it's fundamentally contributive to the
larger issue. If you don't understand the code you're writing or reading, it
follows suit that it probably isn't going to work that well or be easy to
maintain.

~~~
logicallee
If everyone is keeping their stack small, everyone is doing the same thing
over and over and over again. Why shouldn't we copy best practices over
without understanding it?

Should you really spend an hour vertically aligning an element in a compatible
way, when you could copy and paste in 30 seconds and go straight to testing
the code you didn't read, write, or understand - and see that it does exactly
as advertised?

Why shouldn't programmers have a division of labor? Why should everyone
understand everything?

~~~
shrugger
I'm not really prepared to explain why being ignorant about your tools is
toxic to good work, but I'll offer this:

If everyone knew C, would they keep writing the same code over and over?
Obviously not. They'd find new ways to compose what they've already written to
create whatever they want.

It's not a waste of time for more than one person to know how to do something.
People start from the bottom and learn their way up. In your example, what
happens the next time they need to align another element? They either copy and
paste whatever they did before, or google it again, right? If they had taken
five minutes to learn it before that, they'd already know how to do it, and
could just write it.

Redundant knowledge is not a bad thing.

------
anotheryou
Who cares about the label? Just know what you can or can not accomplish and
act accordingly.

------
tk120404
To be a good googler, first they need to be good developer

