What Software Engineering Is Actually Like

When you tell someone you're a software engineer, what do they picture?

They picture me typing really fast in a dark room. Green text on a black screen. Maybe I'm wearing a hoodie. That's the movie version. The reality is, I'm sitting at a standing desk in a WeWork in downtown Austin, staring at a React component that renders a payment confirmation modal, and I've been staring at it for 40 minutes because there's a bug that only shows up when a user double-clicks the submit button on a slow 3G connection. Nobody double-clicks a submit button on purpose. But somebody did, and now there's a merchant in Tulsa whose customer got charged twice for a $34 candle order, and that merchant emailed our support team, and our support team pinged the PM, and the PM, Anika, pinged me on Slack at 9:14 AM on a Thursday.

The message from Anika said "checkout bug, customer charged twice, merchant escalating, can you look?" And that was the start of my Thursday. Not writing a new feature. Not building something exciting. Tracking down why a payment confirmation component fires twice when you click it fast enough.

How long did that take to fix?

The fix was one line of code. I added a loading state that disables the button after the first click. Literally one boolean. isSubmitting, set it to true on click, disable the button when it's true. That took about two minutes to write. Finding the bug took three and a half hours.

The first hour was reproducing it. I couldn't get it to happen on my machine because I have fast internet. I had to open Chrome DevTools, throttle my network to "Slow 3G," and then click really fast. Even then it only happened about one in five times. The second hour was tracing through the code. The payment confirmation component calls our API, which calls the payment processor, which returns a response that triggers a redirect. The problem was that the component didn't track whether a request was already in flight. Two clicks, two API calls, two charges. The component was written eight months ago by an engineer who left the company in November. No tests for the double-click case. No loading state. No debounce.

The third hour was testing the fix, writing unit tests so this specific scenario was covered, getting Tomas to review my pull request. Tomas is the tech lead. He's quiet, very precise, gives feedback in bullet points. He approved it in 20 minutes, which for Tomas is fast. Normally he sits on PRs for a day. I think he could tell from the ticket description that this one was urgent.

One line of code. Three and a half hours.

Yeah, and honestly that ratio is pretty normal. People outside of software think the job is writing code. The job is figuring out what code to write. The typing is fast. The understanding is slow. I probably spend, I don't know, maybe 25% of my day actually writing new code. The rest is reading existing code, debugging, reviewing other people's code, sitting in meetings about what code to write next, and explaining to non-engineers why the thing they think should take two hours actually takes two weeks.

Anika came from Amazon about eight months ago and she brought this energy where everything is urgent and everything needs a timeline. Which, fine, urgency is good, but she'll Slack me at 4 PM asking how long something will take and I'll say "I don't know yet, I haven't read the code" and she'll say "can you give me a rough estimate?" and I'll make up a number that's wrong and then we're both mad later. The estimation part is the thing CS programs don't teach you. How long will this take? Nobody knows. The honest answer is always "it depends on what I find when I open the file." But that's not an answer Anika can put in a sprint planning doc.

What's the best part of the job?

When something works. That sounds obvious but it's a specific feeling. I spent two weeks building a new onboarding flow for merchants. Multi-step form, address validation, bank account linking, the whole thing. And on the day it shipped, I watched the analytics and saw 14 merchants complete the flow in the first hour. Fourteen real people used the thing I built. Their money moves through the thing I built. That's a feeling I haven't found anywhere else. My roommate Casey is a nurse at Seton Medical Center and she talks about that feeling too, watching a patient improve. It's not the same thing obviously, building a checkout form is not saving a life, but the core of it is the same: you made something and it worked in the real world for a real person.

At IBM, where I interned the summer before senior year, I never saw who used my code. I was on some internal tools team writing a dashboard that maybe 200 people inside the company would look at. I applied to 14 startups after graduation because I wanted to be close to the user. Here, when a merchant has a problem, I can see the problem, trace it, fix it, and deploy the fix in the same day. At IBM that would have taken three sprints and a change management review.

Your CTO still writes code?

Nikhil, yeah. He co-founded the company. He still pushes directly to main sometimes, which is, I mean, it's a problem. We have a rule: no direct pushes to main, everything goes through a pull request, at least one review. Nikhil follows that rule about 70% of the time. The other 30% he pushes a hotfix at 11 PM because something broke in production and he doesn't want to wait for a review. And his fixes are usually correct, because he wrote most of the original codebase and knows it better than anyone. But it creates this thing where the rules apply to everyone except the person who made the rules. Tomas brought it up in a retro once. Nikhil said "you're right, I'll stop." He did stop, for about two weeks.

