Am I really a developer or just a good Googler?(hanselman.com)
hanselman.com
Am I really a developer or just a good Googler?
http://www.hanselman.com/blog/AmIReallyADeveloperOrJustAGoodGoogler.aspx
160 comments
"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! ;)"
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.
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.
IMO good interviewers just ask for you to perform a task that's a close analog to what you will be doing every day. I've had this happen once.
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.
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.
I have a refrain I like to repeat to myself sometimes, which goes roughly like: in the land of the blind, the one-eyed man is king.
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)
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)
>Please don't bother us old guys with comp-sci fundamentals
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.
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.
In real life, without an internet connection (say 1980) you would have had books. Life is an open book test, as the saying goes.
Books and local documentation.
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.
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.
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.
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.
Possible for Encyclopedia, impossible for technology related to stay relevant in the next few years.
One of the things is that before everybody became a "full-stack devops" you didn't have to be an expert at all those technologies.
* 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 paused for a second when I realized how many of those I understand enough to talk to, but not enough to do anything useful without examples to use as a starting point.
Maybe that's a good indicator of the point we should divide responsibilities at.
(now if only we had headcount to cover distinct roles like that... ha!)
> as a reward you the interviewer get to pick anything you want from that huge list and try to trip me up with it! ;)
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.
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.
Well, it is not so much that any single interviewing "process" would define itself that way. It's more the simple fact that so much of interviewing success or failure depends not on how much you understand, or the breadth of things you've worked with, but rather whether you can run the gauntlet of questions and answers that interviewers use to prove to themselves that you know what you're talking about. Any scalable internet service is going to involve a laundry-list of technologies similar to the list I gave above.
This kind of thing may be partly why interviews are heavy on CS fundamentals -- most good developers agree that they are important in a way that framework quirks are not, even if we don't remember all the details throughout our daily lives. Personally I feel much more at ease disqualifying someone in an interview because they e.g. don't know what a binary search tree is for than if they try to use a Java for-each loop over an Iterator when that only works over an Iterable.
>This kind of thing may be partly why interviews are heavy on CS fundamentals -- most good developers agree that they are important in a way that framework quirks are not
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).
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).
When I worked on databases at Microsoft we were totally trying to find people with good cs fundamentals, and who could program. That was what we were looking for (like totally, dude :-)). At google we looked for those things. And in my new job, we also look for those things. Sure, now we ask questions about server and distributed programming, but good cs fundamentals are fundamental still.
You mean relational as in RDBMS, right? I'm curious, what parts of relational DBs do you think are under-emphasized in a typical CS education that you make sure to ask interview questions about? Things like what does a LEFT JOIN do, etc.?
Normalization is under-emphasized in interviews.
One interview problem I've had before that was clearly intended to measure good database design sense and understanding of normalization was "How would you design the database for a restaurant reservation system?" There are a bunch of restaurants, each of which has a bunch of different tables, each of which can be reserved for chunks of time on various days. I won't go into the details, but you can see how a good answer is maximally normalized.
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.
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.
CS fundamentals is a filter for "recent graduate". It's a way to sneak ageism past HR, that's all.
I strongly disagree. I was definitely not a recent graduate. They sent me a detailed study guide before the interview with all the basic CS fundamentals they might reasonably ask you about. I think it's more of a filter at determining people who want the job and are willing to study for it than testing for recent graduation. It didn't take me that much studying for all of the CS-y stuff to come back, but the programming skill I've accumulated over a career is harder to fake. A lot of fresh grads aren't that great at coding yet, and it shows in interviews.
So they should test, or really talk about that. It's more about your approach to solving a problem then it is to the format of the language.
Someone recently talked to me about how to handle a multithreaded issue. I showed them how to avoid the problem completely, but they didn't want that. They wanted to know what they figured out last week.
I'm in the same boat and it is hair-pullingly mad. On top of that, having someone stare at me and my work while I'm programming adds a ton of anxiety (and thus poorer performance).
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.
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.
> there is no freaking way I can remember all the details of linux, python, bash, ...
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.
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.
> [...] 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.
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?
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?
Why does that sound like a badly written thing, you having no knowledge of the specific domain he's referencing?
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.
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.
> Why does that sound like a badly written thing, you having no knowledge of the specific domain he's referencing?
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.
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.
Why would you admit to not having knowledge of the domain in question, and then, right in the same post, continue making speculative disparaging comments about the technology stack in use, which you self-admittedly know little about? Knowing when your opinion is valuable to others, and withholding it when it is not, is a useful skill.
> 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.
> 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.
A nearly perfect description, from someone who has obviously built similar systems :).
You think that list of technologies is unusual? It's not. And while I keep plenty of my own notes, I am not sure why you think trying to replicate the online documentation that can be quickly found through search tools would be a better strategy.
I'm aware it is not unusual. It is not unusual for software to be badly
written, too (being wide-spread is no sign of being a proper way of doing
things).
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.
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.
The concept of a "single project" leaves a lot of wiggle room. In this case the "project" I refer to was a mobile application with all the front and back-end pieces that implies. You could carve the "project" up into sub-projects and view it however you wish, but since I was responsible for much of the back end pieces I experienced it the way I described.
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?"
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?"
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.
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.
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.
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.
If you know what to google then you probably know what to look for in the documentation. Its often just faster to google though. I think google is good for beginners that dont know what they dont know - or for a quick reference 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.
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.
>>Been talking about this a lot with friends/peers recently. Personally I think half the skill is knowing what to Google.
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.
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.
> 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.
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...
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...
Try watching someone who's just learning how to program, and you'll see that their Google searches are much worse–they'll include irrelevant words, exclude key phrases, click on lower quality search results, and so on.
It really is a skill, built up over time.
It really is a skill, built up over time.
For me its kind of a step by step. Lets say we want to build a Twitch bot.
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.
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.
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.
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.
> 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'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 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.
[deleted]
I wasn't trying to "pigeonhole" you. I was merely responding to your comments as they scanned to me, which is that they came off as dismissive of imposter syndrome.
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.
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.
[deleted]
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)
Everyone should have a healthy way of dealing with feeling inadequate, besides whining. (e.g. learning things)
It's even a meta-issue!
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?
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?
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.
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.
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.
> 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.
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.
I find "hang around people who are more awesome than you and absorb as much as you can" to be a tangible proxy for "learn more"
That addresses the learning part but not the imposter syndrome part. I suspect it would put you at greater risk for imposter syndrome if anything. It probably even puts you at greater risk for being an actual imposter.
No, I mean you do it in reverse: if you find yourself surrounded by awesome people and feel like an impostor, ignore that and focus on learning. You may or may not be an impostor: but does it really matter when you can learn?
This is how I've coped with possibly-impostor-syndrome-or-actually-impostor-idk-lol anyway. YMMV.
This is how I've coped with possibly-impostor-syndrome-or-actually-impostor-idk-lol anyway. YMMV.
I'm surrounded by awesome coders at work and have frequently felt like an imposter. The best way I've found to address it is to tackle it head-on: Just get it out in the open and talk about it. It turns out that most of my outwardly-amazing coworkers also feel the same way occasionally.
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.
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.
I have no idea if "terrible developers whining on Medium" is a thing.
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.
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.
"Nowadays, there seems to be"
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.
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.
There's a lot at play here. Tech startups aren't hiring as fast as they used to, VC money is starting to dry up, large tech corporations seem to be having bigger and bigger layoffs, advanced fields like AR and VR are pretty stagnant, if you frequent HN you'll likely be told the tech you're using is dated and wrong on a daily basis. How could anyone not feel like an imposter?
> large tech corporations seem to be having bigger and bigger layoffs
Yahoo and Intel were having troubles for a long long time. But other than those were there any other big layoffs recently?
Yahoo and Intel were having troubles for a long long time. But other than those were there any other big layoffs recently?
Microsoft laid off 7,800 employees within the past year: http://fortune.com/2015/07/08/microsoft-layoffs/
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...
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...
At least here in Portland the most recent significant one was Jive.
Back when I was still living in DC, the big one was Living Social, which is still ongoing. It's sad, because DC doesn't have a huge startup scene, and its biggest one is in the discount daily deals sector and also hemorrhaging.
"Tech startups aren't hiring as fast as they used to" - I think they are hiring smarter than they used to, but I don't think some of it is entirely "ethical", most of what is done today is really through competitive programming (https://en.wikipedia.org/wiki/Competitive_programming) or cheaper competitions (Kaggle), CTF, etc. Many of which were not really going on when alot of us decided to take up tech, it was a clearer path even if you were self-taught. Whatever form it comes in, it feels like AI will indeed weed alot of us out, which is a shame because it means no more "ideas" or R&D and more an "end result/goal and how fast can you get there" game (ie optimization).
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.
Yep, documentation and source when googling begins to fail.
And occasionally you'll happen to come across a bug in a library you thought was beyond your understanding/comprehension.
I actually enjoy finding/fixing bugs in OSS. I strive to be more of an engineer than a developer. Learning how large projects are put together and maintained help make me a better engineer.
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.
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.
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.
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.
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.
Usually when I search Google for JavaScript language or DOM API, I'll start my search with "mdn" to get the relevant Mozilla documentation.
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.
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.
> 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.
> 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.
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.
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?!"
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
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
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:
http://www.h4labs.com/dev/ios/swift_cookbook.html
That ComputerLanguages repo, wow! This is really awesome! And far, far superior to my own store/collection of helpful links by language by far :(. I may just stop altogether collecting helpful links on languages I may never, ever use, when there're such better lists and guides (like yours) out there that I can search if I ever need to. There are far more programming languages/ideas than there is time.
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!"
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!"
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.
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.
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?
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?
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...
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...
Everyone at the workplaces I've been in uses SO and Google frequently. The difference comes with how resourcefully they're used - more senior devs tend to be more efficient in seeking out accurate answers, while juniors may find misleading info, info irrelevant to the version or environment they're using, info that they have trouble adapting to their specific needs; or may have more trouble finding the best search terms to use; or may simply take longer to scan through results.
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.
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!!"
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!!"
Why not? I've been known to do this as well. I'd rather put a quick link to a relevant source of information explaining why I did something the way I did than spend 2-3 lines trying to explain it.
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?
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?
Different workplace cultures. Just like putting in academic citations on a clickbait site would be inappropriate vs not properly citing academic papers at uni is technically plagiarism.
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."
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 often put links in the code as well and not because I'm a clown but because those discussions led to that code being there and those discussions explain the problem and solution in much detail usually. Nothing wrong with links in comments. I also place links to bug tickets waiting to be solved so I can track the progress without having to google for that bug each time I revise the code. I can go straight and see if it was fixed or not.
ASP.NET scaffolds in Visual Studio contain commented links to MSDN articles and documentation, and the links are clickable. So it has to be a fairly common practice. ;)
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."
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.
In that circumstance (which is what Stack Overflow is mainly used for) links would not be necessary in your comments.
> Licensing issues? [...] I thought we were talking about Stack Overflow
Xe probably was.
* https://meta.stackexchange.com/questions/272956/
* https://meta.stackexchange.com/questions/271080/
* https://meta.stackexchange.com/questions/25956/
* https://news.ycombinator.com/item?id=10905009
Xe probably was.
* https://meta.stackexchange.com/questions/272956/
* https://meta.stackexchange.com/questions/271080/
* https://meta.stackexchange.com/questions/25956/
* https://news.ycombinator.com/item?id=10905009
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".
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 usually put links in comments when I copy out a piece of code (e.g. an utility function) wholesale, with maybe minor tweaks. It happens rarely to me, but when it does, it feels unfair not to credit the original author.
Context in code is everything, and links provide the context far better than comments can most of the time. I find it surprising that you're so surprised at the idea of links in code!
Because it's only one tiny piece of any given function usually that we need help for from SO. That's my experience anyway. Usually it's how to do something, not copying and pasting huge chunks of code. And often I would change and modify what I learn from SO anyway,so it makes little sense to include links then.
Well I'm certainly not littering my code with SO links. But when there's some particularly hairy problem that SO provided a solution, or an odd looking piece of code that I got from SO, I'll throw the link in.
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.
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.
I usually add links too- it feels dishonest otherwise.
My code is littered with links to SO, GitHub, and tutorial blogs. I have no shame. I put getting a job done correctly and fast over what other people think of me. Use as many ideas from other people, but try to contribute your own.
Yikes, another one. I dunno... maybe I'm behind the times. I don't like web links in code comments myself unless it's the comment above a plugin that you wouldn't touch anyway.
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.
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.
I'm a 20 year veteran of various strata of technology organizations, and I know that I cannot hold everything I've learned in my head. If I cannot, then how should I expect anyone else to be able to do so?
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.
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.
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.
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.
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.
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.
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."
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 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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
"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.
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.
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.
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?
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.
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... :)
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.
Google is an excellent tool. Programming, which can use google heavily, is still a skill.
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.
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.
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.
> 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.
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.
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.
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.
Gosh, this is a pretty old post. Maybe add (2013) to the title. Source: I wrote the post.
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.
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.
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.
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.
I remember when I couldn't Google. Those were tough days.
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.
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.
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.
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.
The bootcamp grads. They'll use more libraries in a simple take home problem than we use in a medium size project.
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...
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...
[deleted]
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.
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 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.
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.
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.)
Good developers are good Googlers.
But are good Googlers necessarily good developers? Most likely not.
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.
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.
It's no wonder devs need to keep Google at the ready.
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.
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.
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.
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 don't know. You'd be amazed how many common algorithms don't have good libraries for them (particularly for newer languages).
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".
I often know "what" I want to do, I just can't remember the "how".
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?
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.
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.
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.
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.
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?
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?
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.
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.
Because debugging?
> Why shouldn't we copy best practices over without understanding it?
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.
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.
I have to disagree, unless of course you're okay with being a "developer" and not a software engineer. An engineer needs to know what goes on under the hood. I have seen enough harm done by software engineers who use tools and libraries knowing only their purpose and not their behavior.
Unfortunately someone already invented the NIH anti-pattern.
Who cares about the label? Just know what you can or can not accomplish and act accordingly.
To be a good googler, first they need to be good developer
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! ;)