Is Web Development Stressful?

The invisible consequences. That's the thing that sits with me. When your code touches patient data, a bug isn't just a bug. It's a compliance event. It's a two-week incident review. It's a conversation with legal. I shipped a caching fix last October, a pretty routine Redis optimization. Tested it locally, ran it through staging, looked clean. It went to production on a Tuesday afternoon. By Wednesday morning, 140 patient records were displaying the wrong pharmacy preference. If someone had filled a prescription during that window, it could have gone to the wrong location. Nobody was harmed. But that's luck, not skill.

Kwan, our QA engineer, caught it about 6 hours in. He was running a spot check on a completely unrelated feature and noticed the pharmacy field looked off on a test account that he knew had been updated the day before. If Kwan hadn't been thorough in that exact way at that exact time, it could have been 24 hours. It could have been longer. My manager Raj pulled me into a Zoom the next morning and he wasn't angry, he was calm, but he said something I think about a lot. He said, "The problem with healthcare software is that the blast radius of a mistake is always bigger than it looks." And he's right. The incident review lasted two weeks. I had to write a root cause analysis in Jira, walk through the timeline with our compliance team, and explain why our staging environment didn't catch the data mismatch.

I still dream about it sometimes. Not the meeting, not the write-up. The 6 hours. Those 6 hours where 140 records were wrong and nobody knew. That's the stress of backend work in healthcare. It's not the difficulty of the code. It's the weight of what happens when the code is wrong and you can't see it yet.

The moving floor. That's what I call it. I learned Vue to get this job. Spent three months before the interview building a portfolio project in Vue 3, learned the Composition API, got comfortable with Pinia for state management. I felt good about it. I got the offer. Six months later, Alton, our CEO, read a blog post about React Server Components. By Monday, Margot, our CTO, was evaluating a migration. We switched to React. I spent three months getting up to speed on hooks, on Next.js, on a completely different mental model for component architecture. I finally felt solid. Then last month, Alton forwarded a Hacker News thread about Svelte 5 to the entire engineering Slack channel with a message that said, "Thoughts?" I wanted to throw my laptop into the Bay.

The thing people outside startups don't understand is that this isn't just annoying. It's destabilizing. You can never get deep. You're always at the "I can build things but I don't really understand why it works that way" stage, because by the time you'd reach the next level, the ground has shifted again. My friend Kai works at a company with about 2,000 employees. They've been on the same React codebase for three years. He knows that codebase inside out. He knows where the weird parts are and why they're weird. He's built real expertise. When I talk to him he seems peaceful. I don't have that. I have 18 months of familiarity spread across three frameworks and a Notion doc full of half-finished learning plans.

The worst part is you can't complain about it without sounding like you're resistant to change. Startups worship adaptability. If you push back on a stack migration, you're "not a culture fit." So you smile and you open the docs for the new framework and you start over. Again.

The pace of nothing. I know that sounds strange for a stress answer, but it's the most accurate thing I can say. Everything in government contracting takes forever. A dependency update requires a change request, a security review, a Change Advisory Board meeting, and three signatures from people who may or may not check their email this week. Last year I spent 4 months getting approval to upgrade from Node 16 to Node 18. Four months. Node 16 had already hit end-of-life. We were running production software on an unsupported runtime because the process to fix it took longer than the timeline the Node.js foundation gave us to migrate.

Wayne, my tech lead counterpart on the infrastructure side, jokes that we should submit change requests for next year's changes this year. He's not entirely joking. The security reviewer for our division is a woman named Dottie who has been at the agency since 2007. Dottie is thorough, and I respect that. But she reviews every change request with the same level of scrutiny whether it's a major architectural overhaul or a patch version bump on a logging library. I submitted a request to update Winston from 3.8 to 3.11. Dottie sent it back with 14 questions. One of them was, "What is the rollback plan if this update introduces a vulnerability?" For a patch update to a logging library. I answered all 14 questions. It took me two days to write the responses. Then it sat in the CAB queue for six weeks.

The frustration isn't the work. I like the actual development. The codebase is interesting, the problems are real, and the users depend on what we build. The frustration is that the bureaucracy treats a minor version bump like a major infrastructure overhaul, and you slowly realize that the process exists to protect the institution from risk, not to help you ship good software. After 15 years of this, the stress isn't acute. It's a low hum. The feeling that your career is moving at half the speed it should because every productive impulse has to survive a gauntlet of approvals before it can become real.

