What kind of things you are talking about? I only use StackOverflow
undeliberately, when it pops out for a (mostly trivial) ramp-up code snippet
I could find in documentation, but I'm too lazy to dig in it.
Say for example things you have coded before but can't remember the syntax off hand. Might quickly look it up on StackOverflow. It's like having a pair coder with you.
That's what I don't get either. StackOverflow is definitely a good website, but why limit yourself to one site when you can just google your problem and likely find more answers?
And even if they are,I find SO answers will usually encorage you to read it with links directly to the relevant parts and also include additonal resources and information you wouldn't find in any manual.
That's why I don't randomly paste in code from SO. I do use it readily as a resource, but it's not my first port of call, and I always make sure I understand any code that I take from there. It's extremely useful for exposing you to points of view and ideas that you may not have considered, and I certainly wouldn't recommend that any developer skip it outright.
Sometimes when googling answers I end up on some odd PHP written forum site from ten years ago--ad heavy, huge profile pics, blinking emoticons, endless user signatures after every comment, answers and useless comments spread over multiple pages. Then I realize what wonderful system StackOverflow has created.
StackOverflow has its flaws but compared to the competition it's heaven. Moreover, when reading OP's 'Computer systems are designed to be figured out from their manuals or APIs' I stop reading. Sometimes systems are so new there isn't a manual yet (eg when Node started) or you just deal with complex matters where multiple systems are interweaved.
I learned tons of stuff on SO I would have never figured out myself. Also, how comments and answers are conceptually and visually separated is just very smart and the pain point of every other Q&A site.
I'm dealing with Azure at work right now you would not believe how much of their API is undocumented or unexplained.
My company is being courted by MS a bit, because they want us on Azure, so I was able to talk to some of their developers on the phone when I hit roadblocks. The amount of things they admitted to me were undocumented was enormous.
That's pretty par for the course, I've found. I do a lot of work with Skype for Business/Lync, and besides it seeming like there's about fifty people in the world that regularly work with this stuff, the documentation tends to be a trainwreck. Thank goodness for Reflector and dotPeek.
Is any of this news? This company always hypes stuff that is years away or unfinished and buggy for years, there API documentation is deliberately incomplete to have an competitive advantage in case they want to change private API bits in front of their competition, etc. It was bad, it got better and now it is worse.
To be fair, that's because the stuff they hype is invariably humongous. From win32 onwards, all their solutions involved inordinate amounts of libraries and features, pandering to absolutely everyone and his dog. No wonder they also had tons of undocumented nooks and crannies...
All considered, MSDN has always had a huge amount of content, which was pruned only sporadically. It has long been the gold standard for technical docs; good luck finding that sort of detail for mainstream projects like KDE, Gnome, or even the Linux kernel.
Fair? Is the truth uncomfortable? Yes. Deal with it. And this company was never fair, at any time, to anyone. With Steve's stint as CEO after a few years he got softer and that was the best era of the company and for everyone else. But the current CEO [edited] turned the ship to be pretty end-user hostile (forced monthly updates on recent products, spying on user), the crude bribing of enterprise CTOs and their products are buggier and less documented then ever before. Devs run away, mobile market share is <1%. The trust is gone.
Holy crap, dude, calm down. "India-born Bill 2.0 from a high caste", really? I hope someone flags it. I may or may not agree with some of your points, but there is no need to pepper your argument with gratuitous racism.
MS has always been an aggressive company doing some bad things. I'm far from a MS apologist (where were you in 2000? I was in a social squat learning about Linux...), but I'm old enough to give props where props are due regardless of my "religious beliefs". MS docs are still way better than Oracle docs, to mention but one "bad" corp doing "bad" things. That's all there is.
I remember moderators pointing everyone to the search-function of the board and if you used it the first 3 pages of the search where threads where the moderators are pointing people to the search-function.
This behavior shaped my opinion about moderators permanently...
When I run into an issue, and happen to land on a stack overflow page when searching on it, I don't just try and find a solution that lets me do what I want to do. I try and figure out -why I'm having difficulty- in the first place.
This might be because I don't know the language/library/whatever, or have forgotten some key bugaboo in the stack I'm using, or that its documentation hasn't been updated, or that the holistic knowledge I need to get a useful example isn't really spelled out anywhere canonical (all that exists are descriptions of API endpoints, not a manual or tutorial that tells me how to bring it all together). In which case, a simple "here's how you do it" is -entirely sufficient-; SO can deliver this.
But it also might be because I have a fundamental misunderstanding, as per the OP's example. In which case I read the answers on SO, or anywhere else, -to correct that understanding-. And frequently, SO delivers on that. While there may be a one liner "Just do XYZ" to hack around it, there is almost invariably (and in fact, it's usually the highest rated) an answer from someone explaining the code or idea in question, and the right way to do it. Again, SO can deliver this.
This decision of which sort of answer you're looking for isn't due to a specific source of answers, but what sort of answer is good enough for you. If you have an issue of the latter variety, where you have a misunderstanding, but the former kind of answer is sufficient for someone, where they just are enabled in that misunderstanding, rather than correcting it, then that speaks ill of the person accepting that answer, not of SO enabling that (along with the correct) kind of answer.
Some people like this "reject the premise of the question" approach -- "op, what you want to do is wrong, and here's why. This is what you want to do instead, and here's why."
But some people loathe it, because they're forced into some stupid situation by an idiot boss and they know the right way to do something. They don't know the right way to do something, which is why they're asking the question. But now the question isn't about getting them help, but about an argument over whether they're asking the right question or not.
Question askers should probably include a line about whether their happy for the premise to be rejected or not; answerers and commenters need to lay off a bit. (Not completely: the answer is also for the future people who arrive via search engines, and those people probably want the right way answer).
I asked about this in the fairly early days of SO [1]. Nowadays, it's clear that you're not just answering the OP, but thousands of other people. I think that's worth taking into consideration.
> Question askers should probably include a line about whether their happy for the premise to be rejected or not
This is a good alternative to being too hard-lined one way or the other.
Exactly because others will come from Google to get an answer to the question is the reason why answerers should actually answer the question. Often somebody will write something like
"How do you solve X? --- I'm trying to do A and encountered this problem, so how do I solve X?"
And then the people will tell the user how to solve A without solving X. Except that everybody else will come from Google looking how to solve X, and that's infuriating.
I also don't quite get how Stackoverflow is so accepting of people talking down on others in this way. Like if somebody asks "Can a near-zero floating value cause a divide-by-zero error?" and the best rated answer is "Floating point division by zero is not an error." (http://stackoverflow.com/questions/12114498/can-a-near-zero-...)
You're correct, and that was unfair of me to say; it may not be an issue with the person, but with the set of considerations being imposed on the person, internally or externally.
Stackoverflow has been a real issue for my team. Too many of my junior developers seem to hold the information as gospel. Something I frequently am forced to reiterate is that just because a dozen idiots up vote an incorrect answer doesn't make it the best or proper way to accomplish something.
The second issue is with understanding. I hold a firm rule, never commit code that you do not fully understand. Because when it breaks, you will have no idea how to fix it. Too often I see developers copy/paste directly, and just change variable names. You aren't writing code, you're playing dev Lego.
My final issue is their draconian insistence on what they consider subjective question locking. When I'm making a technological choice, I'm looking for real world usage, and comparisons between frameworks. These questions can be asked and answered in non-subjective ways; yet even when done so, anything with the word "compare" gets locked. This would be the real value to me, as my research time is very limited, and being able to exclude frameworks and tools based on objective comparisons of feature sets or capabilities and limitations would be highly valuable to me.
Your third point really hits home for me. The most useful questions & answers I've ever found on S.O. tend to be locked more often than not. And even if they are slightly off topic, they're much more useful and informative to me during my research than the more common type (e.g. http://www.doxdesk.com/img/updates/20091116-so-large.gif). I understand this isn't the point of S.O. but there's really no resource like it for that kind of research.
The worst part about the locked questions is that they often appear in top spots in Google. So you see the question in the search results, exactly what you've been looking for, but then some bureaucrat has locked it.
It would be more honest if they'd delete locked questions from the site, then they at least wouldn't spam Google result pages ... but the way it's currently implemented is infuriating.
> Too often I see developers copy/paste directly, and just change variable names.
Yeah, I don't think StackOverflow is your problem. I mean, if they're going to blindly paste code, surely doing that from community-curated examples is better than whatever junk they'd find.
This. SO gets a lot of flack for stuff these days, and it falls into two camps - one camp is 'they hate fun', 'they close my questions', where people want to reduce the quality of the content on SO, and one is the 'the content isn't perfect' camp that complains about stuff like this.
It reminds me of the 'wikipedia can be wrong!' crowd - yes, that's inherant to the format. Yes, you are going to need to check things you read there, yes, your 20 page essay about why you are the best person in the world is going to get deleted.
Every time I see a critisism of SO, I tend to see someone who would make the site worse or is misusing the site. Not saying SO is perfect - more can be done to help those people become good contributors or users, but SO is very well designed, and the quality of the content is really very good.
One thing that he doesn't seem to touch on is the voting system for answers where the best ones usually get the most votes (often it isn't the chosen answer). Google search results are probably based on some blog's popularity rather than their correctness of answer, whereas Stack Overflow answers will be up/down voted by people with at least some knowledge of the subject.
This brings up an important point: there are lots of people out there who are rejecting technological augmentation of human intelligence in favor of the older ways like rote memorization and reading the manual. It's like people who want to study a map first rather than just depending on getting real time directions with GPS while driving. Or reading deeply from primary sources about history rather than crowd sourcing questions to historians.
It will be interesting to see how this plays out, but I suspect that like the Luddites and their looms, augmented human intelligence via computers will win out in the end. People will simply find it more efficient to tackle learning from a agile perspective using search and crowd sourcing to grab what you need when you need it rather than doing a lot more reading up front and later sifting through what they need and don't need (YAGNI for knowledge?).
...until the computers shut down because of a simple power outage or an DDoS attack. Then the Luddists and their looms will definitely win. When you rely on technology, you rely on a single point of failure.
There's also the question of speed/efficiency as well. Memorizing a fact and utilizing muscle memory can be much quicker than Googling for Stack Overflow answers every day ("memory caching"). And the faster you solve one problem, the faster you can move onto the next problem.
All we need to do is run out of energy and looms will be in vogue again, the industrial revolution is on the verge of collapse? If the computers shut down, I'm not going to be doing anything anyways.
I find solving problems also improves my efficiency in solving similar problems even if I solved the first problem originally using stack overflow. The mind is incredibly efficient at generalizing from experience, and you really get none of that generalization poweress by reading the manual rather than just doing it.
This feels kind of like the difference between western and eastern educational systems, the latter placing more emphasis in memorization and preparation, the former moving towards a more solve problems paradigm. Lots of practice solving problems is good enough as long as the details needed to solve problems are readily accessible.
This seems like a fairly narrow view on how people learn from others. The assumption the author makes is that if you look up the answer in the back of the book you won't think about how it's done. Yes, some people will do this for the sake of time, but in my experience I think SO does a good job of encouraging a learning environment by requesting answers provide context.
The example given by the author about moving buttons in iOS tries to make the case that there are unknown implications to finding a "hack" to solve a tough problem. I look for this type of information on SO all the time – usually not to implement the exact solution but to learn how others have solved similar problems that will help me think about the specific issue I am tackling. That's how I learn. Not for everybody, and I recognize we all do things differently.
I already have enough interesting problems that I need to solve without SO, because they're obscure enough or because I'm one of the first people doing "said thing".
If SO can help me solve some dumb CRUD problem more quickly or navigate a rather poorly written API (android, iOS, azure, and, well, most APIs actually), then I'll take that route. It never ceases to baffle me how many developers think esoteric language or library knowledge makes them good at their job. You're missing the forest for the trees guys and gals!
As another commenter said if I find that the SO answer provides a counter intuitive solition or gives me some hint that I'm thinking about something in the wrong way then I will of course chase down the "why" of what I'm doing.
I feel like using Stack Overflow as a reference and not as an "answer" is the way to go.
I get that a lot of the time you get your answer, but reading the answer and understanding it is why Stack Overflow is so beneficial. Yes it does save time but it should be used to learn.
>>> Computer systems are designed to be figured out from their manuals or APIs.
I go straight to StackOverflow with no shame. I rarely use the code snippets as-is, but even pointing me to a useful library that I didn't know about can be helpful.
I appreciate the exercise of learning how to use a system from its manuals. I practically memorized the manuals for every successive version of Turbo Pascal up to around 1990. I know every chip in the 1982 National Semiconductor Linear Databook.
But Turbo Pascal was also completely self contained, and came from a single source. Today, I don't even know what the "manual" for something like Python and its ecosystem of add-ons, really means. But whatever it is, a manual needs an index, and for me that index is Google/StackOverflow.
For me, the article points at a specific instance of a general phenomena. The bigger potential issue is googling by default rather than a last resort: increasingly, it is looking like a short term expedient and long term dependency for me, personally.
Yesterday as I was fooling around with Writing GNU Emacs Extensions. One of the great things about that book is that Glickstein figures [correctly in my case] that someone learning to write extensions might not have a good handle on other aspects of Emacs...such as help. It hit me how googling tends to drop me into the emacs manual or other high level references and how impossible it is to drill down on specifics in the way the Emacs help system allows. I mean I can google up a list of the top 150 Emacs keyboard shortcut, but I can't google up "C-x n".
While I love StackOverflow, the overhead of "What does 'C-x n' do?" is astronomical...even if such questions were appropriate.
I've trained myself to break flow and look at ads every few minutes because Google seems great. I'll even google knowing it will have some StackOverflow links under the ads at the top instead of going to the site directly. What I won't get is the great local resource that sits on my machine.
Interestingly DuckDuckGo gives you a box with the Emacs command when you search for "C-x n" (although the quick reference they link to doesn't even include that command). Of course, if you want to know what a shortcut does in Emacs, you can just use "C-h C-h c <the shortcut>". Or if you want to know what a function does and what it's bound to, "C-h C-h f <funtion>".
The reason DuckDuckGo returns nothing for "C-x n" is that it is unbound by default. Which makes it useful for writing extensions. Using the help system as "C-h k C-x n" tells me that it is unbound. That's information I cannot get with google...and can only infer from DDG's results.
What I've realized is that problems like learning DDG's results for Emacs key bindings are XY problems. The right problem is learning Emacs help.
One thing that rings true is that the most difficult part of discovering an answer is formulating the "correct" question. Once you can articulate the actual question, finding the answer is straight forward.
I have had some recent SO frustration with sheer number of answering/seeing SO posts where I have been like... you really couldn't have just googled that?
I guess basically boils down to conversation vs searching. In the last couple of years (maybe more) I have seen less searching and more asking questions in general. I think a large group of mature technologist know how to use Google and prefer it over human intervention... ie a conversation. That is the initial tech culture was RTFM. But there is a growing population particularly where English is not their first language where they prefer to ask over search. I believe this is also culture thing as well. Perhaps a more social culture.
In the US we are so used to Google but in other countries social media, messaging apps, and improved connectivity are really pushing the "conversation interface" and appears to be preferred heavily over the "search interface". That is people seem to want to ask and not search.
I honestly don't know for sure which "interface" is more efficient or better but clearly given Siri and various other AI conversation thing coming out the conversation approach is popular.
Really? I buy the argument that doing what you set out to do is not always best, but I find most questions answered with 'Well, you could do this, but really, you want to do this...' on SO in cases like those. Sometimes they are not the accepted answers, but it's rare it's not the top voted one.
I once got into a heated argument with a colleague.
We were working on a legacy C# project where the initial architecture was such that a RAKEFILE (ruby-make) was used to make a call to CSC.exe (the C# compiler).
"It's easy, we use Ruby to compile our C# so we can use wildcards .cs" (to say nothing of the problems caused by the loading of '.DLL' from the bin folder on app start)
Over time, when I was finally comfortable with the project, and after days of trial and error, I added CSPROJ files for each of the projects and was finally able to compile, run, and debug in visual studio.
When I tried to commit the CSPROJ files into git, he deleted them on the next commit.
When I asked why he removed the files is was a gongshow. "Why in hell should I allow you to put your shit in my repo?" He snapped.
When I explained that using intellisense & debugging were both incredibly valuable.
He countered with "why don't you just memorize the namespace (because that is what better programmers do)"
And "why don't you just use print statements to inspect values? (because that is what better programmers do)"
Skipping stack overflow is a similar sort of self hamstringing that I can't get behind.
Getting the job done quickly is part of what we're paid for. (Caveat* optimally quickly of course, there are plenty of times when taking a bit longer pays off in the long run)
To play devil's advocate: merging csproj files is a PITA. It's too bad VS can't just read the file system to determine what files/namespaces are in a project like virtually everyone else does.
You're right about the PITA, and they start out seeming like a wildly complicated and painfully documented dog's breakfast. I'm happy that .net CORE is moving to dynamic inclusion via "magic"
However, once you are used to CSPROJ, they're actually ok to understand & merge.
Additionally, if you're a c# shop, using msbuild & msdeploy gives you a lot more than hand rolling 100% of your compilation tools. If you stick to the framework, you save money.
Occasional minor merge conflicts around file includes are minor relative the the ability to step-through-debug the code and get project wide code completion via intellisense.
This begs the question of how legacy something would have to be for them to initially setup the project in such a shitshow fashion in the first place. Too cheap to buy VS licenses, back when the community edition/express editions weren't a thing?
Or maybe that I have so much Stockholm Syndrome from living inside Visual Studio world for too long.
Well, we're talking about a company that is ~15 years old but the legacy portion of this system is likely less than 10. (I've been there near 5 and it was old when I got there)
I never thought the arguments in favor of using RUBY to compile your C# held a lot of water.
"Visual studio is a slow and clunky resource hog" was one argument, which I don't feel has been true for a long while.
They were mostly preference based decisions. But (IMO) ones that optimized for the wrong result.
Dynamically loading .DLL means that if the DLL is in the bin folder you can use it anywhere in your code without requiring a using statement.
Let me tell you how many hours I've spent hunting down namespace conflicts.
Compiling .cs saves time & conflicts in managing CSPROJ files... But if you decide to leave the framework in 2005 & the tools keep moving forward for 10 years, you eventually either miss out on a lot of really important features, or spend time implementing things that are not your core business or competency.
We wound up getting locked in to dozens of horrifically limiting technologies because of the design choices.
I feel like it was a bit of a case of "programmer hubris" that lead to the shit-show.
Thinking "I personally can do it better" (than the billion dollar company dedicating more resources to this tool than the size of our entire company) can be a pretty bad decision.
I've had a few discussions about the choices and preferences with the original dev.
He still thinks VS is crap, MSBuild doesn't do anything that you can't get from CSC.exe, and docker is just a VM.
Well, we're talking about a company that is ~15 years old but the legacy portion of this system is likely less than 10. (I've been there near 5 and it was old when I got there)
I never thought the arguments in favor of using RUBY to compile your C# held a lot of water.
"Visual studio is a slow and clunky resource hog" was one argument, which I don't feel has been true for a long while.
They were mostly preference based decisions. But (IMO) ones that optimized for the wrong result.
Dynamically loading .DLL means that if the DLL is in the bin folder you can use it anywhere in your code without requiring a using statement.
Let me tell you how many hours I've spent hunting down namespace conflicts.
Compiling .cs saves time & conflicts in managing CSPROJ files... But if you decide to leave the framework in 2005 & the tools keep moving forward for 10 years, you eventually either miss out on a lot of really important features, or spend time implementing things that are not your core business or competency.
We wound up getting locked in to dozens of horrifically limiting technologies because of the design choices.
I feel like it was a bit of a case of "programmer hubris" that lead to the shit-show.
Thinking "I personally can do it better" (than the billion dollar company dedicating more resources to this tool than the size of our entire company) can be a pretty bad decision.
I've had a few discussions about the choices and preferences with the original dev.
He still thinks VS is crap, MSBuild doesn't do anything that you can't get from CSC.exe, and docker is just a VM.
>I’ll Google for the answer, but only read articles people wrote and posted on their own sites.
Funny thing is there are a lot of sites that just republish the SO post. Also, there's the reverse where you find a really good blog post in an SO answer.
>so you copy and paste code fragments from up and down the page, in a vain attempt to shut the problem down
I almost never do this. I read the snippets to get the idea of why they would work which helps me understand the problem better.
>Learning to read an API or manual will save you time.
It's even better when the library/framework you're using is open source so you can just look at what the code is doing vs. what they say it's doing.
Unfortunately, rise of the Stack Overflow and alike made developers far too lazy to write any decent documentation.
Last time I saw a documentation I would consider beautiful, comprehensive and really well written was back in the OpenVMS days. You can see something distantly resembling that glorious style if you type 'help' in gnuplot.
61 comments
[ 2.8 ms ] story [ 118 ms ] threadSometimes you get stuck on things that are blockers and time consuming but there isn't a lot of learning value there.
Saving time on these kind of blockers means i can spend more time on learning concepts and higher level things that help me become a better coder.
Quantity does not make up for quality.
Lol. If only every API was designed and documented well.
StackOverflow has its flaws but compared to the competition it's heaven. Moreover, when reading OP's 'Computer systems are designed to be figured out from their manuals or APIs' I stop reading. Sometimes systems are so new there isn't a manual yet (eg when Node started) or you just deal with complex matters where multiple systems are interweaved.
I learned tons of stuff on SO I would have never figured out myself. Also, how comments and answers are conceptually and visually separated is just very smart and the pain point of every other Q&A site.
My company is being courted by MS a bit, because they want us on Azure, so I was able to talk to some of their developers on the phone when I hit roadblocks. The amount of things they admitted to me were undocumented was enormous.
All considered, MSDN has always had a huge amount of content, which was pruned only sporadically. It has long been the gold standard for technical docs; good luck finding that sort of detail for mainstream projects like KDE, Gnome, or even the Linux kernel.
MS has always been an aggressive company doing some bad things. I'm far from a MS apologist (where were you in 2000? I was in a social squat learning about Linux...), but I'm old enough to give props where props are due regardless of my "religious beliefs". MS docs are still way better than Oracle docs, to mention but one "bad" corp doing "bad" things. That's all there is.
If the CEO happened to be of Bavarian Aristocratic heritage, would pointing that out be racist?
Satya Nadella is of the Brahmin caste, there is not one thing racist in noting it.
I remember moderators pointing everyone to the search-function of the board and if you used it the first 3 pages of the search where threads where the moderators are pointing people to the search-function.
This behavior shaped my opinion about moderators permanently...
When I run into an issue, and happen to land on a stack overflow page when searching on it, I don't just try and find a solution that lets me do what I want to do. I try and figure out -why I'm having difficulty- in the first place.
This might be because I don't know the language/library/whatever, or have forgotten some key bugaboo in the stack I'm using, or that its documentation hasn't been updated, or that the holistic knowledge I need to get a useful example isn't really spelled out anywhere canonical (all that exists are descriptions of API endpoints, not a manual or tutorial that tells me how to bring it all together). In which case, a simple "here's how you do it" is -entirely sufficient-; SO can deliver this.
But it also might be because I have a fundamental misunderstanding, as per the OP's example. In which case I read the answers on SO, or anywhere else, -to correct that understanding-. And frequently, SO delivers on that. While there may be a one liner "Just do XYZ" to hack around it, there is almost invariably (and in fact, it's usually the highest rated) an answer from someone explaining the code or idea in question, and the right way to do it. Again, SO can deliver this.
This decision of which sort of answer you're looking for isn't due to a specific source of answers, but what sort of answer is good enough for you. If you have an issue of the latter variety, where you have a misunderstanding, but the former kind of answer is sufficient for someone, where they just are enabled in that misunderstanding, rather than correcting it, then that speaks ill of the person accepting that answer, not of SO enabling that (along with the correct) kind of answer.
But some people loathe it, because they're forced into some stupid situation by an idiot boss and they know the right way to do something. They don't know the right way to do something, which is why they're asking the question. But now the question isn't about getting them help, but about an argument over whether they're asking the right question or not.
Question askers should probably include a line about whether their happy for the premise to be rejected or not; answerers and commenters need to lay off a bit. (Not completely: the answer is also for the future people who arrive via search engines, and those people probably want the right way answer).
> Question askers should probably include a line about whether their happy for the premise to be rejected or not
This is a good alternative to being too hard-lined one way or the other.
[1] http://meta.stackexchange.com/questions/45536/on-answering-t...
"How do you solve X? --- I'm trying to do A and encountered this problem, so how do I solve X?"
And then the people will tell the user how to solve A without solving X. Except that everybody else will come from Google looking how to solve X, and that's infuriating.
I also don't quite get how Stackoverflow is so accepting of people talking down on others in this way. Like if somebody asks "Can a near-zero floating value cause a divide-by-zero error?" and the best rated answer is "Floating point division by zero is not an error." (http://stackoverflow.com/questions/12114498/can-a-near-zero-...)
Have you tried to code angular2 or something else new? Documentation simply does not exist.
StackOverflow is the de facto documentation source for a lot of things.
On lots of occasions it is not a shortcut, it's simply the only place you can get an answer.
The second issue is with understanding. I hold a firm rule, never commit code that you do not fully understand. Because when it breaks, you will have no idea how to fix it. Too often I see developers copy/paste directly, and just change variable names. You aren't writing code, you're playing dev Lego.
My final issue is their draconian insistence on what they consider subjective question locking. When I'm making a technological choice, I'm looking for real world usage, and comparisons between frameworks. These questions can be asked and answered in non-subjective ways; yet even when done so, anything with the word "compare" gets locked. This would be the real value to me, as my research time is very limited, and being able to exclude frameworks and tools based on objective comparisons of feature sets or capabilities and limitations would be highly valuable to me.
http://softwarerecs.stackexchange.com/
I have found that MDN is a way better resource, including pedagogic examples for most (if not all) concepts without using bloated libraries.
It would be more honest if they'd delete locked questions from the site, then they at least wouldn't spam Google result pages ... but the way it's currently implemented is infuriating.
Yeah, I don't think StackOverflow is your problem. I mean, if they're going to blindly paste code, surely doing that from community-curated examples is better than whatever junk they'd find.
It reminds me of the 'wikipedia can be wrong!' crowd - yes, that's inherant to the format. Yes, you are going to need to check things you read there, yes, your 20 page essay about why you are the best person in the world is going to get deleted.
Every time I see a critisism of SO, I tend to see someone who would make the site worse or is misusing the site. Not saying SO is perfect - more can be done to help those people become good contributors or users, but SO is very well designed, and the quality of the content is really very good.
It will be interesting to see how this plays out, but I suspect that like the Luddites and their looms, augmented human intelligence via computers will win out in the end. People will simply find it more efficient to tackle learning from a agile perspective using search and crowd sourcing to grab what you need when you need it rather than doing a lot more reading up front and later sifting through what they need and don't need (YAGNI for knowledge?).
There's also the question of speed/efficiency as well. Memorizing a fact and utilizing muscle memory can be much quicker than Googling for Stack Overflow answers every day ("memory caching"). And the faster you solve one problem, the faster you can move onto the next problem.
I find solving problems also improves my efficiency in solving similar problems even if I solved the first problem originally using stack overflow. The mind is incredibly efficient at generalizing from experience, and you really get none of that generalization poweress by reading the manual rather than just doing it.
This feels kind of like the difference between western and eastern educational systems, the latter placing more emphasis in memorization and preparation, the former moving towards a more solve problems paradigm. Lots of practice solving problems is good enough as long as the details needed to solve problems are readily accessible.
The example given by the author about moving buttons in iOS tries to make the case that there are unknown implications to finding a "hack" to solve a tough problem. I look for this type of information on SO all the time – usually not to implement the exact solution but to learn how others have solved similar problems that will help me think about the specific issue I am tackling. That's how I learn. Not for everybody, and I recognize we all do things differently.
If SO can help me solve some dumb CRUD problem more quickly or navigate a rather poorly written API (android, iOS, azure, and, well, most APIs actually), then I'll take that route. It never ceases to baffle me how many developers think esoteric language or library knowledge makes them good at their job. You're missing the forest for the trees guys and gals!
As another commenter said if I find that the SO answer provides a counter intuitive solition or gives me some hint that I'm thinking about something in the wrong way then I will of course chase down the "why" of what I'm doing.
I get that a lot of the time you get your answer, but reading the answer and understanding it is why Stack Overflow is so beneficial. Yes it does save time but it should be used to learn.
I go straight to StackOverflow with no shame. I rarely use the code snippets as-is, but even pointing me to a useful library that I didn't know about can be helpful.
I appreciate the exercise of learning how to use a system from its manuals. I practically memorized the manuals for every successive version of Turbo Pascal up to around 1990. I know every chip in the 1982 National Semiconductor Linear Databook.
But Turbo Pascal was also completely self contained, and came from a single source. Today, I don't even know what the "manual" for something like Python and its ecosystem of add-ons, really means. But whatever it is, a manual needs an index, and for me that index is Google/StackOverflow.
Yesterday as I was fooling around with Writing GNU Emacs Extensions. One of the great things about that book is that Glickstein figures [correctly in my case] that someone learning to write extensions might not have a good handle on other aspects of Emacs...such as help. It hit me how googling tends to drop me into the emacs manual or other high level references and how impossible it is to drill down on specifics in the way the Emacs help system allows. I mean I can google up a list of the top 150 Emacs keyboard shortcut, but I can't google up "C-x n".
While I love StackOverflow, the overhead of "What does 'C-x n' do?" is astronomical...even if such questions were appropriate.
I've trained myself to break flow and look at ads every few minutes because Google seems great. I'll even google knowing it will have some StackOverflow links under the ads at the top instead of going to the site directly. What I won't get is the great local resource that sits on my machine.
What I've realized is that problems like learning DDG's results for Emacs key bindings are XY problems. The right problem is learning Emacs help.
I guess basically boils down to conversation vs searching. In the last couple of years (maybe more) I have seen less searching and more asking questions in general. I think a large group of mature technologist know how to use Google and prefer it over human intervention... ie a conversation. That is the initial tech culture was RTFM. But there is a growing population particularly where English is not their first language where they prefer to ask over search. I believe this is also culture thing as well. Perhaps a more social culture.
In the US we are so used to Google but in other countries social media, messaging apps, and improved connectivity are really pushing the "conversation interface" and appears to be preferred heavily over the "search interface". That is people seem to want to ask and not search.
I honestly don't know for sure which "interface" is more efficient or better but clearly given Siri and various other AI conversation thing coming out the conversation approach is popular.
We were working on a legacy C# project where the initial architecture was such that a RAKEFILE (ruby-make) was used to make a call to CSC.exe (the C# compiler).
"It's easy, we use Ruby to compile our C# so we can use wildcards .cs" (to say nothing of the problems caused by the loading of '.DLL' from the bin folder on app start)
Over time, when I was finally comfortable with the project, and after days of trial and error, I added CSPROJ files for each of the projects and was finally able to compile, run, and debug in visual studio.
When I tried to commit the CSPROJ files into git, he deleted them on the next commit.
When I asked why he removed the files is was a gongshow. "Why in hell should I allow you to put your shit in my repo?" He snapped.
When I explained that using intellisense & debugging were both incredibly valuable.
He countered with "why don't you just memorize the namespace (because that is what better programmers do)"
And "why don't you just use print statements to inspect values? (because that is what better programmers do)"
Skipping stack overflow is a similar sort of self hamstringing that I can't get behind.
Getting the job done quickly is part of what we're paid for. (Caveat* optimally quickly of course, there are plenty of times when taking a bit longer pays off in the long run)
Anyways, TL;DR skipping stack overflow is dumb.
However, once you are used to CSPROJ, they're actually ok to understand & merge.
Additionally, if you're a c# shop, using msbuild & msdeploy gives you a lot more than hand rolling 100% of your compilation tools. If you stick to the framework, you save money.
Occasional minor merge conflicts around file includes are minor relative the the ability to step-through-debug the code and get project wide code completion via intellisense.
Or maybe that I have so much Stockholm Syndrome from living inside Visual Studio world for too long.
I never thought the arguments in favor of using RUBY to compile your C# held a lot of water.
"Visual studio is a slow and clunky resource hog" was one argument, which I don't feel has been true for a long while.
They were mostly preference based decisions. But (IMO) ones that optimized for the wrong result.
Dynamically loading .DLL means that if the DLL is in the bin folder you can use it anywhere in your code without requiring a using statement.
Let me tell you how many hours I've spent hunting down namespace conflicts.
Compiling .cs saves time & conflicts in managing CSPROJ files... But if you decide to leave the framework in 2005 & the tools keep moving forward for 10 years, you eventually either miss out on a lot of really important features, or spend time implementing things that are not your core business or competency.
We wound up getting locked in to dozens of horrifically limiting technologies because of the design choices.
I feel like it was a bit of a case of "programmer hubris" that lead to the shit-show.
Thinking "I personally can do it better" (than the billion dollar company dedicating more resources to this tool than the size of our entire company) can be a pretty bad decision.
I've had a few discussions about the choices and preferences with the original dev.
He still thinks VS is crap, MSBuild doesn't do anything that you can't get from CSC.exe, and docker is just a VM.
It's a difference of opinion.
I never thought the arguments in favor of using RUBY to compile your C# held a lot of water.
"Visual studio is a slow and clunky resource hog" was one argument, which I don't feel has been true for a long while.
They were mostly preference based decisions. But (IMO) ones that optimized for the wrong result.
Dynamically loading .DLL means that if the DLL is in the bin folder you can use it anywhere in your code without requiring a using statement.
Let me tell you how many hours I've spent hunting down namespace conflicts.
Compiling .cs saves time & conflicts in managing CSPROJ files... But if you decide to leave the framework in 2005 & the tools keep moving forward for 10 years, you eventually either miss out on a lot of really important features, or spend time implementing things that are not your core business or competency.
We wound up getting locked in to dozens of horrifically limiting technologies because of the design choices.
I feel like it was a bit of a case of "programmer hubris" that lead to the shit-show.
Thinking "I personally can do it better" (than the billion dollar company dedicating more resources to this tool than the size of our entire company) can be a pretty bad decision.
I've had a few discussions about the choices and preferences with the original dev.
He still thinks VS is crap, MSBuild doesn't do anything that you can't get from CSC.exe, and docker is just a VM.
It's a difference of opinion.
Funny thing is there are a lot of sites that just republish the SO post. Also, there's the reverse where you find a really good blog post in an SO answer.
>so you copy and paste code fragments from up and down the page, in a vain attempt to shut the problem down
I almost never do this. I read the snippets to get the idea of why they would work which helps me understand the problem better.
>Learning to read an API or manual will save you time.
It's even better when the library/framework you're using is open source so you can just look at what the code is doing vs. what they say it's doing.
Source?
A lot of software nowadays implicitely acknowledges the existence of SO or even open recommends to use this source.
Last time I saw a documentation I would consider beautiful, comprehensive and really well written was back in the OpenVMS days. You can see something distantly resembling that glorious style if you type 'help' in gnuplot.