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?!"
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!"
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.
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.
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.
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.
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.
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.
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?
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.
> 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 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.
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.
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.
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)
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.
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.
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 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.
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.
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.
> 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 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.
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?
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).
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.
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.
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.
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.
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.
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.
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."
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.
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.
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?
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.
> 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.
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.
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.
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.
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.
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... :)
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.
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.
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?"
>>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.
> 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...
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 seen this while conducting phone screens. Obviously, it didn't work out for them. But I don't blame them for trying; they were already completely flubbing the interview anyway, so why not go for a hail mary?
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.
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.
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.
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.
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...
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.
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.
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!!"
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."
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?
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 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.
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.
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.
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".
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.
160 comments
[ 2.8 ms ] story [ 239 ms ] thread20 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
Someone who works at Google is called a "Googler". When you are used to constantly hearing a word used with meaning A, and almost never meaning B, it can be quite confusing when you hear it in a context where someone uses meaning B, especially when meaning A sort of fits. So you can imagine my confusion when I parsed the entire article as "Why would being a good software engineer and [working for Google] be mutually exclusive? They usually go hand-in-hand!"
Was expecting some blog post about someone concerned he was just 'going through the motions' working at Google; not 'really developing anything'.. ha.
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.
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.
Then it's easy to tell whether you're googling or developing: "am I writing something nobody did EVER /trying to improve the state of the art of xyz?"
If yes, you should understand deeply and "develop", if no you should be searching and changing variable names.
If you're writing a new framework - then by all means! actually understand the code.
If not, you shouldn't have to.
Smushing a bunch of frameworks together until the code works isn't going to help anybody improve, and I think it's fundamentally contributive to the larger issue. If you don't understand the code you're writing or reading, it follows suit that it probably isn't going to work that well or be easy to maintain.
Should you really spend an hour vertically aligning an element in a compatible way, when you could copy and paste in 30 seconds and go straight to testing the code you didn't read, write, or understand - and see that it does exactly as advertised?
Why shouldn't programmers have a division of labor? Why should everyone understand everything?
If everyone knew C, would they keep writing the same code over and over? Obviously not. They'd find new ways to compose what they've already written to create whatever they want.
It's not a waste of time for more than one person to know how to do something. People start from the bottom and learn their way up. In your example, what happens the next time they need to align another element? They either copy and paste whatever they did before, or google it again, right? If they had taken five minutes to learn it before that, they'd already know how to do it, and could just write it.
Redundant knowledge is not a bad thing.
I'm surprised to see this question being asked non-ironically. I can see myself using a library function without fully understanding it, but copy-and-paste? This may be acceptable in something like CSS (since the comment mentions 'vertically aligning elements), but for solving any non-trivial problem, this is probably not a good way to go.
I sort of understand it from the students' perspectives, because they have a professor to compare themselves to and aspire to, I think in that scenario it spurs self-improvement but in the workplace it seems like it would only be counterproductive at best to compare yourself to other coworkers or even other people in the field.
I remember when I first started, I never thought "Shit, will I ever be as good at Scheme as Sussman?" I just worked the exercises and kept moving forward.
Nowadays, there seems to be a real strong pressure to be aware of all the new technologies, newest libraries, and all this material that nobody could ever possibly have time to completely understand, and it drives people crazy, I think.
Everyone should have a healthy way of dealing with feeling inadequate, besides whining. (e.g. learning things)
So, how do we find out which people are whining and which aren't? How do we encourage people to just learn and self-improve rather than sink to escapism?
The solution for dealing with actual imposters is to fire them. If, somehow, they manage to use "imposter syndrome" as a deflection (I haven't seen this play in the wild and I'm not convinced it's prevalent or even could be made to work), then gather evidence that they aren't pulling their weight and proceed to use it. If that doesn't work, it's not because of some stupid blog post, it's because there's stronger politics at play. Abort/retry/ignore as warranted.
That's a good idea in general, but it doesn't address the specific problem of imposter syndrome.
> This is something imposters don't do.
If you believe that this is true then it addresses the problem of imposter syndrome. The danger is that you might then have to deal with cognitive dissonance if you were confronted with someone who ramped so slowly or started from so far behind that they couldn't be expected to make a net positive contribution to the team within a reasonable timeframe. It's entirely possible to try and fail, and while we should all admire the "try," that doesn't mean you or your employer should be on the hook for funding it.
This is how I've coped with possibly-impostor-syndrome-or-actually-impostor-idk-lol anyway. YMMV.
And, of course, don't ever let imposter feelings getting in the way of diving headlong and trying things anyway, even if they seem impossibly difficult from the outset. It's mostly mental barriers; I've tackled dozens of tasks that were imposingly difficult from the outset. There hasn't been a single one yet that I didn't end up making appreciable headway on.
What I am actually worried about are arrogant developers. They tend to cause the most damage, write the most "clever" code, have the worst communications skills, and will be the first to leave the team in the lurch and panic when shit hits the fan.
There may of course be arrogant developers who can walk the talk, but I'm taking from personal experience.
The ones with "Imposter Syndrome" - i.e. those who have a fear they're not quite good enough for the job - are more likely, again based on personal experience, to double check everything, to ask questions (from the rest of the team or Google), to write tests and test manually. They write "dumb" code that works and is well-commented and is as simple as possible. They have a desire to learn.
I'm not sure what you mean by "has gone too far". It's an effect; it's not like people are aiming to feel incompetent. You could just as well say that "This depression thing has gone too far" -- OK, but so? That's not a solution? Sweeping it under the rug doesn't cure anyone of it.
The solution to imposter syndrome is to make everyone aware of it, so that people who could otherwise grow into their role properly don't look around at the performance of their more experienced peers and simply give up. At my work we assign all new employees a more experienced mentor that they can discuss these issues in confidence with. It really helps.
I'm glad that your real opinion of the issue is the opposite, so it sounds like we are in agreement, but you didn't come off that way in your first comment, and I was just pointing that out.
Yahoo and Intel were having troubles for a long long time. But other than those were there any other big layoffs recently?
Qualcomm laid off over one thousand employees within the past year: http://www.sandiegouniontribune.com/news/2015/sep/17/Qualcom...
Here's a large list: http://www.edd.ca.gov/jobs_and_training/warn/WARN-Report-for...
And here's an article with more: http://www.businessinsider.com/its-been-a-bad-month-for-tech...
There was never a day when that wasn't true. Not within a couple lifetimes, at least. Might be useful to gather data from other areas. Software development suffers from a severe case of toxic neophilia therefore the solution to that problem found by philosophers 2000 years ago must be wrong solely because its old. The problem is human wisdom is deep and can't be reinvented every other year solely to avoid a disease, there's just too much. So we must operate without wisdom, or at least not be seen in public relying on wisdom.
Maybe 25, 30 years ago I had the privilege of working for a guy with a philosophy degree (at a workplace having nothing to do with software dev or philosophy...) and we had a long and interesting break time conversation one day on the topic of the subjective difference between reading about philosophy (or presumably googling it) vs the experience of actually doing philosophy by writing papers about new thoughts (presumably breaking new ground writing code). Some mixture of the way he dealt with it, or the way philosophers figured out how to deal with it 2000 years ago, was to not worry. The two activities feel subjectively different, because they are different, and as long as you get that "A" or get that paycheck it doesn't really matter. The same pride of a job well done to the best known abilities applies no matter if you're climbing via a staircase or a ramp, and sweating over them being "different" is a false enlightenment, its the wrong thing to sweat over. There is no solution because there is nothing to see there. In modern terms I guess it could be a called a toxic meme virus, it just eats up brain cycles producing nothing of value. Its a socially acceptable form of a mild anxiety disease.
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.
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.
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.
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."
As long as you can do what you want to do with code you are a developer. Whether looking up code on google or in a reference book.
I've learned so many good Jquery tricks from that place, I owe the network and users a great debt. One can often learn why something is the wrong answer too, which is valuable information.
With web frontend, often the best solution is a combination of Jquery and good old vanilla JS, and getting that balance right... come on, let's face it, we need to help each other get there.
At the end of the day no one cares if you're a good developer. They care that the service looks good and works well. Googling is how you build a better service ergo do it and don't worry about it.
> At the end of the day no one cares if you're a good developer. They care that the service looks good and works well.
Those decisions lead over time to an architecture that can good or bad, and assuming your software has patches or improvements over time, that's important.
Context: I've worked with too many startups with non-dry untested code that are now getting past "looks good and works well" to needs to drastically expand feature set or change underlying features.
I remember when I couldn't Google. Those were tough days.
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.
It's been a little bizarre to see how this focus has changed my development. I sit in on team discussions about coding style and design patterns and find it quite uninteresting. I code as much as the next person on the team, so I'm not aspiring to be an ivory tower architect or anything, but I find weighing in on engineering decisions adds far greater value.
"The creative application of scientific principles to design or develop structures, machines, apparatus, or manufacturing processes, or works utilizing them singly or in combination; or to construct or operate the same with full cognizance of their design; or to forecast their behavior under specific operating conditions; all as respects an intended function, economics of operation or safety to life and property."
In my ideal world, every developer would do what you're describing as engineering, and the software engineers would be those who far exceed those requirements.
My mum's husband is a painter and decorator. Every house is different, but he has built up a set of skills over the years he's been active that allow him to broadly apply his knowledge to understand how to solve a problem.
Similarly, I can't always solve the problem, but I do know where to start asking questions, and I do know how to follow those up efficiently. Is this when I Google for the docs, for answers to a problem, for a place to find help? And then after that, it's about knowing the next steps, knowing which part is likely to be the next relevant thing to Google/research.
Do I get stuff done? Sure. Do I remember how to do it next time? Sometimes. But sometimes it's just enough to know how to start solving the next problem. I think we just feel a bit fraudulent because Google is easier. I'd be surprised if anyone ever said "Am I good at xxxxx or just good at going to the library, choosing the right books and reading the required parts?"
Yes, exactly. I said this a few days ago in another similar discussion: Google is really good at "meta-guidance." If I search for something and don't get any results, it means I'm either asking the question incorrectly, or I'm trying to solve the wrong problem.
Which brings me to the subject at hand: if someone is really good at Google'ing answers on a topic, then they're most likely good at that topic. I believe it was Einstein who said (I may be misattributing the quote here): never memorize something you can look up easily.
So much this. I noticed this myself. When I google for information in the domains I know, I can be extremely efficient, because I know what to ask for and how to evaluate both results and the metadata - i.e. how much results I got, how good/crappy they are, etc. But when I try to search for information on topics I have little to no experience in, I struggle to find what I'm looking for. And more often than not, I'm left with this feeling of incompleteness, like the information I needed was still out there, if I could only phrase my query correctly...
You can pick up so much about a new tool so quickly simply by applying an existing broad knowledge base of programming information to a few examples.
When i am learning a new language/library, rather than reading through the documentation trying to find something to solve my problem (as i dont know what to look for), i simply google it and get to the solution faster. I retain knowledge much better if its relevant to my current problem. Often i will then be able to place a name/concept to my problem and then be able to find it much easier in the documentation.
1. Google: twitch bot and look for official docs, github, and stackoverflow.
2. Google: Twich bot Golang , or twich bot nodejs, or twitch bot c#. Sometimes i look up samples in several languages to get a better general idea of how it works.
3. Based on what we learned in last search, filter our search for specifics such as twitch IRC, twich API etc.
It really is a skill, built up over time.
I've always been a solo / start-up developer (for now), and sometimes I sit back and think about how my (often zealous) use of SO and Google would bode with a team of developers in an office.
Would I be considered (to use a loaded term) an impostor if I was seen to be using SO a lot, even if I produced good results?
-- I think that last point — of good results — is key, but I am curious to how co-workers perceive this kind of productivity...
I remember a fellow developer used to curse in his comments. Expletives about what he didn't like etc. Funny the first time I saw it, then got annoying.
But adding those links to code I have never ever heard of! Not judging, but if I were working in your team I'd be like "ok, what clown is putting stack overflow links in the code!!"
Its also for defense programming or documentation. "Why did you do that to that matrix to stabilize it?" "Well that is right out of Prof Higham's paper about nearest correlation matrices see this link in the comments, its not like I'm just making that stuff up as I go along".
Also comes in handy for legal review. "Wait, thanks for the flattery but you can't copyright that, that algo is copied right out of Knuth, it was invented 50 years ago."
I probably most often use it when I've hacked around a known bug in someone elses framework - linking to the respective ticket, that way if someone comes along later and the ticket is resolved, they can remove/adjust whatever I've done.
Links are everywhere else, why not in our comments?
If the code is self explanatory or not particularly interesting, then there's no link. If its worthy of a comment, its usually worthy of a SO link.
In that circumstance (which is what Stack Overflow is mainly used for) links would not be necessary in your comments.
Xe probably was.
* https://meta.stackexchange.com/questions/272956/
* https://meta.stackexchange.com/questions/271080/
* https://meta.stackexchange.com/questions/25956/
* https://news.ycombinator.com/item?id=10905009
If someone wants attribution for code, it better be something self-contained with its own home on github or at least a blog somewhere with a unique name: "my awesome plugin v1.0".
I'm the early parts of any project I start with research, which means Google and stack overflow. It does little harm for others to use the same approach.