It's one of those startup things. The founders are brilliant and they built the thing from nothing and they still think of the code as theirs. At some point the codebase belongs to the team, not the founders. We're in that transition right now and it's awkward. Nikhil is a great engineer. He's learning to be a manager. Those are different skills and right now he's better at one than the other.

What's yours?

How much of my confidence is tied to my last pull request. If I ship something clean and Tomas approves it with no comments, I feel smart. If he sends it back with 12 comments and a "let's rethink the approach," I feel like I don't know what I'm doing. And I know intellectually that feedback is good and code review makes the code better and Tomas is teaching me. But emotionally? My mood follows my PR approval rate. I've had days where I got a PR rejected and went home and lay on the couch and thought, am I actually good at this, or did I just memorize enough to get hired?

My mom ran a nail salon in Houston when I was growing up. I built their first website when I was 16 using Wix. That's technically how I got into this. And sometimes I think about the fact that 16-year-old me, dragging boxes around on Wix, felt more confident about what she was building than 28-year-old me at a company that raised $42 million. The stakes got higher and the confidence didn't scale with them. Nobody talks about that because in this industry you're supposed to project competence constantly. Admitting you feel shaky is, like, career-threatening in a way I don't think it is in other jobs. Casey, my roommate, talks openly about hard shifts and nobody questions whether she should be a nurse. If I said "I'm struggling with this codebase" in a standup, people would start wondering if I can handle the work.

Insurance company software. That's not what people picture when they think of engineering.

No, it's not. Nobody grows up dreaming of writing Java for an insurance company. But the system I work on processes $2.3 billion in claims annually. Billion with a B. When somebody gets in a car accident in Connecticut and files a claim, that claim moves through the system I maintain. The adjuster enters the information, the system routes it to the right workflow, calculates the reserve, generates the payment, and tracks the whole thing through to resolution. That's maybe 40 microservices, a core monolith that was written in 2009, an Oracle database with about 800 tables, and a layer of batch jobs that run overnight to reconcile everything.

The tech stack has layers like geological strata. You dig down and you find Java 8, then some Java 6, then some stored procedures that predate my employment, and under all of it there's a mainframe system that handles a specific subset of commercial claims because nobody has migrated it yet. The mainframe has been "scheduled for decommission" since 2018. It's still running. It will probably outlive me.

What happened on the Wednesday with the 500 errors?

A Wednesday in October. I was eating lunch at my desk, leftover pasta from the night before. Tamika, that's my wife, she's a school counselor, she makes this baked ziti thing on Tuesdays. I'm eating the ziti and I get a PagerDuty alert at 2:47 PM. The claims processing API is returning 500 errors. Not all requests, about 30% of them. Which means adjusters in the field are trying to submit claims and some of them are going through and some aren't, and there's no pattern from the user's perspective. It just fails sometimes.

First thing I do is check the application logs. The errors are all coming from the same service, the one that validates claim data before writing it to the database. The error message says "connection pool exhausted." Which means the service is trying to connect to the Oracle database and all the connections are in use. Normal load for a Wednesday afternoon is about 1,200 requests per hour. I check the metrics dashboard and we're getting 3,400 requests per hour. Something is generating way more traffic than normal.

Took me about 45 minutes to trace it. A database migration was running. Not a big structural migration, just adding an index to a table. But the DBA, a contractor named Vikram who works remotely from Hyderabad, had scheduled it to run over the weekend. Except the cron schedule was set to UTC and he calculated the offset wrong, so instead of running at 2 AM Sunday, it kicked off at 2 PM Wednesday. The migration was locking rows in the claims table, which slowed down every query that touched that table, which caused connections to pile up, which exhausted the pool.

I called Vikram. It was past midnight his time. He picked up on the second ring because Vikram always picks up, which is one of the reasons I trust him more than most of my onshore colleagues. He killed the migration. The connection pool recovered in about four minutes. Total incident: 38 minutes of degraded service. I wrote the postmortem. The root cause was a timezone miscalculation in a cron schedule. The fix was adding a comment to the cron configuration that says "all times UTC" and having a second person verify the schedule before any migration runs.

Six years at the same company. Do you get bored?

Some days. Most days, honestly. But "bored" isn't the right word. The work isn't exciting. I don't go home and tell Tamika about the thrilling query I optimized. But it's deep. I know this system better than almost anyone. When something breaks, I can usually guess where the problem is within five minutes because I've seen most of the failure modes before. There's a thing that happens around year three or four at a company where you stop learning the system and start being the system. People come to you not because you're the smartest person but because you've been here long enough to know where the bodies are buried. Which table has the weird trigger. Which service silently drops messages when the queue backs up. Which batch job fails every third month and needs to be restarted manually.

