Chapter 4: Your Stack Is Not a Personality
You have opinions about tabs vs. spaces, and that’s fine. But when you find yourself genuinely upset that someone on the internet called your language “mid,” it might be time to ask what’s really going on.
Let’s talk about something you’ve probably noticed but haven’t named: developers have stereotypes. Not just about technologies — about the people who use those technologies.
The Python developer is pragmatic, maybe a little academic, probably does data science or scripting. The JavaScript developer is fast-moving, maybe a bit sloppy, lives in the browser and wouldn’t know a type system if it bit them. The Rust developer is meticulous, slightly evangelical, thinks about memory in their sleep. The Go developer values simplicity, maybe a little too much, writes a lot of if-err-not-nil. The Haskell developer is brilliant but impractical, writes code that looks like math homework, is definitely judging you.
You’re smiling, or maybe wincing, because you recognize these. They’re in the jokes, the memes, the conference hallway conversations. And they’re mostly harmless — until they’re not. Until you start to actually believe that your choice of programming language says something fundamental about who you are as a person. Until the stereotype becomes a self-concept.
When Tools Become Traits
Personality is supposed to be the relatively stable set of characteristics that define how you engage with the world. Your disposition, your values, your habitual patterns of thought and feeling. It’s the deep stuff. The stuff that doesn’t change when you change jobs or move to a new city.
Your technology stack is not that. Your stack is a set of tools you happen to be using right now, shaped by a combination of circumstance, job market dynamics, historical accident, and genuine preference. It’s real, and it matters, but it’s not the same thing as who you are.
And yet.
When developers describe themselves, the stack and the personality often merge into a single thing. “I’m the kind of developer who…” followed by a technology preference, as if the preference reveals something deep about character. “I’m a systems person” doesn’t just mean you work on systems software. It means you’re a certain kind of thinker — careful, precise, interested in what happens close to the metal. “I’m a frontend person” doesn’t just mean you write CSS. It means you care about users, about visual experience, about the part of software that humans actually touch.
These associations aren’t always wrong. People who choose systems programming often are methodical. People who choose frontend work often do care deeply about user experience. But the causation runs in both directions, and sometimes it runs in neither direction. Sometimes you’re doing systems programming because that’s what the job was, and you’ve been doing it long enough that you’ve incorporated “systems person” into your identity even though you’d be equally happy doing something else if you gave yourself permission to try.
The Personality Test You Didn’t Take
Here’s an uncomfortable exercise. Think about the last time you met a developer who uses a very different stack from you. What assumptions did you make?
If they said they’re a PHP developer, did you assume something about their level of sophistication? If they said they write Scala, did you assume something about their personality? If they said they’re a WordPress developer, did something shift in how you saw their technical credibility?
Be honest. We all do this. We all carry a mental model that maps technologies to personality types, and we use that model constantly — in hiring, in team formation, in casual conversation. It’s a cognitive shortcut, the same kind of shortcut humans use for everything from first impressions to restaurant choices.
The problem isn’t having these mental models. The problem is that they’re self-reinforcing. When you believe that “Ruby developers are X kind of person,” you tend to notice the Ruby developers who confirm the stereotype and ignore the ones who don’t. And when you’ve identified as a Ruby developer yourself, you tend to unconsciously emphasize the traits that match the stereotype, because fitting the mold feels like belonging.
So the stereotype shapes the community, and the community shapes the stereotype, and after a few years it’s impossible to tell whether Ruby developers are actually more of a certain disposition or whether they’ve just been performing that disposition because the community rewards it.
The Flattering Mirror
Here’s the really subtle part: the stereotypes that attach to your stack are usually flattering. Or at least, they’re flattering from the inside.
If you’re a Rust developer, the stereotype says you’re rigorous and principled. If you’re a Python developer, you’re pragmatic and productive. If you’re a functional programming enthusiast, you’re sophisticated and mathematically minded. These are nice things to believe about yourself. And the stack gives you a pre-packaged way to believe them.
This is part of why stack identity is so sticky. It’s not just a label — it’s a compliment. “I’m a Rust developer” doesn’t just mean “I use Rust.” It means “I’m the kind of person who values correctness over convenience, rigor over speed, doing things right over doing things fast.” That’s an attractive self-concept. Who wouldn’t want to be that person?
But the compliment only works if you maintain the identity. If you switch to a “lesser” language — one whose stereotype is less flattering — it feels like a demotion. Not a technical demotion. A personality demotion. As if using a language with a different reputation makes you a different, lesser kind of person.
This is, of course, nonsense. You’re the same person regardless of what language you write in today. But the nonsense is powerful, and it keeps people locked into stacks they’ve outgrown because leaving feels like losing something about themselves.
The Personality Beneath the Stack
So here’s the real question: if your stack isn’t your personality, what is?
Maybe you’re someone who likes solving puzzles. That’s a personality trait, and it would follow you from Python to Rust to Haskell to whatever comes next. Maybe you’re someone who cares deeply about craft — about doing things well, about elegance, about the satisfaction of a system that fits together cleanly. That’s not a technology trait. That’s a human trait.
Maybe you’re someone who gets energized by collaboration, who loves the back-and-forth of code review and pair programming. Maybe you’re someone who prefers deep solo focus, who does their best work in long uninterrupted sessions. Maybe you’re a teacher at heart, or a tinkerer, or an architect, or a debugger. These are real personality dimensions. They have nothing to do with which framework you use.
The stack is a vehicle. It’s how you express these deeper traits in a particular context at a particular time. But the traits are yours. They were yours before you learned this language, and they’ll be yours after you learn the next one.
Wearing It Lightly
The goal isn’t to have no relationship with your stack. The goal is to wear it lightly. To be able to say “I use TypeScript” with the same emotional weight as “I use a standing desk” — it’s a preference, it’s real, it’s maybe even a strong preference, but it’s not the core of who you are.
The developers who wear their stack lightly are often the most interesting people to work with. They can have strong opinions about technology without those opinions being personal. They can hear criticism of their tools without hearing criticism of themselves. They can explore new things without feeling like they’re betraying old things.
They’re also, not coincidentally, the developers who tend to have the longest and most interesting careers. Because when the landscape shifts — and it always shifts — they can shift with it. Not because they don’t care about tools, but because they know the difference between a tool and a self.
Your stack is not your personality. Your personality is what you bring to whatever stack you happen to be using. And that’s worth a lot more.