npsimons

AFAICT, the noise is the point. The people with loud vehicles (and this includes the rattling bass and coffee can mufflers on low-end econoboxes) are selfish assholes, desperate for attention, often compensating for a failure in another part of their lives. "Loud pipes save lives" has zero data to back it up.

This is the sort of thing that tempts me - an enchanting vision, like something out of "Death on the Nile", only minus the death. Just a small floating hotel that takes you to interesting places, not a floating amusement park combined with buffet.

I have to ask, as someone into alpine touring and ski mountaineering (but not racing), what difference would backcountry skiing make to this advice? I imagine you'd need sharpening more often, due to twin factors of A) more rock and hard ice and B) really wanting that control on ungroomed (ie, icy) slopes at high angles.

I don't consider myself "really pushing it", but would like to have every ounce of control I can get when heading downhill. I'm enough of a beginner that I will often side-slip or even just hike completely down a slope I don't like the looks of.

As an amateur alpine tourist who is deathly afraid of that feeling of "loss of control" from incredible downhill speeds, this is exactly what I do.

That said, I'm here reading because I want to know if the heuristic for sharpening changes when A) one is mostly off-piste (rock, hard ice, etc) and B) really want those edges sharp for ungroomed (ie, icy) slopes.

I mean, everyone dies. Not that I'm elevating Mt. Everest climbers, but at least they're aspiring for something.

Now, if the message you're trying to get across is it takes more than motivation, and life is rife with failure, that I can get behind. But "don't try, there's no point" is the laziest, most self-serving twaddle ever to be uttered (and no, it's not Nihilism either).

"Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to one instruction which doesn't work."

Too true! I find it helps if I think of it as an engineering problem: "what can I say that will make these people not commit the same error again?" A bit dehumanizing and manipulative, but can be super effective at shifting away from blaming and belittling (almost never works), and towards mentoring.

Always, always assume this is the case - it might frustrate you to no end, but until you have conclusive evidence something is "wrong", it's best to ignore it and toodle along with whatever you're supposed to be working on (I always encounter these head scratchers when working on legacy code, my tasking being something unrelated).