Legacy code ownership. Specifically, the checkout flow. It was written in 2018 by a developer named Vito who left the company in 2020. No documentation. No tests. One README file that says "see Confluence" and the Confluence page is blank. This checkout flow processes $2.3 million in transactions per week. Every time I touch it, I might break something that costs real money, and I won't know for hours because the monitoring on this part of the system is held together with two Datadog alerts that Vito set up before he left.

I've never met Vito, but I know his coding style better than some people know their spouse's handwriting. He liked nested ternaries. He used single-letter variable names in places where the function is 200 lines long. There's a utility file called helpers.js that is 1,400 lines and contains functions for everything from price calculation to date formatting to a Base64 encoder that I'm pretty sure was copied from Stack Overflow in 2019. My manager Gail knows this is a problem. She's been trying to get a rewrite approved for two quarters, but the business team keeps saying the same thing: "It works. Don't touch it." It works until it doesn't, and when it doesn't, it's 2 AM and Andie from DevOps is paging me because the payment webhook is returning 500s and we're losing $4,000 an hour in failed transactions.

That happened in January. A Stripe API version change broke a deprecated parameter that Vito was still using in the webhook handler. It took me 90 minutes to find it because the error message was generic and the code path had three layers of try-catch blocks that swallowed the real exception. Andie and I got it fixed at 3:40 AM. Total revenue lost was around $6,200. The next morning Gail asked me to write a postmortem and I wanted to write one sentence: "We are building on sand and we all know it." Instead I wrote four pages and recommended the rewrite again. It's still in the backlog.

The performance of competence. That's the best way I can describe it. Every day I walk into standup and the senior devs are talking in acronyms I have to Google under the table. Last week someone said "we need to make the Lambda handler idempotent" and I nodded like I understood. I Googled "idempotent" on my phone while pretending to check Slack. I've read the AWS docs on Lambda cold starts three times and I still couldn't explain it to someone confidently. The stress isn't that I don't know things. It's that I don't know what I don't know, and the gap between my knowledge and what's assumed feels enormous.

My mentor, Pascal, is a senior engineer who's been at the company for 9 years. He's patient, genuinely kind. But he's also busy. He runs two services and sits on the architecture review board. When I ask him a question, he gives me a thoughtful answer and then goes back to his own work, which is fair. But I usually need about four follow-up questions to actually understand, and I'm terrified of being the junior who takes too much of someone's time. So I ask one question, say "that makes sense," and then spend 45 minutes reading docs trying to fill in the pieces he assumed I already had.

My friend Tamiko is a junior dev at a different company. We text each other questions we're too afraid to ask in Slack. Last Tuesday she sent me "what's the difference between a load balancer and a reverse proxy" and I sent back "honestly I just learned this last month, here's the blog post." That text thread is the most valuable learning resource I have. More useful than any internal wiki. Because with Tamiko there's no performance. There's no pretending. It's just two people admitting what they don't know yet. The stress of this job at my level isn't the workload. It's the constant energy spent trying to look like you belong in the room before you actually feel like you do.

The young man's game narrative. I'm 48. My React is current. My TypeScript is clean. I contribute to open source. I can architect a system from the database layer to the CDN. But every tech podcast, every conference, every job posting is optimized for someone who's 28. The stock photos are 28. The "culture" descriptions mention ping-pong tables and beer fridges. The job requirements ask for 5 years of experience with a framework that's been around for 7, which tells you exactly who they're picturing.

Last year I applied for 6 senior developer roles. Got 2 interviews. Both went well on the technical screens, both went quiet after the video call. I'm not naive about what happened. The hiring managers were 33 and 35. When they saw a 48-year-old on the Zoom, something shifted. Maybe it was conscious, maybe not. But the energy changed. My former colleague Vincent saw it coming. He went independent at 45 and now does contract architecture work. He told me, "The industry doesn't fire you at 45. It just stops calling you back." He's not wrong. I've watched three engineers on my current team, all under 32, get promoted to lead roles in the last two years. My performance reviews are consistently strong. My PRs in GitHub get approved with fewer revisions than anyone else on the team. But the promotions go to people who "show leadership potential," which apparently means something different when you're 48 than when you're 30.

My wife Sheryl asks me sometimes if I want to switch industries. I think about it. But this is what I'm good at, and I still love the work. The code doesn't care how old I am. The compiler doesn't check my LinkedIn photo. The stress is that the humans around the code do, and they've decided that the best years of a developer are behind you before you're even halfway through your career. That's a strange thing to sit with at 48 when you know your work has never been better.