4 ms·

the article doesn't make sense to me when making decisions: "we should be asking which option will give us good-enough results under the widest range of futur

the article doesn't make sense to me when making decisions: "we should be asking which option will give us good-enough results under the widest range of future states of the world" doesn't that lead you right back to the struggle for the most efficient way to determine the optimal "good-enough" answer? Also, the article talks about efficiency but efficiency of what exactly? What if you're very efficient at a maintaining a relaxed and happy lifestyle?

Double_Cast 6y ago
Suppose you're playing a videogame. Your character just leveled up. You can upgrade either Attack or HP. * "Upgrade Attack" is more efficient. It allows you to beat the game faster. But since your HP is low, you can't afford to make mistakes (get hit). * "Upgrade HP" is more robust. It increases your damage-buffer, which allows you to absorb more mistakes without dying. But if you make zero mistakes, you won't beat the game as quickly as if you'd upgraded Attack. IRL the dichotomy is often "income vs wealth", "velocity vs displacement", "throughput vs latency", "strength vs endurance", etc.
zackmorris 6y ago
As it relates to hacking, I think of it as: clients can be fickle because they don't even know what they want sometimes. So I picture next steps as coalescing, like a wave collapsing. Uncertainty comes to dominate the process, so it works more like evolution than planning (stochastic vs deterministic). My problem solving algorithm is to look up to 7 steps ahead, along up to 7 different branches in the tree of possibilities (I'd like to examine more choices but my brain can't hold them all). In practice this is always at least 2 and 2, so this task or its alternative, and then looking at the next step along each branch. Then I prune the tree, selecting for the steps that work across as many branches as possible, without rewrites or duplication. I'm often working on a common dependency several steps out that other people aren't aware of yet. This could be thought of as a breadth-first search or parallel search. Unfortunately on an individual level, the tech industry seems to be going the opposite direction, exploring deeply down very long and linear branches of the tree. Coders are expected to implement an idea and be ready to scrap it without hesitation, iterating over and over again until finished, rather than simulating the outcome in their minds. More of a depth-first, serial search. I think the split is due to programming moving from an individual endeavor towards teams. We can't see inside each other's heads, so we plot the course and divvy up steps among the members. The cost of this is that serial searches will almost always turn up suboptimal results, because the resources to do broader searches get withheld so we miss elegant solutions and even perceive them as more costly. To answer your question, the serial approach works best for individual tasks, but misses the big-picture view that might have let us see that the task didn't need to be done in the first place. So my vote would be to see more quiet reflection and less spinning and churning. But I'm mostly outvoted, so it probably comes down to personality, with junior developers being more sought-after than senior developers like me who might be perceived as reserved/overcautious/conservative.

Double_Cast 6y ago

Suppose you're playing a videogame. Your character just leveled up. You can upgrade either Attack or HP. * "Upgrade Attack" is more efficient. It allows you to beat the game faster. But since your HP is low, you can't afford to make mistakes (get hit). * "Upgrade HP" is more robust. It increases your damage-buffer, which allows you to absorb more mistakes without dying. But if you make zero mistakes, you won't beat the game as quickly as if you'd upgraded Attack. IRL the dichotomy is often "income vs wealth", "velocity vs displacement", "throughput vs latency", "strength vs endurance", etc.

zackmorris 6y ago

As it relates to hacking, I think of it as: clients can be fickle because they don't even know what they want sometimes. So I picture next steps as coalescing, like a wave collapsing. Uncertainty comes to dominate the process, so it works more like evolution than planning (stochastic vs deterministic). My problem solving algorithm is to look up to 7 steps ahead, along up to 7 different branches in the tree of possibilities (I'd like to examine more choices but my brain can't hold them all). In practice this is always at least 2 and 2, so this task or its alternative, and then looking at the next step along each branch. Then I prune the tree, selecting for the steps that work across as many branches as possible, without rewrites or duplication. I'm often working on a common dependency several steps out that other people aren't aware of yet. This could be thought of as a breadth-first search or parallel search. Unfortunately on an individual level, the tech industry seems to be going the opposite direction, exploring deeply down very long and linear branches of the tree. Coders are expected to implement an idea and be ready to scrap it without hesitation, iterating over and over again until finished, rather than simulating the outcome in their minds. More of a depth-first, serial search. I think the split is due to programming moving from an individual endeavor towards teams. We can't see inside each other's heads, so we plot the course and divvy up steps among the members. The cost of this is that serial searches will almost always turn up suboptimal results, because the resources to do broader searches get withheld so we miss elegant solutions and even perceive them as more costly. To answer your question, the serial approach works best for individual tasks, but misses the big-picture view that might have let us see that the task didn't need to be done in the first place. So my vote would be to see more quiet reflection and less spinning and churning. But I'm mostly outvoted, so it probably comes down to personality, with junior developers being more sought-after than senior developers like me who might be perceived as reserved/overcautious/conservative.