SO and its ilk give me an example that I can start to cross reference with the API level docs, to figure out how to pull it all together, and also where to look to find the "gotchas", tweaks, and options.
Example:
Compiler throws error 0x19822943 on what looks like valid code. Googling the error code along with the compiler name almost invariably returns stackoverflow results near the top, so I look at the post(s) with answers and see "Oh yeah this is a known issue, upgrade to version 1.29 and it goes away".
For all the issues I have with the site it is still pretty great for these sorts of problems that should be covered in the support documentation for whatever it is that failed (but often isn't -- or isn't in a way that google is likely to find it easily).
trying to find some kind of shortcut to just get my code working by copy pasta-ing random bits of spagetti and crossing my fingers. Stop. There’s a better way.
is about as honest as the Juice Loosener pitch from the Simpsons [0]. It's impossible to be able to just copy and paste something you find online and have it work, especially while ignoring all context and learning nothing.
This, a billion times.
I wonder if there is a way to voluntarily downrank pages in search engines so that answers that are obsolete do not show up first in results.
If I'm having issues with Ubuntu 22.04, the solution to a similar problem in Ubuntu 10.04 is very much likely to be wrong.
I took that away from the article as well, although I doubt that is the author's original intent.
One thing I like to do, if I have the extra time, is pull out a couple of different algorithm's books (Cormen always being one) and see if I can find a new way of viewing a problem in light of an "algorithmic approach."
Admittedly the research takes time and is always a lot of fun as I explore many other "rabbit holes" but it leads to other insights as well. The thing I will try to do is capture a few bullet points that I may have gleaned during this exercise. The approach is not conducive to goal, or time, sensitive deadlines, however.
Personally, I avoid SO because I've seen too many wrong answers. I prefer documentation, or blogs explaining approaches. But, it can be a resource, especially to new developers, to help you understand how you need to think and how to approach problems. As a replacement for coding it yourself, it's might be hot garbage, so you should understand it before committing to having produced that code and assign your name to it.
I do too, in theory. In reality though, 90 percent of the time it's essentially unnavigable / unsearchable / basically intractable to use.
What you want is simply something that tells you "how do I do X" where X is some real-world thing, like strip the end-of-line characters from a file. What you get from "documentation" as such is a huge sprawl of text explaining the guys of 90 different command line options. Good luck digging your way through that.
Imperfect though it is, SO was created to address precisely this huge, gaping disparity between what users want, and what most "documentation" actually delivers. Did I mention it's imperfect? And that you actually have to (shudder) think about the examples given, before randomly cut-and-pasting them into production?
The whole point is though, that it's better than nothing, and frequently is mostly correct (and it's not that hard to tell when the answer is wrong or requires a bit of fine-tuning for your use case). And at the end of the day, still saves me hundreds of hours compared to the nearly useless "documentation" that ships with most running languages and platforms these days.
I'll keep doing what I've always done:
Look things up on stack overflow (and other sites), compare different answers and check the discussions as well, figure out WHY people are doing what they do - and then do my own experiments based on that.
For me personally, this leads to faster learning results than experimenting completely on my own, without any guidance.