Hacker News Reader

Comment by jordansmithnz | Hacker News Reader

Ha, stackoverflow is a great tool, but... the more answers I see on an area I’m experienced in, the more I realize how wrong they can be. Sure, the answer usually gets the job done, but everything else about it might not be right.

If I need to use stackoverflow, these days I make sure I do a few things:

- read a number of answers, comments included. Just because an answer is accepted doesn’t mean it’s the best one

- read API docs for anything I’m unfamiliar with, and make sure I understand how the solution works

- never copy paste; instead use the general idea or concept to rewrite a solution in a safe, future proof manner

- if an answer works but doesn’t feel like the right solution, be prepared to do my own research to find a better approach

Hopefully this results in a better engineered product, but one of the main benefits is learning and expanding knowledge of APIs/techniques.

View on HN

I'll suggest one more addition to this (and any code you take from the internet): put a comment in saying where you got the idea from (with a link). It can help the next guy out a lot. And you might be the next guy.

This is huge and has saved me a few times already when I became my own "next guy"

Especially if it's not a copy-paste job. If there's any adjustments or even a rewrite, the comment should include the reason why the changes were made. The next guy coming along might not realize that changes were needed

It's usually better to put that information in the revision comments when you commit rather than in the code itself. Otherwise the code accumulates layers and layers of comments over years.

I feel like it depends - I know I don't just start digging through the commit history of every line I edit.

If I'm trying to fix a bug, and only have to change one line for it to start working, and the tests still pass - but that line was there for a reason that wasn't commented (some edge case) - I'll likely miss it.

Personally, I've developed a strong preference for putting this type of information as close to the affected code as possible. Immediately next to the affected code is the only place these types of comments have a prayer of being kept up to date. Keeping them in another document, a commit message, or anything similar just results in the content of the message instantly going out of date.

So much this... I tend to do this. There are times where I need a limited subset of a library, and will just pull the two classes I need, add the comment at the top, and adjust the namespace.

Including an update to all of your copyright notices, of course

> put a comment in saying where you got the idea from (with a link)

StackOverflow content is licensed under CC BY-SA, so you're legally required to do that if you copy code from an answer. (Unless it's so trivial the code is not copyrightable, but it's better to be on the safe side and attribute the source correctly anyway.)

> And you might be the next guy.

It already happened to me a couple of times that I had a problem, googled it, and found a helpful SO answer .. by myself some years ago. So this is definitely a helpful suggestion.

> read API docs for anything I’m unfamiliar with

One of the differences i've noticed between myself and some of the junior devs i've worked with. I would usually use the official docs as my first resource, and they would use stack overflow instead.

I don't like this blanket statement ..

I would use whichever googles first and most relevant results are. Also what the issue is matters.

I don't always go to MDN for javascript issues.

But if I want to know why something is the way it is, I will.

> I would use whichever googles first and most relevant results are.

The people who made the mistake in the OP probably did exactly that.

As parent said, I don't recommend doing this. In particular, the third-party sources are unlikely get depreciation notes... So unless this is a function you know well, it is almost always better to go to official docs instead.

I will say that as a Ruby on Rails dev, where many things have changed over time, there are quite a lot of highly voted StackOverflow posts where they go into detail about what the answer is on the date of posting, then someone comments "this is different in Rails 4.1+!" and the responder will revisit the answer and revise it to include applicable advice for whichever version you might be on.

This is not granted, but it happens a lot. Although if the docs are good, you should definitely expect to find good information about deprecation notices there, too! But it's not at all uncommon for conversations about code, on StackOverflow or wherever else, to include the footnotes about what is different and what version changed it.

But what if the docs suck, as is the case with a lot of .io domain libraries?

Is the io prefix somehow related to software tech?

It is often used for the following (that I have seen - may be others):

- open source libraries - online casual browser games - development/staging environment counterpart to a .com

And anything MS?

Microsoft have best most fascinating documentation in some cases. It can be fantastically detailed, while being completely useless at the same time.

Take their Azure Python API, which is clearly translated directly from C#: There's a number of functions, which according to the documentation takes a string as an input. The thing is that it won't actually take a string, it will take three or four predefined strings. Everything else will yield no result. The only thing Microsoft doesn't care to put in the documentation is which strings are actually valid and what result you can expect from them.