Kenji, he's a new hire, 24 years old, first job out of a bootcamp. Good kid. Asks good questions. He looked at our codebase on his first day and said, "This is legacy, right?" And I get why he said it. Java 8, monolithic architecture, no containers, no Kubernetes. By the standards of a 2026 bootcamp curriculum, this is ancient. But this "legacy" system processes $2.3 billion in claims a year and it has a 99.7% uptime over the last 12 months. Kenji's bootcamp final project crashed when more than 10 people used it at the same time. I didn't say that to him. I just said, "Yeah, it's been around a while." He'll figure out the rest.

You left a defense contractor for this. Was that a lateral move?

Lateral-ish. I was at a defense contractor outside Hartford doing, I can't say exactly what, but think data processing for government systems. The work was classified, which sounds exciting and is actually deeply boring because you can't talk about what you do, you can't take your laptop home, and the development cycle is measured in years, not sprints. I shipped one feature in three years. One. The security clearance was nice on a resume but the pace was killing me slowly. I applied to the insurance company because it was 15 minutes from my house and paid $15,000 more. That was the whole decision. Proximity and money. Tamika was pregnant with our first kid. I needed predictability and I needed to be home for dinner. This gives me that. I coach Little League on Saturdays. That only works if I leave the office at 5.

My manager Donna has 11 direct reports. She was an engineer, went into management, and now spends most of her time in back-to-back meetings and writing status reports. She's perpetually behind on 1-on-1s. We're supposed to have them biweekly. We actually have them about once a month. But she's supportive when it counts, she fights for budget when I tell her we need to upgrade something, and she doesn't micromanage. In enterprise, a good manager is one who mostly leaves you alone and has your back when you need it. Donna does both.

What's yours?

How personally you take the code. This codebase is, by any objective measure, a mess in places. There are methods that are 400 lines long. There are variable names that are single letters. There are comments that say "TODO: fix this" from 2014. But I've rewritten parts of it. The claims routing service, that's mine. I refactored it over six months in 2022 and it cut processing time by 40%. When a new engineer joins and makes a face at the codebase, part of me understands and part of me takes it personally. Because some of this code is mine. I know what it looked like before I got here and I know what it looks like now and the difference represents thousands of hours of my attention.

My kids are 4 and 7. They don't know what I do. If you asked my 7-year-old, she'd say "Daddy works on the computer." And she's right. But inside that computer is a system that makes sure people get paid when their house floods or their car gets totaled. There's a weight to that, even though nobody treats it like there's a weight to it. We're not saving lives. But we're making sure a family in Bridgeport gets their $14,000 check so they can fix their roof. That matters to me more than I expected it to when I took this job for the commute and the money.

Philosophy degree to software engineer. How did that happen?

After Reed I worked at a bookstore in southeast Portland for two years. Powell's, actually. I loved it but I was making $15.50 an hour and my rent was $1,100 a month and the math was, you know, the math was not sustainable. A friend showed me freeCodeCamp and I started doing the exercises at night after my shifts. Then I found The Odin Project, which is more structured, more like a real curriculum. I spent about eight months going through it. I'd work at the bookstore from 10 to 6, come home, eat, and code from 7:30 to 11. Weekends I'd go to a coffee shop and code for six or seven hours.

I got my first job at a small consultancy. Four developers, a designer, and a guy who was simultaneously the CEO and the project manager and the sales team. The work was building websites for local businesses. Restaurants, dentists, a dog grooming company. The code quality was, being generous, inconsistent. But I learned how to ship. You get a project on Monday and it goes live on Friday and if the contact form doesn't work, the dentist calls your CEO directly and your CEO walks over to your desk. That proximity to the user was good training. I stayed 10 months and then applied here.

Walk us through what happened with the quick view modal.

OK so this was about a month ago. The product team wanted to add a "quick view" feature to our product listing pages. You know when you're on an e-commerce site and you hover over a product and there's a little button that says "quick view" and it opens a modal with the product details without navigating to the full product page? That. Our PM said it should take about a week. I said I'd look at it.

The first thing I did was look at our product data model. We sell outdoor gear. Tents, backpacks, jackets, that kind of thing. Each product has a listing page and a detail page. The listing page shows the product image, name, and price. The detail page shows everything: description, specs, reviews, variant options, availability by warehouse. The quick view modal was supposed to show some of the detail page content inside the listing page. But our API was designed so that the listing endpoint returns minimal data and the detail endpoint returns everything. There was no in-between endpoint that returned just enough for a quick view.

