Is Software Engineering Stressful?

The pager. That's it. That's my answer. I'm on call one week out of every four. During that week, if something breaks in production, my phone goes off. Doesn't matter what time. Doesn't matter what I'm doing. Two Wednesdays ago I got paged at 2:17 AM because a Kubernetes node pool ran out of capacity. A customer was running a Black Friday load test, in March, because their product team wanted to "stress test early." Their load test was supposed to hit their staging environment. It hit production. Our production. 4,200 API requests per second against a node pool sized for 900.

I was in bed. My girlfriend Leah was asleep next to me. The phone buzzes and I get this full-body adrenaline response that I've developed over three years of on-call rotations. It's not gradual. You go from asleep to fully alert in about two seconds. I grabbed my laptop from the nightstand, opened it in bed, and started triaging. The fix was scaling up the node pool and then rate-limiting the customer's traffic until they fixed their test configuration. That took about an hour and forty minutes. I went back to sleep at 4. My alarm went off at 7. Leah asked me in the morning if I'd slept. I said "mostly."

The thing about on-call is it's not just the incidents. It's the anticipation. During my on-call weeks, I don't sleep the same way. I sleep with the phone on the pillow. I keep my laptop plugged in on the nightstand. I don't drink. I don't go to movies because I might have to leave. My manager, Ravi, says the team is working on reducing page frequency. Last quarter we had 34 pages during off-hours. This quarter we're at 28. That's progress but 28 times in three months I or someone on my team woke up in the middle of the night because a computer needed attention. People in other engineering roles hear "on-call" and think it means you might have to check Slack. It means your sleep is a thing the company borrows when it needs to.

We build an app that helps patients manage chronic conditions. Medication reminders, appointment tracking, symptom logging. The kind of app where if it works, someone takes their blood pressure medication on time, and if it doesn't, maybe they don't. I'm not a doctor. I write Swift code. But the thing I write is between a patient and their medication, and that weight doesn't leave when I close my laptop.

Last November, we had a bug in the medication reminder feature. The push notification service we use changed their payload format, and our parsing code didn't handle the new format correctly. The result was that about 340 users on iOS 16 devices didn't receive their evening medication reminders for two days. We caught it when a patient's daughter called our support line and said her mother hadn't been getting her reminders. That call came in on a Thursday morning. The bug had been live since Tuesday evening.

My manager Deepak said "we caught it fast." And objectively, 46 hours is fast for a silent failure in a push notification system. But 340 people didn't get reminded to take their medication for two days. Nobody died. Probably. We don't know. We can't know. And that's the stress. Not the bug itself, bugs happen, parsing errors happen, API changes happen. The stress is the "probably." I thought about those 340 users for about a week after we fixed it. I'd be eating dinner with my husband and thinking, what if one of those people forgot their beta-blocker because my parsing code broke? That's an insane thing to carry. And it is insane. But it's also true. When your code is between a person and their health, the stakes are not theoretical.

Performance reviews. Specifically, the calibration process. Every six months, my manager Arun writes up my performance and then takes it into a room with other managers and they rank all the engineers in the organization against each other. They use a curve. A fixed percentage of people get "exceeds expectations." A fixed percentage get "meets." And a fixed percentage get "needs improvement," which is corporate language for "start looking." I don't know the exact percentages but people talk about it constantly and the consensus number is that about 5 to 10% of people get the bottom rating each cycle.

My rating determines my stock refresher, which is about 40% of my total compensation. The difference between an "exceeds" and a "meets" rating is roughly $30,000 a year in RSUs. So twice a year I sit through a process where my manager argues to other managers about whether I'm worth $30,000 more or less, based on a written document that's supposed to capture six months of my work in about two pages. And I'm being compared to people I've never met on other teams, doing different work, under different managers with different writing abilities.

The person who sits next to me, Farhan, has a PhD from MIT. He shipped a production system when he was 19 years old. He's brilliant in a way that makes you question whether you're in the right career. And we're calibrated together. My manager told me I'm doing "great work." But "great" against Farhan is "meets." "Great" against a new grad from a state school might be "exceeds." The rating is relative, and the relative comparison is invisible to me. I'm playing a game where I can't see the scoreboard and the rules change every cycle. That sits with me in a way that the actual code never does.

I built our transaction processing system. I mean that literally. I wrote the first version in 2019 when there were 38 of us in a coworking space in Tribeca. I designed the architecture, wrote the core logic, handled the payment processor integrations. Over the next four years, other engineers contributed, the system evolved, but the bones of it are mine. It processes about $180 million in transactions per month now. It works. It's fast. It's well-tested. Last year it had 99.95% uptime.

