Hacker News Reader

Hacker News

Comment by anjc | Hacker News Reader

Full thread

anjc

I love it when somebody immediately knows the answer to something seemingly obscure.

View on HN

Sometimes I think these guys know something obscure, and then post a question about it just to answer it themselves.

SO actually allows this, Q and A from the same account. Some people use sock-puppets though.

Not only is this allowed, it is encouraged.

Why would people use sock-puppets, I don't know. It seems that the SO team has special ways to detect voting frauds.

People use sock puppets to do this because although you're correct that it's with the SO guidelines, it feels a bit off, and not uncommon for it to get pushback from those who either don't agree with the guidelines or are not aware of them.

Also, while voting fraud is against the guidelines and actively countered, creating sock puppet accounts is not.

> Also, while voting fraud is against the guidelines and actively countered, creating sock puppet accounts is not.

You're right. For anyone interested here is the relevant post: http://meta.stackexchange.com/q/57682/297429

Doesn't that say that "Answering your own questions with the other account(s)" is one of the things that a sock puppet account should not be used for?

Yes, but the parent comment said "creating sock puppet accounts", which is okay because there might be legitimate uses.

You use a sock-puppet to ask the question, and your real account to answer it. Then you can look smart.

I've done the self-answer thing a couple of times. Sometimes you just know that someone is going to run into the same problem, but you'll never see the question, and you can preempt it.

Some of these have been absolute God sends for me.

You have a cross between misinterpreting what something means, on obscure hardware, with a useless error message and you are normally stuck for days.

If I resolve my question before someone else in the community I always self answer to help the next guy.

More than once I've solved the problem by the time I am 80% of the way through formulating a question. As long as it's not something trivial I finish and post the answer immediately.

I think I've posted on StackOverflow/ServerFault three times in my life. If I've hit the point where I'm posting, I'm desperate and I've probably already spent 8+ hours scouring Google and trying everything I can think of.

If I do end up figuring out a solution, I definitely post it, and I'm glad that SO allows this, otherwise there would still be no answer to some of these questions online... One of these issues previously only turned up a single bash mailing list post from a decade ago with no resolution. Now searching for a few relevant search terms turns up my answer/solution in the top few results for all of them.

I don't care about imaginary internet points, I just figured I'd help the next guy out.

Still if it helps others this is cool interesting thing.

Sometimes the act of writing out a question is enough to spur the right ideas to solve the problem. It's the same as whiteboarding or asking to use someone as a sounding board.

Also known as rubber duck debugging.

He must had a hard time figuring it out when he first encountered the problem..

Or he's written a terminal that had to figure out how to do that functionality and remembered how it worked.

According to the comments on TJ's post, this would be correct.

http://stackoverflow.com/questions/21947452/why-is-printing-...

> There are some answers that come from hard learned experience. T.J. and I (since we are friends) grew up in the days of the Apple ][ and the zx80/81. There was no built in word wrap back then. So we both ended up writing our own — more than once. And those lessons stick with you, they get burned in to your lizard brain. But if you leaned to code after that, when your environment word wraps everything, or you do it manually prior to runtime, it is harder to run into the issues with word wrap. – JockM

100% I am the guy who wrote that comment. Sometimes there are benefits to getting older ;)

I am amused when someone comes up with obscure problems. I am disappointed when that person doesn't brief about the scenario that led them to such a problem.

This is a great example of a "10x engineer". Someone less experienced would take 10x or 100x the time to investigate and resolve this problem.

No, it just means someone has encountered that particular problem in the past.

The 10X immediately knows the answer. The 100X immediately knows the answer, but asks "That is an interesting observation and I'd really like to know why too. But is writing 1 million characters to the console essential to the problem your solving?"

Indeed.

Then the 1000x engineer explains:

"You are confused because you do not understand Tao. Only a fool expects rational behavior from his fellow humans. Why do you expect it from a machine that humans have constructed? Computers simulate determinism; only Tao is perfect.

The rules of programming are transitory; only Tao is eternal. Therefore, you must contemplate Tao before you receive Enlightenment."

"But how will I know when I have received Enlightenment?" asks the 100x engineer.

"Your program will run correctly," replies the 1000x engineer.

Meanwhile, the 10kx engineer sits here on HN, doing nothing while requirements change again and again - waiting to implement the thing when the requirements finally settle.

It's really an example that we should teach people to use a sampling profiler. anyone can answer this question in a minute or so, no speculation necessary, if they just know what tool to use.

Except the insight of the answer is that the bottleneck is in a different program than suspected. Running the suspect program under a profiler wouldn't yield any answers.

Sure, anyone can find the answer if they already know where to look.

Running the suspect program would show blocked states; even without that, you would simply see no difference, conclude that the problem must lie elsewhere, and switch to looking at a full system profile.

FWIW, I always start with a full system profile including all thread states when debugging mysterious performance issues, precisely because "the problem is in another process" is such a common occurrence. This is also why it's important to use a sampling profiler specifically.

Reply on news.ycombinator.com