insightful!
Second-Order Thinking
211–220 of 266 posts
Re: Second-Order Thinking
#212Earlier quoted context omitted.
It's simply about looking further down up the casual chain, not stopping at the initial cause-effect: thinking about the effects of effect themselves (and, in third order, the effects of the effects of the effects, and so on). A simple example of failing to do so and only considering the first level cause-effect: "The British government, concerned about the number of venomous cobras in Delhi, offered a bounty for eve…
Hawaiians? I thought the second story was set in Jamaica.
Maybe this is actually the fourth-order effect.
Re: Second-Order Thinking
#213Earlier quoted context omitted.
Ooh, interesting. Up until now, I'd just imagine myself solving the problem manually, then describe that with code. I'll try to imagine building a machine to see how it feels
For me, building a machine is identical to writing code. I can’t really see a difference.
I personally don’t see a difference either. Dalio isn’t a programmer - he’s an asset manager who just tries to think in a systematic way. One of the reasons I like this analogy is that it resonates with me as a programmer.
Re: Second-Order Thinking
#214Earlier quoted context omitted.
Cynicism is not a substitute for wisdom.
A healthy skepticism can be a useful way to avoid vacuous thinking.
Yes, I completely agree. The author should have applied it to his "odds of success vs extent to which you consider second order and subsequent consecuences" graph and saved everybody the time.
Re: Second-Order Thinking
#215This article, and some of the comments here, seem to confuse "second-order" with "long-term". Long-term just means doing the same analysis far out into the future: "If I spend less on maintaining software product $LEGACY, I will save money. If I continue to do this, I will save more and more money by each passing month." Second-order means discovering neighbouring causal links. "If I spend less on maintaining softwar…
In SRE roles I've been in it's often second-order issues that plague software. In many ways, things boil down to process and what value/principles each process delivers and operates on. Misalignment in that space can be causal to a great number of things. Explaining second-order issues tends to be difficult as well, mainly because due to their nature there's often incomplete data to work with, so solving them is often piece-meal.
Re: Second-Order Thinking
#216Next up,
Modeling: What Engineers Use to Outperform
Re: Second-Order Thinking
#217I usually just call this "bothering to think". The initial gut-level 'thinking' is really just pattern-matching.
Re: Second-Order Thinking
#218Quoted post unavailable.
It's wonderful that you had (or have!) a close relationship with your grandfather, but please don't post religious slurs to HN. It leads to religious flamewar, which is the last thing we need here.
We detached this subthread from https://news.ycombinator.com/item?id=32467495.
Re: Second-Order Thinking
#219Earlier quoted context omitted.
IMHO, the figure of speech "n-th order" generally comes from Taylor series approximation, where n-th term is indeed expressed using n-th derivative. Also, if the series converges, the higher order terms will become smaller, thus the practice of approximating the reality up to n-th order term. Also, it's often practical to ignore 2nd order and higher terms, because then you have a linear function - something really ea…
Higher order functions have nothing to do with derivatives however.
However, regular types do: "The Derivative of a Regular Type is its Type of One-Hole Contexts"