Six months ago, our VP of engineering, Craig, decided we should replace it with a vendor product. A third-party payments platform that costs $400,000 a year. His reasoning: "we're a fintech company, not a payments infrastructure company. We should focus on our differentiators." And that's a reasonable argument. I've read enough engineering blog posts to know that build-vs-buy decisions are nuanced and sometimes buying is right. But this vendor product doesn't handle half our edge cases. I know because I spent three weeks evaluating it. It doesn't support our multi-currency settlement flow. It doesn't handle the partial refund logic that took me six months to get right. Craig knows this. He said "we'll work with the vendor on customizations."

And now I'm being asked to help with the migration. Of my own system. To a system that's worse. I come to work every day and systematically dismantle something I built. Craig calls it "strategic simplification." I call it replacing a working system with a more expensive system that does less because a VP wanted to put "vendor consolidation" on his OKRs. I haven't said that out loud. I've said versions of it in design review meetings using professional language. I said "the vendor doesn't support multi-currency settlement natively" and Craig said "that's a phase two concern." Phase two concerns have a way of becoming phase one emergencies. I've been doing this long enough to know that. The stress isn't the migration. The stress is being right about the problems and being unable to prevent them.

In web development, if you ship a bug, you deploy a fix. Maybe it takes an hour. Maybe it takes a day. But the mechanism exists. You push code, the servers update, users get the new version. In embedded systems, when my firmware gets burned onto a chip that goes into a brake controller, that chip goes into a car. 200,000 cars, potentially. You don't push a hotfix to 200,000 brake controllers. There is no App Store for brake ECUs. If the code is wrong, it's wrong forever, or until a recall that costs the company $40 million and makes the news.

The code freeze for our next production run is in six weeks. I have 340 open issues in our bug tracker. Twelve of them are severity 1, meaning they affect safety-critical functionality. My lead, Petra, and I triaged them last Thursday and agreed that 8 of the severity 1 issues need to be resolved before code freeze. The other 4 are edge cases that have never been triggered in field testing and can be mitigated with parameter limits. We're making judgment calls about which bugs matter enough to fix and which ones we can live with. In most software, "we can live with it" means a user gets an error message. In my software, "we can live with it" means we've decided the statistical probability of this code path executing in a real vehicle is low enough to accept the risk.

I test my code on a hardware-in-the-loop simulator in our lab. It's a bench with the actual ECU mounted to it, connected to simulated sensors and actuators. When I run a test, I can hear the relay click. I can see the LED on the board cycle. The physicality of it is both the best and worst part. Best because I can see my code do something in the real world. Worst because when a test fails, I'm looking at the hardware that will be in someone's car and thinking about the person driving it. My friend from college, Travis, works at a SaaS company in Ann Arbor. When his code breaks, a dashboard shows an error. When my code breaks, a car might not brake correctly. I don't tell him about that part because it sounds melodramatic. It's not melodramatic. It's just the job.

People problems don't have stack traces. That's the one-sentence version. I was an individual contributor for 12 years. I debugged distributed systems. I optimized database queries. I refactored legacy codebases. Every problem had a root cause, and if you were patient and methodical, you could find it. Management is not that. Management is a senior engineer named Malik telling you in your 1-on-1 that he's bored. Not burned out. Not frustrated. Bored. He's been on the team for two years, he's good at his job, he finishes his work by Wednesday most weeks, and there's nothing in the next two quarters of our roadmap that will challenge him.

When Malik tells me he's bored, my instinct is to debug. Find the root cause. Fix it. But the root cause is that our roadmap is full of incremental features because the product team is optimizing for short-term revenue targets, and I don't control the roadmap. I can advocate for more ambitious technical work. I did. My director, Paula, said she "hears me" and that Q3 might have more infrastructure projects. "Might" and "Q3" are both vague enough that I can't give Malik anything concrete. So I'm sitting across from a talented engineer who is telling me, politely, that he's thinking about leaving, and the best I can offer is "I'm working on it." He nodded. He'll stay for another quarter, maybe two. And then he'll take one of the recruiter messages in his LinkedIn inbox and I'll lose the best engineer on my team because I couldn't make the roadmap interesting enough.

The thing about management that nobody prepared me for is the guilt of knowing a problem and being unable to solve it. As an IC, I could always fix the code. As a manager, sometimes the best I can do is acknowledge the problem, document it, escalate it, and watch it not get fixed because the people above me have different priorities. Malik deserves better. My ability to give him better is limited by organizational decisions I didn't make and can't change. That gap between what I see and what I can do, that's the stress. It's not on-call pages or coding deadlines. It's watching a good person become less engaged and being unable to stop it.