Hacker News Reader

> I am unable to count the number of times I've gone to some random project community for assistance dealing with whatever problem I was having at the time to be met with someone telling me that what I'm doing is insane and shouldn't be done in the first place.

There should be an explicit three-way breakdown for this:

1. You're having trouble because of a bug, either yours or ours. If it's yours, the helpful thing is to help you fix it. If it's ours, obviously all projects should accept bug reports gracefully and work on them in some kind of reasonable fashion.

2. You've hit a deliberate design limitation, which isn't a bug as far as we're concerned, but we're willing to acknowledge it's annoying. This might turn into a feature request.

3. This is out-of-scope for our project. You picked the wrong tool. Getting us to change scope probably isn't going to be done using a bug report. That should be stated politely and without denigrating you or your problem.

What should not happen is what you describe: Developers fitting problems into a Procrustean bed and cutting off the bits which don't fit the pre-designed mold, and then claiming that this cut-down problem is all anyone would ever need to solve. It's sometimes inevitable that you have to simplify the solution by simplifying the problem, but never pretend that a solution thus simplified is complete.

Well, on the flip side - I've had similar experiences to cosban's, and it usually goes like this: I'm neck-deep in a complicated scenario, and I'm stuck and can't figure out what to do next. I can ask for help, but it will take pages of explanation just to describe how I got where I am. Recognizing that everybody's (myself included) attention span only goes so far, I try to describe just the problem I've run into in as few words as possible without going through the whole epic story. Then somebody comes along and says "what you're doing doesn't make any sense, you shouldn't be doing that"...

Many questions come from beginners - and they are often trying to do the wrong thing. The developer who is answering you don't know who you are nor what you tried before, it makes sense for them to eliminate most common scenarios first before advising on something complicated.

It is not necessary personal nor lack of good intention, it is that experience with answering questions teaches you that it is overall most effective to check whether the problem can be solved differently as it often can be done.

I mostly work on audio and video codec projects. You would not believe the number of people in this domain who come to us trying to do something insane that shouldn't be done in the first place. Of course, telling them that and dismissing them isn't helpful. But pretty much all you can do is ask, "Why are you trying to do that?" and work backwards. With luck you can set them back on the path towards success.

But a lot of people don't want to explain themselves or their reasoning, or get defensive when you imply that the time they just sunk into the approach they were taking was wasted.

It's helpful to remember that the people who have been working on a project for years might (but not always!) have a better perspective than someone who picked it up this week. If we're asking you "why", it's because we really are trying to help.

We're especially interested in figuring out how we can avoid leading other people down the path you went down (whether it's better documentation, or something else that would help). Because for every one who comes to us trying to do something insane, there's probably a hundred who are doing insane things and not telling us.

So then say "Do x, y, and z. But this is usually the wrong approach. Tell me what you're trying to do."

Don't be their babysitter. There's nothing more infuriating than "I know how, but I'm not going to tell you for your own good."

> So then say "Do x, y, and z. But this is usually the wrong approach. Tell me what you're trying to do."

And never hear from them again, but later hit the shitty code you have just helped to producfe.

If we continue a bit further down that path we come to:

Well, you never know if they're skilled or unskilled hackers, but they're probably not very skilled. Or at the least not as skilled as I am. So no matter what you tell them, they're probably going to write shitty code I helped produce. Even if they have some skill, why take that risk?

So it's better to not bother even with the initial "Why do you want to do that?" gatekeeping and to just ignore questions entirely. They're just going to screw it up anyway.

> when I deal with open source […] there is always a retort by someone saying the help is free and that I should be grateful.

I'm never bothered just because some particular OSS project sucks (after all, they are free). Rather, it's the fact that I've been suckered into using a sucky project – by network effects or false claims – that grinds my gears.