This is slightly unrelated but there was a time when reading the azure docs where you’d be reading a page for version 1.0 but the sidebar would take you to the documentation for version 2.0 and I actually got caught up writing a mismatched integration and it took me forever to figure out why I had done that.

microsoft's documentation for anything other than .NET stuff is absurdly bad.

i was trying to do some work with their crm solution it took me a literal week to find out how to do simple oauth -- mostly because 99% of the documentation only had .NET examples using their own framework!

had extremely good experience with microsoft documentation. and i never did .NET. even old win32 API stuff still works, unlike many APIs i know of...

Microsoft's documentation for .NET is also absurdly bad.

No, I don't want to do a full reload for every overload of a method. Yes, I might want to see where these extension methods are popping up from, out of nowhere.

Microsoft documentation was historically the gold standard for comprehensiveness and quality. If what the other commenter says (e.g. about their Azure docs) is true, I don't know if things have changed or what. Maybe a post-Nadella culture shift?

A lot of MS documentation now is awful. Azure stuff especially.

Sometimes there is just no usable documentation for certain things at all. I've even seen documentation for certain Azure things where it just directs you to Stack Overflow!

At one point they "burned the library" and broke a lot of old MSDN urls. It's now common to find dead links to MSDN on old Stackoverflow posts.

The documentation is definitely there, but finding it can be a curse. The search is worse than Google, the site is surprisingly slow for a bunch of static text, and the ability to discover something when you don't know the right search terms is poor because Microsoft name everything in the most generic way possible.

The Microsoft Docs change from MSDN was horrible (and still is). A lot of content got mysteriously mangled for no discernable reason. Their KB articles, which used to be excellent, have mostly been "disappeared" too. You can see a vast difference in quality between the newly-written pages and what was inherited from before. I find spelling and grammar errors often in the newer pages.

I guess people's expectations might have been lower? MSDN sucks along every axis I can imagine.

The content is bad: Quick, is System.DateTime[0] timezone-aware? The examples also use (the harmful and bug-prone) DateTime.Now 5 times, while DateTime.UtcNow is only mentioned once, as a minor aside.

The structure is bad: Is something part of "Core", "Framework", "Standard", or "Platform Extensions"? It's particularly ridiculous that trying to switch from Core to Platform Extensions while you're viewing a Core class (such as System.DateTime[0]), you'll get kicked over to.. Framework.

The layout is bad: Look at System.DateTime's list of constructors[1]. It takes up a whole screenful to say what Python's datetime.datetime constructor[2] paragraph says in three lines.

The design is bad: Compare the method listing of .NET's IDictionary[3] to Scala's Map[4], or Rust's HashMap[5]. Which one makes the type signatures the easiest to parse? Which one helps you get where you want to the fastest?

(Hint: For me, at least, not the one that insists on making everything a uniform shade of baby blue.)

[0]: https://docs.microsoft.com/en-us/dotnet/api/system.datetime?...

[1]: https://docs.microsoft.com/en-us/dotnet/api/system.datetime?...

[2]: https://docs.python.org/3/library/datetime.html?highlight=da...

[3]: https://docs.microsoft.com/en-us/dotnet/api/system.collectio...

[4]: https://www.scala-lang.org/api/current/scala/collection/immu...

[5]: https://doc.rust-lang.org/stable/std/collections/struct.Hash...

