Often I'd spent a morning reviewing a Python codebase, then switched to a Java project after lunch. Same problem domain, similar scale, but stepping into that Java code felt like walking into a different office. The naming conventions, the abstractions, the way responsibilities were carved up. Everything signaled a different set of values about what "good" looks like. By the end of the day, I realized I hadn't just been switching syntax. I'd been switching how I thought.
Michael Morris, in his book Tribal, describes the same pattern in natural languages. Bilingual people don't just switch words when they change languages. They switch everything. Mannerisms, gestures, personality traits shift depending on which language they're speaking.
Morris's own research makes this concrete. In one study, Hongkongers made different decisions depending on which language they were questioned in: they favored compromise more when speaking Chinese than when speaking English, even though the situation was identical. The language acts as a cultural cue. Without conscious effort, the person becomes a different version of themselves.
I know this pattern from my own life. I grew up speaking Spanish in Colombia, and I've spent most of my adult life working in English across Europe. When I'm back home speaking Spanish, my mannerisms change, my humor changes, the way I build sentences changes, even my pitch. Spanish feels like a more emotional language to me, warmer and more expressive. English feels more structured, more academic. I don't decide to be different in each language. It just happens.
When Morris described this phenomenon, I recognized it. And then I started wondering whether the same thing happens with my other set of languages.
Morris's research covers natural languages and cultural frames, not programming. But the parallels feel too strong to ignore, and the patterns I've observed over 15 years line up in ways worth exploring.
I've been a polyglot in programming languages for most of my career. Python, Java, JavaScript, and whatever else the project demanded. When I write Python, I don't just change syntax. I change what I consider elegant, how I approach the problem, and what community I feel part of. Switch to Java, and a different set of conventions, values, and expectations kicks in. A different tribe.
More than syntax
Every programming language comes with an invisible cultural package. It's not written in any documentation, but everyone in the community absorbs it.
Python's culture values readability and simplicity. "There should be one, and preferably only one, obvious way to do it." That's not a style guide preference; it's a philosophical statement about how software should be built. The community gravitates toward scripts, data science, and quick prototyping. The cultural expectation is that your code should be approachable, almost conversational.
Java's culture values structure and explicitness. Enterprise patterns, verbose naming, clear type hierarchies. The community expects robustness, testability, and code that can be maintained by large teams over many years. What a Python developer calls "boilerplate," a Java developer calls "clarity."
Choosing a language means stepping into a community with its own norms, its own heroes, its own traditions. You're joining a tribe.
The signals underneath the syntax
Morris identifies three instincts that govern tribal behavior: the peer instinct (follow what most people do), the hero instinct (emulate what admired people do), and the ancestor instinct (preserve what has always been done). His framework covers human cultures, not programming. But once I started looking for these patterns in technology communities, I kept finding them.
"Everyone's using React" is a prevalence signal. It carries weight that has nothing to do with React's technical merits. I've sat in technology selection meetings where the strongest argument wasn't performance benchmarks or developer experience; it was "this is what the industry is converging on." When a technology becomes widespread, adopting it feels safe. Resisting it feels like swimming upstream.
When a respected principal engineer at your company advocates for Go, that's a prestige signal. The broader tech world runs on this too: DHH shaped an entire generation's approach to web development through Rails, not through the framework's features, but through his personality, his opinions, his vibe. People didn't just adopt Rails. They adopted a worldview.
And "we're a Java shop" is one of the most powerful precedent signals in technology decision-making. It's about identity, continuity, and the accumulated investment (emotional as much as technical) in a particular way of doing things. Proposing a switch challenges the tribe's sense of who they are.
Why technology debates get so heated
This lens might explain why developers argue about programming languages with the intensity of people arguing about religion or politics.
If language choice were rational, these debates would be boring. You'd compare benchmarks, ecosystem maturity, hiring pools, and make a decision. But that's not what happens. People get passionate. They get defensive. They take it personally when someone criticizes their preferred stack.
When someone criticizes your programming language, they're questioning your tribe. They're challenging the prevalence signals you've relied on ("everyone uses this"), the prestige figures you admire ("the best engineers choose this"), and the traditions you've built your career around ("I've always done it this way"). All three instincts respond at once, and the reaction feels visceral because, in a psychological sense, it is.
I've been on both sides. I've argued for technologies with more passion than the technical merits warranted. I've dismissed alternatives without a fair hearing. Looking back, I can see the tribal instincts at work. The technology I'd invested years in wasn't a tool I knew well. It was part of how I saw myself.
Choosing technologies with tribal awareness
I'm not saying we should ignore tribal dynamics when making technology decisions. That would be like telling people to ignore gravity. These instincts exist for good reasons: they help communities coordinate, maintain standards, and accumulate knowledge over time.
But being aware of them changes the conversation, especially when a team is deciding between sticking with a known technology or trying something new.
Staying with a known stack reinforces the existing tribe: the hiring pipeline you've built, the community knowledge your team has accumulated, the cultural norms around code quality that developed over years. There's real value in that continuity. Sometimes "we know how to build well in this language" is the strongest argument you have.
Adopting a new technology imports a different tribe's values. Over time, that reshapes your organization in ways that go beyond the codebase. A team that adopts Rust starts thinking differently about ownership and safety. A team that moves to TypeScript inherits a culture of type-driven design. A team that picks up Elixir absorbs patterns around concurrency and fault tolerance. These are cultural tradeoffs that influence how your team thinks, what kind of engineers you attract, and what your organization values.
The question isn't just "which technology is better for this problem?" It's also "what kind of team and culture are we building, and which technology's tribal dynamics support that direction?"
When your team debates whether to adopt a new framework, try separating the tribal signals from the technical ones. Is the resistance to change driven by legitimate technical concerns, or by the ancestor instinct protecting "how we've always done it"? Is the enthusiasm for the new thing driven by genuine advantages, or by prevalence signals from conference talks and blog posts? Is the preference based on evaluation, or on which tech heroes endorsed it?
You won't eliminate the tribal element from technology decisions. But you can name it when you see it, and use it deliberately rather than being carried by it without noticing.
The frame that comes with the language
Morris's research covers human cultures, not GitHub repositories. But if switching from Chinese to English changes how people approach compromise, switching from Python to Java changing how engineers approach problem decomposition doesn't feel like a stretch. His insight about bilingual code-switching captures something I've felt but never had words for. When I switch programming languages, I shift into a different way of thinking, a different set of values, a different community's expectations. I change frames, and something that looks a lot like tribal instincts fills in the rest.
The next time you find yourself in a heated technology debate, or resistant to learning a new language, or loyal to a framework you haven't used in years, ask yourself: is this a technical judgment, or is your tribe talking? Sometimes it's both. Knowing the difference is what matters.