It's Thanksgiving. You've barely gotten your coat off. And there it is — the question, delivered by a well-meaning aunt with the confidence of someone who has never heard the word "backend" in their life:
"So what do you do again? You work on computers?"
You work on computers. Sure. That's one way to put it.
If you're a software engineer, you've had this conversation approximately four hundred times. At holidays. At weddings. On first dates. On airplanes next to strangers who are about to explain to you what "the cloud" is. And every single time, you have to decide: do I explain it properly, or do I just say "yeah, basically" and change the subject?
This is a survival guide for the former.
"So what do software engineers do all day?"
Great question, hypothetical relative. Let me explain.
You write instructions for a machine that has no intuition, no common sense, and will do exactly what you tell it — including the wrong thing, at scale, in production, on a Friday afternoon. You spend a significant portion of your day reading error messages that technically describe what went wrong but offer no emotional support whatsoever. You Google things you've Googled before. You attend meetings about meetings. You occasionally ship something that works, which feels like winning an Olympic event, except nobody outside your team knows it happened.
"But like... what are you actually building?"
The website your bank uses. The app your doctor's office crashes on. The thing that recommends you movies you've already seen. The checkout flow that breaks every time someone tries to pay with a gift card. The code that runs on servers in buildings you've never been to, doing things at 3am that no human is awake to witness.
You build the invisible infrastructure of modern life, and then get asked if you can fix someone's printer.
The Analogy Game (And Why It Never Quite Works)
Developers spend years developing analogies for this conversation. Here are the ones that get tried most often, and why they all fall slightly short:
"It's like writing a recipe." Close, but recipes don't throw a cryptic error if you forget a comma. And they don't have seventeen dependencies that all need to be updated before you can make pasta.
"Think of it like building with Legos." Except the Legos are invisible, some of them are on fire, and the instructions are a Stack Overflow answer from 2014 that may or may not still apply.
"I build apps." This one works until someone asks if you could build an app for their idea about a social network for dogs. (You could. You won't.)
The truth is, software engineering is one of those jobs where the output is real and valuable and everywhere, but the work itself is essentially invisible. You're thinking for a living. You're debugging systems in your head. You're holding fifteen context windows open at once in your brain while someone asks you to "just add one quick thing."
What Do You Actually Say?
Honestly? The best move is to find the thing in your domain they already use and connect it to that.
"You know how when you click 'pay' on Amazon and it actually works? I build the systems that make that happen."
"You know how your phone knows when you've been somewhere and asks if you want to review it? I work on stuff like that — except for [company thing]."
"You know that spinning wheel that shows up when a page is loading? I try to make that not happen."
This approach works because it anchors abstract work to concrete experience. It doesn't fully explain what you do, but it gives the other person a foothold. That's all they actually need. They don't want a systems architecture lecture. They want to feel like they understand, nod, and move on to asking if you want more pie.
The Gear That Says It Without Words
Some conversations you don't want to have at all. Sometimes you want your outfit to do the talking — or at least set expectations before the conversation starts.
The Works on My Machine Tee is perfect for this. It's a reference that fellow developers will immediately recognize (and silently salute you for) while confusing everyone else just enough that they might not ask follow-up questions. That's the goal.
For the holiday gathering where you know you're about to face the full interrogation, consider showing up in the git commit -m 'fixed it' Hoodie. It says "I'm a professional, I'm warm, and I have committed code without looking at what changed." Relatable to your team. Opaque to your extended family. Perfect on both counts.
And if you want something to put on your desk while you're on the video call where someone asks why you can't just use Excel for the database, the Undefined is Not a Function Mug is a deeply specific error message that will resonate with anyone who's done JavaScript and baffle everyone who hasn't. Which is the correct distribution of reactions.
The Real Answer
Here's what you actually do: you solve problems that haven't been solved before, using tools that are constantly changing, under constraints that are often contradictory, for requirements that shift mid-sprint. You think in systems. You care about edge cases. You're comfortable with uncertainty in a way that most people aren't, because your entire job is operating in the space between "it should work" and "it does work."
That's harder to put on a Thanksgiving table than "I work on computers." But it's the truth.
And if all else fails, just say you're in IT. Nobody asks IT follow-up questions. They just want you to look at their printer.
Browse developer-humor apparel that explains the job without words at Sudo Threads.