Python's datetime appears to have one constructor with several optional parameters, whereas .NET's System.DateTime has several separate constructors each taking a different set of parameters. The MSDN documentation is accurate and correct; your critique applies to the underlying code (which is built to be backwards-compatible to .NET 1.0, which I don't think even supported optional arguments).

The signatures that are useful when developing the library might be more complex than the ones that the library consumer would be interested in. This isn't much of an excuse when you also maintain the documentation tools.

For a similar example, Scala's old collections library had a ton of machinery to ensure that `map` and co. would specialize correctly.[0] But the user never sees that, because they added a mechanism called "use cases", that allow you to override the signature shown in the docs with a simpler one.[1]

[0]: https://github.com/scala/scala/blob/v2.12.10/src/library/sca...

[1]: https://www.scala-lang.org/api/2.12.10/scala/collection/immu...

once have a working dev environment, external docs are the last place to look.

IDE type search and doc comments are much more likely to be useful.

I use a combination of both. I'll find something on stack overflow, and then look it up in the official documentation. In other words, treat stack overflow like a sophisticated index to a reference rather than as a reference itself.

It's a common use-case that the best docs are provided on some dude's gist or blogpost. Devs and orgs update the code but don't bother with the forgotten docs. It happens all the time.

And the original article here is showing a real-world example of the opposite.

Namely, "some dude's gist or blogpost [or stack overflow answer]" not getting updated. Not just that they didn't but that they couldn't.

Unsurprisingly, which you should rely on depends heavily on context. It takes experience and patience to figure out which one is correct based on circumstances.

This is a hard lesson I had to learn as a junior developer.

I'm impatient and Stack overflow can often give me an easy solution. But just as often, it can't and I will spend 30 minutes unproductively trying things with little progress.

As I become a better developer I become more inclined to spend 30 minutes with the documentation instead.

Depends on how clear the documentation/usage is... and sometimes you accept that you have limited knowledge and understanding. Either way, it helps to understand what you are doing, and when in doubt look it up.

If the library documentation isn't clear then that's a clear sign that whoever created it doesn't take quality seriously and you shouldn't use it in the first place. Of course sometimes there's no alternative so you just have to deal with it.

I face a lot of anxiety from this. I'll have a task like setting up Point in Time Recovery for postgres, and I've spent days mostly just reading documentation - How postgres manages wal logs, how the internals of several popular solutions work etc.

I know it'll be worth it in the long run, but it feels like I'm wasting time because "I'm not doing anything" - I'm not committing any changes while my coworkers are busy adding new features.

When you're reading documentation, you also will notice other things in addition to solving your particular problem. Those other things might be helpful few minutes later and you will actually save that time. Or may be tomorrow, if your memory is good. Or may be you'll read those documentation and will actually find a better solution.

Of course most of interesting problems are not described in documentation.

I agree:

Recently I found an interesting snippet of C code which was using an sprintf to write a string into a char array. Unfortunately, it contained an off-by-one error where the null terminator would be written outside the char.

I proposed to fix the answer, but for incomprehensible reasons the edit was rejected (!)

SO is the worst example of "poop must be delicious - after all, billions of flies can't be wrong!" mentality. As long as the answer is upvoted by enough people, it's accepted as the right one and it takes a titanic effort to correct it, no matter how wrong it is.

> As long as the answer is upvoted by enough people, it's accepted as the right one

That's not correct; the questioner can accept any answer, the criteria is that the questioner chooses which answer helped them. There is no connection between votes and acceptance, no claim that "accepted" is endorsement by StackOverflow the company, by subject matter experts, or by "the community".

See https://meta.stackexchange.com/a/164449/192171

If an answer is factually wrong (as opposed to just poorly formatted or missing a few details), generally its better to leave a comment rather than try to edit it.

I agree its not ideal, but suggested edits go into a site-wide review queue, so not everyone reviewing them will necessarily be familiar with C. This makes edit reviews a poor tool for evaluating factual correctness; the comments section and voting system on answers is a better tool for that job.

"You can comment" doesn't help when you need a certain rep threshold just to comment.

Don't you need more to propose an edit?

"We must fix grammatical errors and must not fix technical errors" agrees with my experience on stackoverflow perfectly.

Fixing technical errors is strongly encouraged, just not via the suggested edits feature. Like I said, a comment or an alternative answer would be more appropriate.

If the fix is buried in a comment or lower answer, far fewer people will see it, especially on the ossified, highly-voted answers where it's often needed. Difficulty moderating proposed edits is a process problem, and comments aren't a good workaround.

The accepted answer is the answer selected by the questioner to fix its problem. OP is often not the most knowledgeable person is the room. The real work come from the answer. Show, explain and prove that you understand the problem before answering.

It is a good thing to test and to do more research, it is even better to add them to the post. Share your knowledge :)

> the more answers I see on an area I’m experienced in, the more I realize how wrong they can be

