3 ms·

> As an avid endurance runner, I am very familiar with the importance of good pacing, and the perils of doing it poorly. If you go out too hard in a race, you a

> As an avid endurance runner, I am very familiar with the importance of good pacing, and the perils of doing it poorly. If you go out too hard in a race, you are destined to crash and burn. On the other hand, if you start too slow, you may have too much time to make up before the end of the race. At every moment throughout a run, you need to be in-tune with your body, understanding the limits of how hard you can push given your current position in the race. I know it's not a popular opinion, but I hate sport metaphors for business. They make no sense even with tiniest scrutiny. Isn't endurance running as mean of transportation completely disrupted by bicycle, cars, or public transportation? Wouldn't endurance running even with perfect pace actually kill you if you don't stop?

swatcoder 3y ago
What do you mean by disrupted here? And don't you have to stop riding a bicycle or driving a car eventually too? Endurance racing, which is what they're actually talking about as they care about "making time", is a sport that also appears almost identically in cycling and driving. And in all those contexts it's just an elective hobby that helps paint a picture about pacing, goals, and burnout. It's not about transportation at all. But as far as running goes for transportation, it's 500,000 year old technique that ultimately requires no manufacturing or contraptions and runs on foraged berries. Other options may creep into use for a millenia or two, but it's not going anywhere.
pflenker 3y ago
A metaphor aims to illustrate a specific point better. It does not aim to be a full equivalent of the thing itself. This does not only apply to sports metaphors. Sports metaphors are common because the are usually easy to grasp. And I think in this specific case it makes a ton of things to not pick any metaphor, but an endurance run as opposed to … a sprint, which is currently THE most common (albeit only implicitly used)sports metaphor in the software engineering industry.
- pflenker 3y ago
  *sense, not things.
082349872349872 3y ago
Once upon a time, while hiking, an elderly fellow shared his three rules for multi-day hikes: - look backwards from time to time (so you'll know from where you came in case it's necessary to backtrack) - know where you think you should be after X hours hike, and compare your actual surroundings to ensure they match sufficiently with the deduced location - if you do get lost, never leave your drainage (when things are going poorly, don't make them worse) We later learned he was a program manager for the https://en.wikipedia.org/wiki/Rockwell_X-30 https://en.wikipedia.org/wiki/Rockwell_X-30 , and not only did we use all three rules literally when got lost about half a week later, I've used them metaphorically on all manner of software projects since.
- jakelazaroff 3y ago
  Could you elaborate? I'm not sure what it means to apply these to software development (at least, 1 and 3). Also, what does drainage mean in this context?
  - Jtsummers 3y ago
    Retrospection, orientation, and I'll re-phrase the last one as "maybe stop digging that hole before it's so deep you can't climb out." (I'm guessing on that last one, not heard drainage used that way either.) Retrospection: Periodically examine what you've made and how, identifying the good, the bad, and the ugly. Try to structure your future work to produce more of the good and less of the bad and ugly. Orientation: Periodically check to see if you're making what you meant to make, is what the customer wanted you to make, and is still what the customer wants you to make. "Stop digging": Ok, you have a bit of code that's almost right, but it fails some tests. Add an extra conditional here, copy/paste a function there, change a constant in the copied code, voila problem solved. Oh, failing another test, let's repeat, and repeat. In the end you have 10x (or more) the necessary code and anyone looking at it would, rightfully, mock you for copying a 10 line function multiple times to make "render_with_black_background", "render_with_blue_background", "render_with_green_background", etc. when you, maybe, could have made it a parameter (with a default value) instead. It's related to the previous two in the sense that if you're actually retrospecting and periodically orienting, you probably won't dig the hole too deep.
dasil003 3y ago
Any metaphor can have holes poked in it. Same as all narrative are reductive and leave out innumerable salient facts. The map is not the territory. It doesn't mean analogies aren't useful. As a cross-country mountain biker and long-time software engineer, there is a hell of a lot of analogues between mental and physical endurance even if the activities are completely different.

swatcoder 3y ago

What do you mean by disrupted here? And don't you have to stop riding a bicycle or driving a car eventually too? Endurance racing, which is what they're actually talking about as they care about "making time", is a sport that also appears almost identically in cycling and driving. And in all those contexts it's just an elective hobby that helps paint a picture about pacing, goals, and burnout. It's not about transportation at all. But as far as running goes for transportation, it's 500,000 year old technique that ultimately requires no manufacturing or contraptions and runs on foraged berries. Other options may creep into use for a millenia or two, but it's not going anywhere.

pflenker 3y ago

A metaphor aims to illustrate a specific point better. It does not aim to be a full equivalent of the thing itself. This does not only apply to sports metaphors. Sports metaphors are common because the are usually easy to grasp. And I think in this specific case it makes a ton of things to not pick any metaphor, but an endurance run as opposed to … a sprint, which is currently THE most common (albeit only implicitly used)sports metaphor in the software engineering industry.

pflenker 3y ago
*sense, not things.

082349872349872 3y ago

Once upon a time, while hiking, an elderly fellow shared his three rules for multi-day hikes: - look backwards from time to time (so you'll know from where you came in case it's necessary to backtrack) - know where you think you should be after X hours hike, and compare your actual surroundings to ensure they match sufficiently with the deduced location - if you do get lost, never leave your drainage (when things are going poorly, don't make them worse) We later learned he was a program manager for the https://en.wikipedia.org/wiki/Rockwell_X-30 https://en.wikipedia.org/wiki/Rockwell_X-30 , and not only did we use all three rules literally when got lost about half a week later, I've used them metaphorically on all manner of software projects since.

jakelazaroff 3y ago
Could you elaborate? I'm not sure what it means to apply these to software development (at least, 1 and 3). Also, what does drainage mean in this context?
- Jtsummers 3y ago
  Retrospection, orientation, and I'll re-phrase the last one as "maybe stop digging that hole before it's so deep you can't climb out." (I'm guessing on that last one, not heard drainage used that way either.) Retrospection: Periodically examine what you've made and how, identifying the good, the bad, and the ugly. Try to structure your future work to produce more of the good and less of the bad and ugly. Orientation: Periodically check to see if you're making what you meant to make, is what the customer wanted you to make, and is still what the customer wants you to make. "Stop digging": Ok, you have a bit of code that's almost right, but it fails some tests. Add an extra conditional here, copy/paste a function there, change a constant in the copied code, voila problem solved. Oh, failing another test, let's repeat, and repeat. In the end you have 10x (or more) the necessary code and anyone looking at it would, rightfully, mock you for copying a 10 line function multiple times to make "render_with_black_background", "render_with_blue_background", "render_with_green_background", etc. when you, maybe, could have made it a parameter (with a default value) instead. It's related to the previous two in the sense that if you're actually retrospecting and periodically orienting, you probably won't dig the hole too deep.

dasil003 3y ago

Any metaphor can have holes poked in it. Same as all narrative are reductive and leave out innumerable salient facts. The map is not the territory. It doesn't mean analogies aren't useful. As a cross-country mountain biker and long-time software engineer, there is a hell of a lot of analogues between mental and physical endurance even if the activities are completely different.