It happens gradually. One day you're a normal person who happens to write code for a living. Then, slowly, the code starts writing you back.
You notice it in small ways at first. You catch yourself mentally refactoring a sentence before you say it out loud. You evaluate restaurant menus for schema consistency. You feel a specific, irrational irritation when someone uses the word "simple" without defining their complexity assumptions.
And then one day someone asks how you're doing and you say "nominal" and mean it unironically.
Welcome. You've been a developer too long. Here are the signs.
You think in conditionals
Normal people plan things. Developers write mental pseudocode for things. The internal monologue has shifted from "if it rains I'll bring an umbrella" to something closer to if (weather.precipitation > 0) { bring(umbrella); }
This isn't a choice. It just happens. At some point the if-else structure became the natural shape of a decision, and now every situation in life gets evaluated as a series of branching conditions with edge cases you should probably handle but probably won't until something breaks.
The advanced version of this is when you start mentally adding error handling to social situations. What's the fallback if this conversation goes in an unexpected direction? What's the rollback plan if the dinner reservation doesn't exist? What's the graceful degradation strategy for this family gathering?
You have opinions about naming things
There are only two hard things in computer science: cache invalidation and naming things. You've internalized this so deeply that it has escaped the codebase entirely.
You renamed a folder on your desktop three times before settling on something that accurately described its contents without being too specific or too generic. You felt something when a friend named their dog a name that was technically correct but didn't capture the essential nature of the dog. You have strong feelings about what the baby should be named and at least some of those feelings are informed by variable naming conventions.
The specific flavor of this sign is the pause before you name anything. The slight hesitation while your brain runs through a brief taxonomy: is this name accurate? Is it discoverable? Will future-you understand what this means in six months? For a folder on your desktop. That you'll probably delete anyway.
You debug before you panic
Something goes wrong in daily life — the car makes a noise, the appliance behaves unexpectedly, the relationship has a bug — and your first instinct isn't emotional. It's diagnostic. What are the symptoms? When did this start? What changed recently? Can I reproduce it?
This is genuinely useful. It makes you calmer under pressure than most people, more systematic in your approach to problems, and significantly better at finding the actual cause of things rather than the apparent cause. The downside is that the people around you sometimes want you to have a feeling before you start troubleshooting, and the two things are not always compatible.
The advanced sign is when you start asking people to describe their problems more precisely. "Something's wrong" is not a valid bug report. What is the expected behavior? What is the actual behavior? Can you provide steps to reproduce?
Your relationship with documentation has become personal
You read terms of service. Not all of them, not carefully — but you read more of them than non-developers do, and you notice specific things that concern you in ways that wouldn't occur to most people. You have opinions about API documentation quality. You've left a job partly because the internal documentation was so bad that it felt like an organizational health indicator, which it was.
The flip side is the guilt about your own documentation. You know you should write it. You know why it matters. You have a vivid memory of inheriting someone else's undocumented code and the specific combination of frustration and grudging respect that came with it. And yet. The documentation is always the thing that doesn't get done, and the knowledge that you're perpetuating the cycle you hate is a low-level background process that never fully terminates.
You have a complicated relationship with the word "simple"
When someone says something is simple, you need more information. Simple for whom? Simple relative to what? Simple in what context, with what assumptions, given what prior knowledge?
You've seen too many things described as simple that weren't. You've said "this should be simple" yourself and been wrong in ways that cost days. The word has been irreparably damaged by experience. Now every time you hear it, a small part of your brain files a ticket labeled "verify this claim" and waits.
The related sign is your reaction to the phrase "just quickly." Someone asks you to "just quickly add a feature" and you feel something in your chest that isn't quite anger and isn't quite despair but lives somewhere in the neighborhood of both.
You optimize things that don't need optimizing
The dishwasher loading strategy. The route to work, recalculated regularly based on new data. The morning routine, which has been refactored twice this year for efficiency gains. The grocery shopping process, which you've been meaning to batch properly instead of running multiple small inefficient trips.
This is the developer instinct for optimization escaping the codebase and colonizing daily life. It's not always bad — some things genuinely benefit from being thought through systematically. But there's a point where you're spending more cognitive energy optimizing something than you'd ever save from the optimization, and you've crossed that line more than once and you know it.
The specific advanced sign is when you start thinking about the time complexity of household tasks. The laundry is an O(n) operation but folding is approaching O(n²) because you keep refolding things that were already folded. This thought has occurred to you. Recently.
Your vacation auto-reply is more detailed than it needs to be
Normal people write: "I'm out of office until [date]. I'll respond when I return."
You write something that includes the scope of your absence, expected response time upon return, escalation paths for urgent matters, a note about what constitutes urgent, and possibly a version number if you've been doing this long enough to have iterated on the format.
The auto-reply is a system. It has requirements. It should handle edge cases. What if someone sends something time-sensitive? What if the escalation contact is also unavailable? What if someone doesn't read it and follows up anyway — is there a retry limit? These are reasonable questions that a normal person would not ask about an out-of-office message.
You feel things about other people's code
Not just your own code — other people's. You read a news article that shows a screenshot of some code in the background and you notice something about it. You watch a TV show where a character is supposedly hacking something and the screen shows clearly fictional nonsense and it pulls you out of the scene entirely. You saw a meme where the code in the background had a subtle bug and you commented on it.
The inverse is the quiet pride when you see good code in the wild — a well-structured query, a clean API design, documentation that actually explains the why instead of the what. You notice it the way a carpenter notices good joinery or a chef notices good knife work. It's craft recognition. You can't turn it off.
You've named things that didn't need names
A plant. A car. A particularly persistent bug that kept coming back. A Roomba. The cat. The second cat that was supposed to be temporary. The Slack bot you built over a weekend that now has more users than you expected and kind of has a personality. All of them have names. Good names, carefully chosen, with reasoning you could explain.
This isn't weird. Everything in a codebase has a name, and the name is important, and you spend a lot of time choosing them. The habit generalizes. Things that exist deserve names. Names matter. This is a professional value that has become a lifestyle.
You have strong opinions about tools you don't use
Every developer has a stack they work in daily. Most developers also have opinions about stacks they've never touched, based on things they've read, talks they've attended, and conversations they've had at conferences where everyone was slightly overcaffeinated.
You haven't used PHP seriously in years but you have a take on it. You've never shipped production Rust but you could give a reasonably informed opinion on its memory model. You know enough about enough things to have positions on most things, and you're aware that some of those positions are more informed than others, but they exist regardless.
The specific developer flavor of this is the Stack Overflow comment thread position — the opinion formed from reading arguments rather than having experience, which you hold loosely but still hold. You've been wrong about tools you've never used. You've also been right. You've learned to flag which is which, mostly.
Your relationship with sleep has changed
You've been paged at 3am enough times that part of your brain never fully relaxes during production deployments. You've fixed a bug in a dream and woken up to write it down and it actually worked. You've had the experience of going to bed stuck on a problem and waking up with the solution fully formed, which is genuinely remarkable and also means your brain is running background processes during sleep that you did not authorize.
You've also developed the ability to context-switch back into a deep technical problem after a ten-minute break with a speed that non-developers find alarming. The on-off switch for deep focus has been used so many times it responds very quickly now. This is useful professionally and occasionally inconvenient personally.
You've made peace with uncertainty
Early in your career, not knowing something felt like a failure. Now it's just the starting state. You don't know this yet. Fine. Where do you look? What's the fastest path to understanding enough to move forward? What can you ship while you figure out the rest?
This is one of the things years of development actually gives you, underneath the jokes about naming things and optimizing dishwashers. A genuine, hard-won comfort with the unknown. The ability to make progress in the absence of complete information. The knowledge that "I don't know yet" is the beginning of figuring something out, not the end of the conversation.
It's not a small thing. Most people never develop it. You have it because you've spent years in a field that requires it, and it shows up everywhere — not just in code.
You've earned the shirt
At Code Crushes, every collection was built for people who recognize themselves in this list. Not because these things are flaws — most of them aren't — but because they're real. They're the specific texture of a career spent building things, debugging things, shipping things, and gradually having your brain reorganized by the work in ways you didn't fully anticipate.
The humor is earned humor. The inside jokes are inside because they're true, and they're only funny once you've accumulated enough experience to recognize yourself in them.
If you've been nodding along to this list, you've been a developer long enough. You've earned the shirt.