Chapter 2: Hello, I’m a [X] Developer
At what point did “I write Java at work” become “I’m a Java developer”? And why did no one warn you those are completely different sentences?
Try an experiment. Go to a tech meetup — or just imagine one, if that’s more comfortable — and introduce yourself without mentioning a technology. Say what you do without saying what you do it with.
“Hi, I build systems that help people manage their money.”
“I work on making search results more relevant.”
“I solve data pipeline problems for a logistics company.”
Notice how strange that feels? Notice how incomplete? There’s a pull, almost gravitational, to append the stack. “…in Python.” “…using Elasticsearch and React.” “…with Spark and Kafka.” As if the sentence isn’t finished until the technology arrives to complete it. As if you haven’t actually told them who you are until they know what language you write in.
That pull is worth examining.
The Grammar of Identity
Language shapes thought. The Sapir-Whorf hypothesis is debatable when it comes to natural languages, but in developer culture, the pattern is clear: the way we talk about what we do collapses the distinction between the person and the tool.
“I’m a Python developer” is an identity statement. It uses the same grammatical structure as “I’m a parent” or “I’m a New Yorker” or “I’m a musician.” It places the technology at the core of self-definition, in the same slot where we put the things we consider most fundamental about who we are.
Compare it to other professions. A carpenter doesn’t say “I’m a DeWalt carpenter.” A surgeon doesn’t say “I’m a Stryker surgeon” (Stryker makes surgical instruments). A chef doesn’t say “I’m a Le Creuset chef.” They might have preferences — strong ones, even — but the tool doesn’t become the title.
Yet in our field, it’s the default. And it’s not just casual speech. It’s on resumes. It’s on LinkedIn headlines. It’s in job postings. It’s the first filter in almost every professional interaction.
“Are you a frontend or backend developer?” Translation: what kind of tools do you use?
“What’s your primary language?” Translation: which tribe are you in?
“Are you more of a React person or an Angular person?” Translation: who are you?
How the Label Gets Welded On
The label usually gets attached during a period of intense learning. You’re deep in a new technology, spending hours every day with it, and something shifts. The struggle starts to ease. The error messages start to make sense. You stop Googling basic syntax and start solving real problems.
That transition — from confused outsider to competent insider — is one of the most powerful emotional experiences in a developer’s life. It’s not just skill acquisition. It’s belonging. You’ve earned your way into a community of people who understand the things you understand, who laugh at the same jokes, who nod at the same frustrations.
And the label is how you claim that belonging. “I’m a Rails developer” doesn’t just describe what you do. It says: I went through the learning curve. I paid the tax. I belong here.
Which is why it sticks so hard. The label isn’t really about the technology. It’s about the work you did to learn it and the community you found on the other side. Asking someone to give up the label feels like asking them to give up the achievement and the belonging that the label represents.
The Box You Didn’t Know You Built
But labels are boxes, and boxes have walls.
Once you’re “a Python developer,” a subtle filtering starts happening. You click on Python articles more often. You follow Python people on social media. You go to Python conferences. Your feed becomes an echo chamber of Python perspectives on problems, and gradually, without noticing, you start to believe that the Python way of seeing things is the way of seeing things.
The box also affects how others see you. Recruiters, hiring managers, and even colleagues start to see you through the lens of the label. “Oh, Sarah’s our Python person.” And once you’re the Python person, the Go project goes to someone else. The TypeScript migration gets staffed with “TypeScript people.” Not because you couldn’t do it, but because the label has become a sorting mechanism, and you’re sorted.
The most damaging part is how the label affects what you allow yourself to try. There’s a voice — quiet, insistent — that says: “That’s not for people like me.” That Rust project looks interesting, but I’m not a systems programming person. That data science role sounds exciting, but I’m a web developer. That functional programming book seems fascinating, but I’m not a Haskell person.
Each “I’m not a [X] person” closes a door. And over the course of a career, the doors close one by one until you’re standing in a very small room, wondering why you feel stuck.
The Uncomfortable Middle
Here’s the uncomfortable truth: the label feels good. That’s why it persists. It provides clarity in an overwhelming field. It gives you a home in a vast landscape. It tells you what to learn next, what to skip, who your people are, and where you belong.
Giving it up — or even loosening it — means sitting in ambiguity. It means being the person at the meetup who says “I work on backend systems” and then has to weather the follow-up question: “Yeah, but in what?” It means tolerating the discomfort of not having a neat one-line identity that signals your competence.
That ambiguity is genuinely hard. We underestimate how much cognitive and emotional work goes into maintaining a clear professional identity, and how disorienting it is when that identity gets blurred.
But the ambiguity is also where growth lives. The developer who can sit in the uncomfortable space between labels — who can say “I’ve mostly worked in Python but I’m interested in distributed systems regardless of the language” — that developer has more options, more flexibility, and more room to become something that doesn’t exist yet.
An Exercise in Subtraction
Try this for a week: whenever you’re about to describe yourself using a technology label, pause and rephrase.
Instead of “I’m a frontend developer,” try “I build user interfaces.” Instead of “I’m a Java developer,” try “I work on enterprise systems.” Instead of “I’m a DevOps engineer,” try “I focus on reliability and deployment.”
Notice what happens. You might find that the technology-free version is actually more accurate. It captures more of what you actually do and care about. It leaves room for the tools to change without your identity changing with them.
You might also find it uncomfortable. That discomfort is information. It tells you how much of your professional identity is load-bearing on the technology label, and how much of the real you is hiding underneath.
Who Are You Without the Prefix?
At the end of the day, this chapter is asking a simple question: can you describe what you do — what you’re good at, what you care about, what you bring to a team — without naming a single technology?
If you can, you’re already ahead of the game.
If you can’t — if the technologies are so entangled with your sense of self that removing them leaves nothing — then we’ve found the thing this book is about.
Either way, you’re still a developer. A real one. The prefix was never the point.