Programmer Hypotheticals

As a programmer, I try to always be reading questions and answers, and never writing them. The truth is that I would rather work around the lack of a good answer than deal with a particular type of conversation.

Since programmer-speak can verge on the arcanely obscene, I've taken the liberty of translating such an interaction into a different context, so that programmers and muggles alike may groan in unison.

Well, piano experts may find this annoying. It couldn't be helped.

I have a problem moving my piano.

The piano is a Funkenhauser K2 grand which was a gift from my late mother. I can't get it through our patio door without taking the legs off it and moving it at an angle, which I was warned not to do because the frame on this model is supposedly susceptible to warping. It doesn't look like I have any alternative. Is there any way to minimize the risk of damage?

Any advice would be appreciated.

Why would you want to move the piano outside? The humidity and temperature variation will destroy a wooden piano body, especially one that uses a more permeable lacquer like the factory finish on the Fünkenhauser K2.

I don't want to move it outside, exactly. We're moving out of our house (which was also a gift from my mother) into a new place, and for a lot of reasons I'd like the piano to come with us.

Well, just move it out however it got in there originally.

I would do that if I could, but the patio door was replaced at some point after she purchased the piano and the new opening is smaller. I'm just looking for a way to get it out of there with minimal damage to the house and piano.

You should never reduce the size of a doorway below the size required to move the item out of a room. Also, warping is a known issue with the K2 and you should avoid moving it at an angle.

You're right, of course, but that's the position I'm in now. Does anybody have any advice? (Anybody?)

If you intended to move it you shouldn't have reduced the size of the doorway. If there was a chance that you were going to reduce the size of the doorway and you might end up manhandling the piano, you shouldn't have purchased a model with a lightweight frame that can warp like the Fünkenhauser K2.

Does this seem exaggerated? Ridiculous? Only slightly. This hypothetical exchange demonstrates some of some of the worst of programmer hubris and self-deceit, which I shall call:

The Pillars of Unhelpful Assistance

  1. Conflating knowledge and intelligence. A person seeking the solution to an intractable problem is possibly in over his or her head, but that does not imply that he or she is an idiot. However, if you cannot think of a situation in which your intelligent self might ask an obvious question out of ignorance, you might be an idiot.

  2. Ignoring critical background information and constraints in your proposed solution. The solution to a lot of hypothetical programming problems is to remove some constraint. The question is often being asked in an attempt to locate the constraint of least resistance. If there is no good answer to the question, that's useful information. On the other hand, if you just can't tolerate being without an answer, go watch Jeopardy.

  3. Ignoring the requirements to reframe the problem as trivially solvable, or not a problem at all. Instead of changing the environment of the problem, you're changing the problem itself, so rather than solving the problem being asked, you're solving the problem you think should have been asked, or objecting to the fact that there is one. My observations suggest that most programmers who treat user requirements this way, get fired. On the other hand, a person receiving this response to a question in a public forum can only hope you go away. Unless user18399057 is actually your boss.

  4. Making the asker the problem. If you are such an expert that you would never find yourself in such a situation, and you have no useful answer, then the question wasn't for you. The question was intended for an expert who could get themselves out of such a situation anyway -- the kind of thing that is going to be expected of you at your next promotion.

I have seen these characteristics demonstrated by some of the most knowledgeable specialist programmers on the Internet. A specific, highly technical question, set against a background of "that's how I would do it too," gets a thorough, detailed, correct and utterly authoritative reply, and it is a privilege to read. Then you see another reply, from a bad day or a question that was "beneath" the respondent, and not only is it combative, unhelpful and a waste the asker's time to read, but a criminal misuse of the time of the expert replying, because that time could have been spent answering a better question, or finding a cloud that looks like Snoopy.

I think that these sort of bad answers are the response of an intelligent person to what he or she perceives as a deluge of bad questions. I understand the complaint, but in public fora like StackOverflow where such questions reign, there is no standard of service; no obligation for anyone to reply; no ticket queue to clear before Friday. If you do not like the question, there is nothing to be done. It's Darwinian -- those who can search or ask to get the information they need, survive to experience even greater ignorance in tougher challenges.

And so:

The Pillars of Helpful Unassistance

  1. If a question is beyond you, don't answer.
  2. If it's beneath you, don't answer.
  3. If you're having a bad day, don't answer.
  4. If it's unsolveable, answer that it's unsolveable as asked, and identify the limiting constraint for bonus marks...or just don't answer.

Questions and answers aren't for everyone. In my own case, it is well within my capability to ask a stupid question and give a demeaning, unhelpful reply on the very same day.

If this could be describing you, too, you can try my system: ask only Google, and channel any insufferable haughtiness into blogging.