Every so often, a developer forum erupts into war.
Python versus JavaScript, which is worse; whether Rust will replace C++; whether Arch Linux users understand Linux better than Ubuntu users; whether Vim or Emacs is the endgame of editors. The debate is fierce, the participants numerous, and the threads last far longer than any meaningful technical discussion. They routinely run to hundreds of posts, the rhetoric growing increasingly heated; each one ends with mutual blocking or a moderator locking the thread — only to start all over again in the next thread.
A bystander could easily conclude: these people are wasting their time.
But that conclusion is itself wrong. They are not discussing technology; technology is merely the vehicle. They are doing something much older: defending identity.
I call this phenomenon Techno-Tribalism.
It is not a runaway state of technical discussion but a stably functioning social structure: technology choices serve as totems, tool identification marks the boundaries, and tribes form with a strong in-group/out-group consciousness; when the tribe is threatened, that consciousness activates systematic defense mechanisms. Understanding it requires starting from the beginning.
Let’s begin with a thought experiment.
Suppose someone asks you: Python or Go, which is better?
A meaningful answer would require at least the following information: How large is the system? How big is the team, and what is the average skill level? What order of magnitude of performance are we talking about? How many years will this system need to be maintained, and by whom?
Without that information, “Python or Go, which is better” is an unanswerable question, because the question itself is incomplete. Comparing languages without any scenario constraints is like comparing two cars without knowing the road or the purpose of driving: what you are really comparing is the totem in the speaker’s head.
Yet the vast majority of language debates in technical communities erase every constraint from the outset and step straight into the arena of “which is better.”
This move is the precondition for Techno-Tribalism to operate.
Because once a concrete scenario is introduced, the discussion becomes conditional and the conclusion becomes relative — and relative conclusions cannot support identity. Identity requires unconditional correctness: my choice is good, and good under all circumstances. So the debate must take place in a vacuum. In a vacuum, victory can be pure, and the totem can be sacred.
Erasing the scenario is the first move of Techno-Tribalism.
II. Conclusion First, Evidence Later
The normal path of reasoning is: observe phenomena, analyze evidence, reach a conclusion.
The actual path of Techno-Tribalism is: I use Python; I identify with the Python community; Python is good; then go find evidence to prove it is good.
Cognitive science calls this motivated reasoning. The conclusion comes first; the evidence is decoration added afterward. Its function is not to discover the truth but to support a position already held.
This process is almost entirely unconscious. No one says to themselves, “I’ll decide Python is good first, and then go look for evidence.” They sincerely believe they are doing objective analysis. But if you watch closely how they handle counterexamples, a pattern emerges: any evidence that supports their position is accepted; anything that does not is explained away.
You bring out a benchmark, and they say the test scenario is wrong; you bring an engineering case, and they say the scale is different; you cite a paper, and they say academia is divorced from practice; you point out a known flaw, and they say that flaw never comes up in real use.
Each rebuttal, taken in isolation, has some merit. Benchmarks can indeed be designed; engineering cases do have context; academia is indeed at some distance from engineering. But when the same person applies these rebuttals systematically to any unfavorable evidence, they are not performing cognitive correction — they are performing cognitive defense.
More precisely: they are not looking for the truth; they are eliminating threats. And they do not know they are doing it.
Once a person has invested time, learning costs, career choices and social circles in something, that thing stops being merely a tool. It becomes part of their self-narrative. This process is gradual and unfolds in several stages.
The first stage is choice. You choose Python. At this stage it is still just a tool, and you know it has strengths and weaknesses.
The second stage is investment. You spend hundreds of hours learning, read a lot of documentation, write a lot of code, run into problems, solve them, and accumulate experience. You begin to feel capable of “getting things done with Python.”
The third stage is community. You join the Python community, get to know some people, take part in discussions, perhaps contribute code, and gain some standing there. You begin to feel like “a Python person.”
The fourth stage is fusion. At some point you are no longer “a person who uses Python” but “a Python developer.” The label has become one of the ways you describe yourself. The boundary between tool and self has blurred to the point of being indistinguishable.
By the fourth stage, criticizing Python becomes a criticism of you: you made the wrong choice, invested in the wrong direction, wasted time in the wrong community. This is no longer a technical discussion; it is a direct threat to your sense of self-worth.
I gave this process a formal name: Tool-Self Fusion — the cognitive boundary between the tool ( 器 ) and the self ( 我 ) disappears, the tool becomes an extension of the self, and an evaluation of the tool becomes equivalent to an evaluation of the self.
Path dependence plus sunk cost is the material foundation of tool-self fusion. The deeper the investment, the tighter the binding, and the higher the cost of loosening its grip. Someone who has used Vim for ten years finds it harder to accept “actually, an IDE is pretty good too” than someone who has used it for one year, because the former has invested more of themselves in that choice. Questioning the tool is questioning their judgment over the past ten years — and the person who made those judgments.
When individual tool-self fusions aggregate, a tribe forms.
The structure of a techno-tribe is closely isomorphic to that of any tribal structure in human history. It has a common totem — a language, a framework, a tool; an origin myth — “Linus created Linux in his spare time”; an in-group/out-group distinction — “real programmers use Vim”; an elite hierarchy — core contributors, evangelists, veteran users; initiation rites — a manual Arch Linux install, configuring Neovim from scratch; and heresy trials — “You’re still on Python 2?” “You use an ORM? That means you don’t understand databases.”
The function of this structure is to maintain group cohesion. The clearer the in-group/out-group distinction, the stronger the identification inside the group. So a techno-tribe needs heretics, needs enemies, needs a continuous external threat. Language holy wars are the tribe’s normal operating state. Without opposition there is no boundary; without a boundary there is no belonging.
The Linux distro community is an excellent case study for observing this structure, because its technical differences are small enough to be almost negligible. For the vast majority of use cases, the practical functional gap between Arch and Ubuntu is minuscule. Yet the identities formed around them have strikingly different cultural temperaments: Ubuntu is “for beginners,” Arch is “for people who really understand Linux.”
The core of Arch user identity is the ascetic narrative: I configured everything by hand, I understand every component, I didn’t rely on any defaults, I chose the hard path. This narrative serves a status function: by voluntarily taking on suffering, one buys an elite identity within the tribe.
This explains why the Arch community reacts so strongly to “I installed it with the archinstall script.” From a technical point of view, the result of installing with a script or by hand is exactly the same. But from a tribal point of view, using the script skips the initiation rite — it is like claiming to be an adult without having completed the coming-of-age ceremony. It is a transgression of the tribal boundary, and it must be corrected.
Techno-Tribalism has one property that makes it harder to see through than other forms of identity politics: it wears the cloak of rationality.
Sports fans know that their support for a team is emotional. When challenged, a fan will say, “I just like this team, so what?” That is a kind of honesty: they admit that what they are doing is emotional investment, not rational analysis.
When a techno-tribalist is challenged, what they say is, “You don’t understand technology.”
The difference is crucial. The fan’s response defines the nature of the discussion: this is emotional preference, and it needs no rational justification. The techno-tribalist’s response claims that this is a rational judgment, and that the other person simply lacks the capacity to understand it.
This claim can stand because the tech world has a deep-rooted self-conception: we are rational people, we let the data speak, we don’t get emotional like ordinary people. Programmers deal with rigorous logic and verifiable systems, and the profession itself reinforces a self-narrative of “I don’t make irrational mistakes.”
But this self-conception becomes the biggest blind spot.
There is a concept in cognitive science called identity-protective cognition: when information threatens self-conception, what the brain launches is not analysis but an immune response, as fast and automatic as the body’s transplant rejection response. The key is that this process happens below the level of consciousness. What the person experiences is not “I am defending myself” but “I am analyzing, and then I find that the other person’s argument has holes.”
The more someone believes they are rational, the weaker their defenses against this process. Because they will not question whether their conclusion comes from motivated reasoning — they are certain they do not have that problem. And that certainty is precisely what lets motivated reasoning operate more smoothly, more thoroughly, and with less chance of being interrupted from outside.
The result: some of the smartest people in tech are also some of the hardest to persuade rationally. The sharper the intellect, the stronger the capacity to construct a case for an existing conclusion, the more sophisticated the motivated reasoning, and the more it resembles genuine rational analysis. To outsiders, they really do seem to be reasoning. To themselves, they really are reasoning.
But they are not reasoning. They are defending themselves.
“I’ve eaten more salt than you’ve eaten rice.”
This line — a Chinese proverb — has countless variants in the tech world. “I’ve been developing for twenty years — I’ve seen this kind of thing far too many times.” “You’ve only used Python for two years; come back and talk to me when you’ve written a hundred thousand lines.” “That approach sounds great, but it simply won’t run in practice — I’ve been burned by it.”
On the surface, these words offer experience as a reference. In reality they are doing something entirely different: trading time invested for epistemic authority, then using that authority to end the conversation.
Its logical structure is: I have spent more time on this than you, therefore my judgment is more credible than yours, therefore you should accept my conclusion, therefore the discussion is over.
This structure has two fatal flaws.
The first is equating quantity of time with quality of cognition. Having eaten a lot of salt does not mean you understand salt. Having used C++ for twenty years may mean only that you spent twenty years repeating the same thought patterns. The accumulation of experience requires a precondition: that you actually reflected on your experience and corrected course along the way. Experience without reflection leads to deeper path dependence, not cognitive growth.
The second is assuming the direction of experience is correct. Twenty years of experience rests on certain assumptions; if those assumptions were flawed to begin with, then the more experience is built on them, the more entrenched the bias becomes and the harder it is to correct. Someone who has spent twenty years circling a local optimum may, on certain specific questions, genuinely be a worse judge than a newcomer who has thought through the underlying logic.
But neither flaw is the point.
The point is that “I’ve eaten more salt than you’ve eaten rice” is not an epistemic statement at all; it is a power statement. Its function is not to argue but to terminate. What it says is: this discussion ends here; my status is not open to question.
A line like this almost always appears precisely when the speaker can no longer defend their position on the merits. When the arguments run out, they switch to seniority. It is a signal that the discussion has failed, but it is packaged as an authoritative pronouncement. Recognizing this switch is one of the most reliable indicators of whether a conversation is still worth continuing.
Rust is one of the clearest examples of Techno-Tribalism in recent years, and deserves a separate dissection.
Rust itself is a language with real merits. Memory safety, zero-cost abstractions, a powerful type system, an excellent toolchain — these are verifiable technical properties. This must be said clearly at the outset, because the analysis of Techno-Tribalism does not depend on whether the totem itself has value. A genuinely valuable tool can just as easily become a tribal totem, and often, precisely because of its real merits, the myth is harder to see through.
Over the past few years the Rust community has made a leap: from “Rust is a valuable systems programming language” to “all future systems software should be rewritten in Rust,” and then to “not using Rust is making a mistake.”
This is a leap of pure faith.
Rust’s learning curve is steep, and the ownership system takes considerable time to truly master. This is inherently a property that calls for trade-offs, but in the Rust community’s narrative it has become an asset: precisely because it is hard, it proves the competence of those who use it. This is structurally identical to the ascetic narrative of Arch Linux: difficulty was converted into a source of status.
So “learning Rust is painful” became “learning Rust is a form of self-cultivation”; “I learned Rust” became “I am a better programmer”; “using Rust in a project” became “I am doing the right thing.” The tool became proof of character.
At the same time, the Rust community developed a full apparatus of heresy trials: using C++ is “playing with fire,” using Python is “not taking performance seriously,” using Go is “choosing mediocrity.” Anyone who criticizes Rust is by definition not making a technical point — they either “haven’t understood Rust’s value yet” or are “too afraid of change.”
The ingenuity of this narrative is that it is self-sealing: any criticism can be explained as the critic’s lack of ability or intellectual backwardness, rather than as a problem with the language itself. In philosophy, this structure is called an unfalsifiable proposition — no evidence can refute it, because every counterexample gets internalized as grounds for doubting the critic. In religion, this structure is called faith.
Rust is a good language. But the identity politics that has formed around it now has almost nothing to do with the language itself.
There is another kind of person worth discussing on their own.
They are not techno-tribalists in the usual sense, but whenever a constructive discussion appears, they surface, drop a single line — “So what? What would that change?” — and then leave.
This posture looks like sobriety, but it is actually another form of Techno-Tribalism, only the totem has changed from a concrete language to an abstract “having seen through it all.”
Most of them have gone through a recognizable trajectory: an early, intense desire to change things; then they hit a wall, became disillusioned, concluded that “nothing works,” and settled into that nihilistic position. Nihilism became a new identity: I am the one who has seen through everything; I am no longer deceived by any narrative.
This identity carries an internal demand: anything constructive that anyone proposes must be denied. Because if it worked, it would mean that giving up back then was not a matter of having no choice but an active choice. That is something they cannot accept.
So what they refute is not your argument but the very fact that you are still doing things in earnest. Your state of being poses a threat to them, because it reveals a possibility they closed with their own hands.
As with techno-tribalists, their defense mechanism is not argument but dissolution: whatever you say is useless, nothing can change, effort is childish, seriousness is ridiculous. This is another form of cognitive immune response, only with the direction reversed: defending the meta-position that “no totem is worth defending.”
This structure does not exist only in the tech world.
I chose the tech world as the entry point because it is easy to observe, not because the problem exists only here.
The same structure exists wherever human groups form identities. In political discussion, the intensity of the left-right divide has long since decoupled from the complexity of any specific policy. In food culture, the opposition between vegans and meat-eaters is completely out of proportion to the actual disputes in nutritional science. In education, the fight over exam-oriented versus holistic education is most often a fight over class identity, not over pedagogy.
The content does not matter; the structure is the same:
People need belonging. Belonging needs a totem. The totem is internalized as identity. When identity is challenged, defense mechanisms activate. The defense is packaged in the rational language of the relevant field. So it looks like a discussion of concrete problems in that field, when in fact it is a defense of territory.
The reason Techno-Tribalism makes this structure especially clear is that it has an explicit “rational person” self-narrative, and the tension between that narrative and its actual operation is unusually stark. Religious groups never claim to be fully rational; the irrationality of political groups can be openly acknowledged. But the tech world sincerely believes it is rationally discussing objective problems — which makes the contradiction between the structure and the self-narrative here the most undisguised, and the most worth dissecting.
One last question: what use is knowing this structure?
The first use is to stop wasting time. Once you recognize that the other person is in a state of identity defense, you know that continuing to supply arguments is pointless. What their brain is responding to is not your argument but a threat signal. Offering better evidence will only trigger a stronger defense; it will not produce cognitive updating.
The second use is to understand where persuasion actually happens. Genuine cognitive updating does not happen in public debate, does not happen when someone is backed into a corner, does not happen when the other side produces irrefutable evidence. It happens in private, when there is no audience, when a person sits alone thinking. Public debate can at best plant a seed, but a seed does not need an audience or an opponent to sprout; it needs quiet and time.
The third use, and the most fundamental: use it to examine yourself.
The structure described in this article is not a “them” problem. Everyone has totems in some domain, everyone has tool-self fusion to varying degrees, everyone has a threshold that triggers an immune response. The only differences are the degree of self-awareness and how much of one’s judgment this structure has taken over.
What does genuine technical judgment look like? It comes after the fact, is conditional, and is willing to revise its conclusions when the scenario changes. It does not need a language to always be good, does not need its own choices to always be right, does not need to confirm its self-worth by belittling other tools.
Recognition cannot eliminate this structure, but it changes how the structure operates: from unconscious autopilot to a process that can be observed, questioned, and selectively interrupted.
That is already the most meaningful thing one can do.
