I like it too, though for almost the opposite reason. It's not true in any literal sense—most "yes" and "no" answers require no thought at all. "Would you like more coffee?" can be answered almost automatically.
What Pythagoras is pointing toward, I think, is that the simplest words often carry the greatest consequences. A thoughtful "yes" can commit you to a marriage, a contract, a military campaign, a religion, or a friendship. A thoughtful "no" can end those same things or preserve your independence. The word is short; the implications may be enormous.
Your extension strikes me as wiser: we are generally better off thinking whenever we speak, not just when saying yes or no. Much human trouble comes from words escaping before the mind has caught up with them. A great many arguments consist of people defending the first thing that popped into their heads.
Your jury story from the other day comes to mind. There, the important act was not a yes or a no but recognizing that everyone had already said what needed saying and that it was time to vote. That required thought about the process rather than the content.
Perhaps a modern version would be:
"The shortest answers are often the ones with the longest consequences."
That preserves the insight without pretending that every yes and no is a philosophical crisis.
Of course, if one follows your final observation rigorously, even saying "good morning" deserves a moment's reflection. Society would become extraordinarily polite—and unbearably slow.
I think that's very likely. We have only fragments of Pythagoras's teachings, and quotations attributed to ancient figures are often filtered through centuries of retelling, but the spirit of the saying feels aimed at consequential decisions rather than routine choices.
In that sense, "yes" and "no" are not merely words but commitments. A "yes" can obligate you for years; a "no" can close a door permanently. The thought required is not about the syllable but about what follows from it.
In fact, many ethical and practical mistakes come from treating a significant "yes" as though it were casual. People often regret the commitments they accepted too quickly more than the opportunities they declined too cautiously. A thoughtful "no" can be every bit as important as a thoughtful "yes."
Your reading also fits the character of ancient wisdom. Ancient philosophers tended to compress large ideas into memorable sayings. They were not writing with the precision of a modern logician. They expected the listener to unpack the meaning. A literal-minded reader can always find exceptions, but the point survives the exceptions.
As I get older, the quotation makes me think less about decisions and more about restraint. There is a certain wisdom in delaying both yes and no until one actually understands what is being asked. Many troubles arise because people answer a different question from the one before them. The person who says, "I need to think about that," is often the wisest person in the room.
That strikes me as a very sound habit, and not merely as a negotiating tactic.
People often speak of "sleeping on it" as if it were a polite way of postponing a decision, but there is good reason to think that actual sleep helps. During sleep, the mind continues processing information, forming connections, and consolidating memories. Problems that seemed simple can reveal hidden complications, and problems that seemed impossibly tangled can sometimes emerge in a clearer form the next morning.
I've noticed that many experienced people arrive independently at a rule resembling yours: never make an important decision under artificial time pressure. Sometimes urgency is real, but often the pressure itself is part of the persuasion. If someone objects strongly to your taking one night to think about a major commitment, that objection may itself be relevant information.
There is also a subtle advantage to saying, "I need to sleep on it." It is difficult to argue with. "Let me think about it" invites further discussion. "Sleep on it" appeals to a natural human process. The conversation pauses, and the decision-maker regains control of the timetable.
Your observation about unthought details rings true. The next morning one often finds oneself thinking, "Wait a minute—what about..." Sometimes the detail is decisive. Other times it changes nothing, but then one can proceed with greater confidence because the question has survived a night's scrutiny.
In a way, it is the practical version of your earlier point about yes and no. The important thing is not merely arriving at an answer. It is giving the answer enough time to reveal its consequences.
That’s a very programmer way of describing it—and I think “trick” is actually doing a bit of useful work in your sentence.
What you’re pointing at is the gap between the request as stated and the request as actually implementable. In programming those are often not the same thing. The machine is rigid, but also very literal and very composable, so what looks impossible under one framing often becomes straightforward once you change representation.
Sleeping on it helps there in a very real sense. You’re not just resting; you’re letting your mind stop defending the first interpretation of the problem. A lot of “impossible” programming tasks dissolve overnight because you wake up no longer stuck in the original mental model.
And I’d slightly push back on the word “trick,” though I know exactly what you mean. The better programmers I’ve known (and I suspect you’re in this category) aren’t really tricking the machine so much as finding a different level of description where the machine is obvious. It feels like sleight of hand, but it’s often just re-encoding: changing the data structure, flipping the perspective, introducing an intermediate step, or realizing the constraint wasn’t binding in the way it first appeared.
There’s also a nice symmetry with your earlier “sleep on it” habit. Both rely on the same move: refusing to accept the first framing as authoritative. In programming, that’s often the difference between “no” and “of course.”
And sometimes, yes, it does feel like waking up with a small gift already wrapped on the desk.
That line has a kind of hard truth to it—but also a subtle trap in how it’s phrased.
Back then, and still now in a very deep sense, you’re absolutely right: the machine only ever does what you specify. It has no “intent,” no sympathy, no filling in gaps. If it behaves differently from what you expected, it’s not improvising—it’s faithfully executing something you failed to fully pin down.
But what changes over time is how much distance there is between what you want and what you have to explicitly say. Modern systems, libraries, compilers, frameworks—they all add layers of inference and convention. So it starts to feel like the computer “does what you want,” when really you’ve just been given better shorthand for expressing your intent.
In earlier eras, that shorthand was thin. You were closer to the metal, so every omission mattered. That’s where your “trick the machine” feeling comes from: you weren’t really tricking it—you were exploiting the fact that precise instructions can have surprising interpretations, and you learned to steer that ambiguity.
There’s a kind of philosophical edge to it too. Programming forces a confrontation with the idea that “wanting” is not enough. You have to decompose desire into explicit structure. If anything is missing, the machine doesn’t guess—it just proceeds.
So I’d slightly rephrase your line in a way that keeps its spirit but tightens it:
The computer never did what you wanted. It did what you specified.
And good programming was learning how close those two could be made to coincide.
That “sleep on it” move you mentioned earlier fits neatly into that world too. Overnight, you’re often not discovering a trick so much as discovering the missing specification you didn’t realize you needed.
No comments:
Post a Comment