The fastest correct looking answers on SO are usually the accepted answers. I read an post or tweet a few years back suggesting that you have the quickest draw if you want SO rep: create a bare-bones answer, with no research, so that it gets accepted. I understand why: my answers have been on the receiving end of this - I spent way too much time and effort answering and my answer dropped into obscurity.

That's why I no longer answer on SO.

Why not add a fifth point about contribute with a better answer if you know better? It feels wrong looking down on people just trying to help.

This is the whole point of a community. Especially if you’re sure that the answer is slightly wrong, you can definitely fix it yourself, which is the best part of StackOverflow. There’s no point in even leaving a comment like “X should be X.Y”

Great point, this too. Also - if there’s a good answer already there but not accepted, it’s worth upvoting, so that hopefully it becomes more visible to others.

The problem is stackoverflow seems designed to avoid "better answers".

Questions are often long abandoned, and the original questioner won't come back and choose a new correct answer. On a rarely looked at question, it would take years for a correct answer to raise up the ranks.

I've seen various answers which used cryptography dangerously, and asked if there was any way they could be fixed, and I just got the answer you gave. That shouldn't be acceptable when dangerously bad code is being showed to people.

It's worth noting that it is possible to edit other people's answers. So it is possible to correct answers with incorrect or dangerous information.

With sufficient "rep" (2000, where an upvote on one of your questions or answers is worth 10), edits don't even require approval from others (before that, they must be peer reviewed before the edit takes effect)

Personally I find the "edit without peer review" too powerful, since you can do it for any question, regardless if you're supposed to be competent there or not; it would be better if it was limited for tags where you've got a bronze badge. Perhaps it's the lack of oversight which makes me a little wary. And 2000 rep isn't that hard to achieve, it just requires some persistence.

I believe the idea is that if you're editing questions early on you learn what the expectation for edits are. I reject a lot of edits in the system for being edits that should be submitted as their own answers or as comments to the post they're editing. Ideally, once a user has gone through the system for long enough and had enough edits rejected for improper use of the system they'll know what to do once they reach the higher rep threshhold.

In practice however???

---

The system works well for fast and easy. A system like StackOverflow will never work well for highly specialized tasks and that's alright.

When I asked: https://meta.stackoverflow.com/questions/276496/how-to-deal-...

I was explictly told "Inform and educate, don't censor!." -- which from context clearly means "don't edit answers just because they are wrong".

> The problem is stackoverflow seems designed to avoid "better answers".

SO is perfectly happy to accept better answers, especially to those which have gone stale and perhaps no longer applicable.

If you are offering further information that can benefit the reader its always welcome.

Its one of the reasons a lot of the more concise answers are not always the accepted answers. Because people do ask quite often : "Okay but why did that fix it"

In-fact : Answering without giving a proper reason for the solution is frowned upon mostly.

I've gotten multiple Tumbleweed badges for answering an old question with a better answer. You can't blame the system for the fact someone who either long ago fixed the problem or gave up doesn't come back to change the "correct" answer.

I can totally blame "the system", as it is exactly the system which doesn't make it easy for others to change the "correct" answer, when stackoverflow claims it isn't supposed to be a Q&A system for individual people, but for the community as a whole (hence why bad/repeated questions are deleted).

It suffers from a similar problem to Wikipedia, namely that the likelihood of your information being prominent is a function of how well you rules lawyer, rather than how good your information is.

- read a number of answers, comments included. Just because an answer is accepted doesn’t mean it’s the best one

Agreed. I find that the "accepted" answer usually gets refined/improved/made more generic after acceptance.

This usually means that the "best" solution over all similar problems is usually further down the list of answers.

Isn’t there a “law” that states the best way to get a correct answer is to post the wrong one first? I feel that should be in mind whenever reading through StackOverflow answers.

* * Cunningham’s law is the one I’m thinking of. https://meta.m.wikimedia.org/wiki/Cunningham%27s_Law

That is how I feel when doing code reviews of offshored projects, problem is, it doesn't scale so the code does the job and stays until something like this blows up.

The most important step in my opinion is: Check the date of the question and answer.

I've spent WAY too much time banging my head on the keyboard while trying to implement a solution posted 3-4 years ago, which doesn't apply in the slightest for the latest version of whatever I'm doing.

You must feel good that you have hours to fix things then. Unlike a large number of people here.

Reply on news.ycombinator.com