Am I really a developer or just a good Googler?
hanselman.com
hanselman.com
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! ;)
Sounds like badly written thing (probably not designed at all). And you do know that there are archaic things like documentation and own notes, right?
Perhaps it's a web frontend in flask, load balanced by haproxy, uses redis heavily for caching, postgres for structured data, and mongo for analytics (yeah yeah, we can gripe about how bad mongo is). These applications run via kubernetes on GCE, the logs of which are forwarded to logstash, stored in elasticsearch (running on the JVM), and viewed via kibana.
> And you do know that there are archaic things like documentation and own notes, right?
Yes, hence his mentioning that he needs to Google to reference them.
I don't have the knowledge, that's why I didn't claim the system was badly written, I only expressed my impression it was. I know, it's a subtle difference easy to be overlooked, especially if somebody is invested in similar architecture.
And it still sounds like a bad idea to tie oneself to specific log transport and log storage, and to a single load balancer at a project time. Use of MongoDB when already using PostgreSQL (or vice versa) doesn't add much soundness, either.
> Use of MongoDB when already using PostgreSQL (or vice versa) doesn't add much soundness, either.
Come on, they're entirely different kinds of databases. PostgreSQL is relational, MongoDB is not. It's very reasonable to use both kinds together in a larger project, each for the type of data that it is best at. I have worked on multiple software projects that combined some variant of SQL (e.g. MySQL, PostgreSQL, MS SQL) with some variant of NoSQL (e.g. MongoDB, DynamoDB, Datastore). Trying to shoehorn everything into a single schema would have been worse.
For a single project (and OP said it was one project) depending on that many specific tools coming from that many fields is a strong sign that the project does too much. Most of the tools mentioned by OP are from the set to be decided in deployment time instead of design time (log transport, storage, and browser, deployment automation, stuff like that), and they should not be dependencies.
I don't know about you, but an interviewing process like that would be a strong signal for me to not work at that place.
Google's interviews are heavy on fundamentals because virtually all of Google's tech stack is home grown.
Other companies imitate this behavior largely because "if google does it it must work great".
Ironically a majority companies actually miss the CS fundamentals that are vitally relevant to them (e.g. relational theory) in favor asking the fundamentals that aren't (e.g. big o notation).
Is normalization taught in a typical CS education outside of a Databases class? Is it a general topic, or is it so specific to the scope of RDBMSs that you don't see it mentioned elsewhere? I don't remember.
One good side effect of working back in the days of spotty (or no) Internet connections was that people were more focused, instead of inventing a new framework every week.
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.
I totally understand and sympathize with the experience, as a DevOps Engineer with alphabet soup on his CV like you probably do. I experience the same.
However, some nuances about your position (and some of the replies about binary search tree questions)... I think good interviewers are going to pick questions based on what you put on your CV. I doubt they're picking from a metaphorical hat questions about redis, flask, Python, java, etc. unless they read them in your resume.
Next it's totally fine to use this broad-based category like approach, so long as the interviewer is asking general questions about the technologies. If I put Python on there, I should expect to be able to answer how in general I'd parse a text file with it, or a basic regex example, or when I last used flask and what it was used for. In my personal experience, only amateurs or people who are socially inexperienced ask questions that require an insane memory or having used the technology the day prior as in your example. When I first started my career as a jr guy, and was interviewing someone, I'd commit these same errors.
I think the right thing to do is trim some of that soup on the CV, and like someone else says be wary of bad interviewers. And know that sometimes they trip you up just to see how you respond.
Sadly, despite this being straightforward and effective it's incredibly rare. Cargo cult "binary tree search style" problems and technology stack trivia questions are more normal.
The level at which dogma and fashion drive this industry is almost embarrassing.
It's true that the interviews can be pretty retarded. Most of our roles don't require knowing half the complex stuff they ask to weed people out. If you're just out of college that stuff is reasonable to ask [1], but otherwise as a hiring manager you should ask what you're looking for. For example, if I'm looking for someone who a) doesn't lie about their experience b) has experience in some of the technologies I need a project completed with or ongoing support for on day 1 c) has the ability to learn technologies I'll need help with on day 180, then I'll ask about a project that was listed on the CV, stopping to ask for more detail about how something works. Then I might present a scenario or problem that's theoretical (or really happened) and have the candidate walk through it.
That was when I was a hiring manager. I didn't weed out good people by asking them dumb questions about how many marbles would fit from here to the moon, or about the different types of O notation. Of course, this is specific to the roles I was hiring for (DevOps).
When I was on the flipside, I was weeded out by overachieving mid 20-somethings who really relished putting me on the hot seat. It felt not dissimilar to a bad date sometimes.
I consider it a 'competitive advantage' that the latter style of interviewing is so commonplace, because it's so off-base. It doesn't make me as frustrated anymore, probably because I'm old and cynical, and a lot more independent now. My thinking now is 'how can I use this to get a leg up on the competition' whether that means learning some cursory rote algorithms stuff if I'm interviewing, or just knowing how to ask the RIGHT questions to get the good candidates (something I feel pretty comfortable about) if I'm the interviewer.
[1] I think it's reasonable to ask questions of a college grad that he would have learned in a hard-core comp-sci class for the same reason I'd ask in-depth questions about the projects in the last role: because it's the freshest thing in their minds and they 'should' probably it. Please don't bother us old guys with comp-sci fundamentals. Unix and TCP/IP fundamentals, on the other hand ...
(Edit: turns out using an asterisk in here causes some weird markup behavior)
No shit, I have been programming C++ for 20 years. Recently someone stuck in a room with a laptop, not connected to internet, and asked me to format C strings to use in a printf (for a C++ job), something I haven't done in 20 years. Maybe it's my fault for abstracting all of the ugliness away with the use of libraries and C++ functions. I could have told them when to use such silliness. Which is when you need to have something that is really performant, that gets called a LOT. After writing game engines, most other performance requirements are trivial.
* The Sysadmins knew Linux, bash, logstash, kuberneties
* The programmers knew python, java, regular expressions, flask,
* The DBAs knew mongodb, postgresql
* The network guys knew haproxy, firewalls, switches, etc
I wish there was no in-person technical challenges (I'm sure there are companies out there like this), have me do a small project then come in and speak about it as part of my interview.
I get that the types of projects they give out may often be google-able, BUT if it's similar to the types of challenges I will be seeing if hired then it shouldn't matter! Google is just as much of a tool as Java or Python.
As a suggestion, maybe try limiting yourself to local documentation? It can be useful for times when you do plan to work offline (flights, no wifi), and are often more consistent and faster to use when you're familiar with the format (eg. man pages).
If you find it limiting in your day to day work, try keeping a list of the common sites you frequent (language references, common examples / snippets) and build a personal repository of reference material to replace your internet searches over time. I have a repo with top level directories for each language, containing an assortment of text files (I use .md though I really only read as plaintext with vim), code examples and scripts (build script examples, library install scripts, etc..).
I think of it like constantly preparing for an open book test. If I understand all my resources (because I wrote them), and can quickly find what I'm looking for, then its legitimately all preparation. Using google always seemed like trying to learn the topic while applying it for the first time in the test. I'm never as confident in the result, even if I do think I understand everything in the end.
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?"
Yes, exactly. I said this a few days ago in another similar discussion: Google is really good at "meta-guidance." If I search for something and don't get any results, it means I'm either asking the question incorrectly, or I'm trying to solve the wrong problem.
Which brings me to the subject at hand: if someone is really good at Google'ing answers on a topic, then they're most likely good at that topic. I believe it was Einstein who said (I may be misattributing the quote here): never memorize something you can look up easily.
So much this. I noticed this myself. When I google for information in the domains I know, I can be extremely efficient, because I know what to ask for and how to evaluate both results and the metadata - i.e. how much results I got, how good/crappy they are, etc. But when I try to search for information on topics I have little to no experience in, I struggle to find what I'm looking for. And more often than not, I'm left with this feeling of incompleteness, like the information I needed was still out there, if I could only phrase my query correctly...
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.
When i am learning a new language/library, rather than reading through the documentation trying to find something to solve my problem (as i dont know what to look for), i simply google it and get to the solution faster. I retain knowledge much better if its relevant to my current problem. Often i will then be able to place a name/concept to my problem and then be able to find it much easier in the documentation.
1. Google: twitch bot and look for official docs, github, and stackoverflow.
2. Google: Twich bot Golang , or twich bot nodejs, or twitch bot c#. Sometimes i look up samples in several languages to get a better general idea of how it works.
3. Based on what we learned in last search, filter our search for specifics such as twitch IRC, twich API etc.
It really is a skill, built up over time.
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.
Everyone should have a healthy way of dealing with feeling inadequate, besides whining. (e.g. learning things)
So, how do we find out which people are whining and which aren't? How do we encourage people to just learn and self-improve rather than sink to escapism?
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.
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.
This is how I've coped with possibly-impostor-syndrome-or-actually-impostor-idk-lol anyway. YMMV.
And, of course, don't ever let imposter feelings getting in the way of diving headlong and trying things anyway, even if they seem impossibly difficult from the outset. It's mostly mental barriers; I've tackled dozens of tasks that were imposingly difficult from the outset. There hasn't been a single one yet that I didn't end up making appreciable headway on.
What I am actually worried about are arrogant developers. They tend to cause the most damage, write the most "clever" code, have the worst communications skills, and will be the first to leave the team in the lurch and panic when shit hits the fan.
There may of course be arrogant developers who can walk the talk, but I'm taking from personal experience.
The ones with "Imposter Syndrome" - i.e. those who have a fear they're not quite good enough for the job - are more likely, again based on personal experience, to double check everything, to ask questions (from the rest of the team or Google), to write tests and test manually. They write "dumb" code that works and is well-commented and is as simple as possible. They have a desire to learn.
I'm not sure what you mean by "has gone too far". It's an effect; it's not like people are aiming to feel incompetent. You could just as well say that "This depression thing has gone too far" -- OK, but so? That's not a solution? Sweeping it under the rug doesn't cure anyone of it.
The solution to imposter syndrome is to make everyone aware of it, so that people who could otherwise grow into their role properly don't look around at the performance of their more experienced peers and simply give up. At my work we assign all new employees a more experienced mentor that they can discuss these issues in confidence with. It really helps.
I'm glad that your real opinion of the issue is the opposite, so it sounds like we are in agreement, but you didn't come off that way in your first comment, and I was just pointing that out.
Yahoo and Intel were having troubles for a long long time. But other than those were there any other big layoffs recently?
Qualcomm laid off over one thousand employees within the past year: http://www.sandiegouniontribune.com/news/2015/sep/17/Qualcom...
Here's a large list: http://www.edd.ca.gov/jobs_and_training/warn/WARN-Report-for...
And here's an article with more: http://www.businessinsider.com/its-been-a-bad-month-for-tech...
There was never a day when that wasn't true. Not within a couple lifetimes, at least. Might be useful to gather data from other areas. Software development suffers from a severe case of toxic neophilia therefore the solution to that problem found by philosophers 2000 years ago must be wrong solely because its old. The problem is human wisdom is deep and can't be reinvented every other year solely to avoid a disease, there's just too much. So we must operate without wisdom, or at least not be seen in public relying on wisdom.
Maybe 25, 30 years ago I had the privilege of working for a guy with a philosophy degree (at a workplace having nothing to do with software dev or philosophy...) and we had a long and interesting break time conversation one day on the topic of the subjective difference between reading about philosophy (or presumably googling it) vs the experience of actually doing philosophy by writing papers about new thoughts (presumably breaking new ground writing code). Some mixture of the way he dealt with it, or the way philosophers figured out how to deal with it 2000 years ago, was to not worry. The two activities feel subjectively different, because they are different, and as long as you get that "A" or get that paycheck it doesn't really matter. The same pride of a job well done to the best known abilities applies no matter if you're climbing via a staircase or a ramp, and sweating over them being "different" is a false enlightenment, its the wrong thing to sweat over. There is no solution because there is nothing to see there. In modern terms I guess it could be a called a toxic meme virus, it just eats up brain cycles producing nothing of value. Its a socially acceptable form of a mild anxiety disease.
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.
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.
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.
> 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.
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
And for Swift and iOS where I want to go deeper, I'm creating my own Cookbook, and perhaps my own search engine:
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!"
Was expecting some blog post about someone concerned he was just 'going through the motions' working at Google; not 'really developing anything'.. ha.
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?
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...
I remember a fellow developer used to curse in his comments. Expletives about what he didn't like etc. Funny the first time I saw it, then got annoying.
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!!"
Its also for defense programming or documentation. "Why did you do that to that matrix to stabilize it?" "Well that is right out of Prof Higham's paper about nearest correlation matrices see this link in the comments, its not like I'm just making that stuff up as I go along".
Also comes in handy for legal review. "Wait, thanks for the flattery but you can't copyright that, that algo is copied right out of Knuth, it was invented 50 years ago."
I probably most often use it when I've hacked around a known bug in someone elses framework - linking to the respective ticket, that way if someone comes along later and the ticket is resolved, they can remove/adjust whatever I've done.
Links are everywhere else, why not in our comments?
If the code is self explanatory or not particularly interesting, then there's no link. If its worthy of a comment, its usually worthy of a SO link.
In that circumstance (which is what Stack Overflow is mainly used for) links would not be necessary in your comments.
Xe probably was.
* https://meta.stackexchange.com/questions/272956/
* https://meta.stackexchange.com/questions/271080/
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".
I'm the early parts of any project I start with research, which means Google and stack overflow. It does little harm for others to use the same approach.
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.
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."
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.
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.
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.
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.
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.
"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.
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.
Google is an excellent tool. Programming, which can use google heavily, is still a skill.
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.
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.
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.
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.
I remember when I couldn't Google. Those were tough days.
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.
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...
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.
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.
It's no wonder devs need to keep Google at the ready.
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.
I often know "what" I want to do, I just can't remember the "how".
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.
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.
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?
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.
I'm surprised to see this question being asked non-ironically. I can see myself using a library function without fully understanding it, but copy-and-paste? This may be acceptable in something like CSS (since the comment mentions 'vertically aligning elements), but for solving any non-trivial problem, this is probably not a good way to go.