So I could either call the full detail endpoint for every product the user quick-views, which would be slow and wasteful, or build a new endpoint that returns just the fields the modal needs. I went with the new endpoint. That took a day to build on the backend, including writing the Django view, the serializer, and the tests. Then I started on the frontend.

Harper, she's the designer I work with most, she'd put together a Figma mockup of the quick view modal. It looked great. It also assumed the product would have exactly four size options, exactly one color swatch row, and a review summary that always existed. In reality, some products have 12 sizes. Some have no color options. About 15% of our products have zero reviews. I left a comment on the Figma: "What should this look like with 12 sizes and no reviews?" Harper left a comment back: "Can you just truncate?" I left a comment: "Truncate how?" She left a comment: "Engineering constraint, your call." I love Harper but that phrase, "engineering constraint, your call," is designer shorthand for "I don't want to design the edge case, you figure it out."

So a one-week project became...

Four days for the feature. But then Quinn, our QA lead, tested it and found that the modal broke on Safari when the product had more than two images in the gallery. Safari handles CSS grid differently than Chrome for elements inside a modal with a fixed height. Quinn catches things nobody else catches. She has this photographic memory for UI inconsistencies. She'll open a page and within 10 seconds she'll say "that button is 2 pixels lower than it was yesterday" and she's right every time. I spent half a day fixing the Safari issue and another half day on the responsive layout because the modal looked wrong on tablets.

Total time: about 6 days. The PM estimated one week. I came in just under. But the one-week estimate was a guess and the 6 days included a new API endpoint, edge case handling the designer didn't spec, a Safari CSS bug, and responsive fixes. If any of those had been worse, it would have been two weeks easily. That gap between the estimate and the actual work, that's where the stress lives. Not in the code. In the expectation.

You said your philosophy degree helps. How?

Debugging is argument analysis. When I'm tracking a bug, I'm doing the same thing I did in my epistemology seminar: holding multiple hypotheses, testing each one against the evidence, eliminating the ones that don't hold. Is the bug in the frontend? Test that. Is it in the API response? Test that. Is it in the database query? Test that. Each test either confirms or eliminates a possibility. Philosophy taught me to be comfortable holding uncertainty while systematically reducing it. Most people want to jump to the answer. I want to eliminate wrong answers first.

It also helps with code reviews. When I review someone's pull request, I'm reading it the way I'd read a philosophical argument. Does this conclusion follow from these premises? Is there a hidden assumption? What's the edge case that breaks the logic? My partner Alex is a carpenter and he says something similar about reading blueprints. You look for what's not on the drawing, the load-bearing wall that the architect didn't account for. Same instinct, different material.

Does not having a CS degree hold you back?

In the interview process, absolutely. When I was job searching, I applied to one Big Tech company and didn't get past the initial screen because I didn't have a CS degree. No conversation, no assessment, just a form rejection. That stung. At my current company, Nolan, my engineering manager, hired me based on a take-home project and a conversation. He didn't ask where I went to school. He asked me to refactor a React component and explain my decisions. I got the job.

Day to day, the lack of a CS degree shows up in specific moments. When someone mentions Big O notation in a design discussion, I know what they mean but I have to think about it a beat longer than someone who took algorithms three times. When we were evaluating whether to use a trie or a hash map for a search autocomplete feature, I had to look up the tradeoffs because I'd never implemented a trie in a class. But I've also never been in a situation where my lack of a formal CS education made me unable to do my job. The stuff I don't know, I learn when I need it. The stuff CS degrees teach that I use every day, like version control, git workflows, testing strategies, I learned those on the job anyway because every bootcamp and college teaches a different version.

What's yours?

How much of the job is translating between people who think differently. Nolan, my manager, thinks in roadmap milestones. Harper thinks in user experience flows. Quinn thinks in edge cases and failure states. The backend engineers think in data models and system constraints. My job as a full-stack engineer is to hold all of those perspectives in my head simultaneously and write code that satisfies all of them. The code is the easy part. Understanding what five different people actually mean when they say "it should work" is the hard part.

Nobody told me that in any tutorial. FreeCodeCamp taught me to write JavaScript. The Odin Project taught me to build web applications. Neither of them taught me how to sit in a meeting with a designer, a PM, a QA lead, and two backend engineers, listen to five different versions of what the feature should do, and then go write the code that makes all five of them say "yes, that's what I meant." That's the actual skill. The code is the output. The comprehension is the work.