The Internal Struggles of a Software Engineer

There's a version of every developer that exists only in standups and sprint reviews. Tickets move across the board. Someone asks a question in Slack and gets an answer within the hour. From a distance, it all looks calm. Controlled, even.

But that's rarely the whole picture.

Underneath it, there's usually a running argument going on that nobody else is invited to. Should I do it this way, or that way? Is this actually the right call, or just the one that's easiest to justify by 5pm? You don't see that on a burndown chart. Nobody puts "spent forty minutes talking myself out of starting over" into a retro. But it's there. Quietly running in the background, like a process nobody remembered to kill.

If you've ever sat in a code review and felt your chest tighten slightly before anyone had even left a comment, you already know the feeling I'm talking about. It's not really about the code. It rarely is.

And there's a newer voice that's crept into that noise too, one that's a bit harder to shake off than the rest. We'll get to that one. It deserves its own space, right at the end.

For now, let's start with the argument that probably shows up the most...which way do I actually go?

There's more than one way to skin a cat

I'm not even a cat person, and I still wince a little every time I hear that phrase. It's such a bizarrely violent way to describe "there are options available to you," but here we are, still using it decades later. Anyway. Onwards!

Ask three engineers how to solve the same problem, and you'll probably get four answers. Maybe five, if one of them changes their mind halfway through explaining it.

That's not really a bad thing 🤷‍♂️. It's actually one of the more interesting parts of the job. But it also means that before a single line of code gets written, there's already a quiet negotiation happening in your head:

• Do I build this properly, or do I build this quickly?
• Do I reach for the pattern I know well, or the one that's technically more "correct" for this case?
• Do I ask someone, or do I just get on with it and hope I'm not about to walk into a wall?

None of these questions have a clean answer. And that's the uncomfortable part. There's rarely a single obviously right path, just a handful of "reasonably defensible" ones, and someone has to pick.

The tricky bit is that this decision often has to be made early, usually before the problem's fully understood. You're choosing a direction with partial information, then living with the consequences of that choice for however long the code sticks around. Which, let's be honest, is usually a lot longer than anyone planned for 😅.

It's a small kind of pressure that repeats itself constantly. Not once a sprint. Not once a day. Sometimes multiple times before the coffee's gone cold.

You made your bed, now you have to lie in it

Except in this case, the bed is a schema decision made eight months ago by someone who's since left the company, and you're the one who has to sleep in it.

Every decision in software has a shelf life you can't quite see when you're making it. Sometimes it's short. Sometimes it's a throwaway script that somehow ends up running in production for three years and nobody has the heart to touch it. Sometimes it's a much bigger call, an architecture, a database choice, a "we'll just do it this way for now" that quietly becomes permanent the moment it ships.

And here's the thing nobody tells you early on: being wrong isn't actually the hard part. Most engineers can handle being wrong. What's harder is being wrong slowly, in a way that only becomes obvious months later, once the decision has had time to work its way into everything around it.

• The library that seemed like the right pick, until it stopped being maintained
• The "quick and simple" data structure, now propping up half the product
• The naming convention that made sense at the time, and only at the time

By the time it's clear something needs to change, ripping it out isn't really an option anymore. Too much depends on it 🙈. So you patch around it instead. You build little workarounds, add a comment that says // TODO: fix this properly, and quietly hope that future-you, or better yet, future-someone-else, has more time than present-you does.

There's a particular kind of tiredness that comes from working around your own past decisions. Not because the decision was reckless. Usually it wasn't. It's just that nobody hands out a crystal ball with the job. You make the best call you can with what you know, and then you live inside that call for a lot longer than feels fair.

There's no time like the present, apparently

Nobody ever asks for a feature next month. It's always "can we get this in by Friday," said on a Tuesday, about something that hasn't been fully scoped yet... 😅

Software has this strange property where the work looks finished long before it actually is. A button exists. A form submits. It looks done, and looking done is often enough for someone to start planning the launch email. What isn't visible is everything sitting underneath it: the edge cases, the error states, the thing that only breaks when a user does something nobody expected them to do.

That gap, between looking done and being done, is where a lot of quiet pressure lives.

• Cutting a corner you know you'll have to come back for
• Skipping the test you'd normally write, "just this once"
• Shipping something you're not fully happy with, because not shipping isn't really an option either

None of this is usually anyone's fault directly. Deadlines exist for real reasons. Customers are waiting. Competitors are moving. The business has to, well, business. But from inside the work, it doesn't always feel like a reasonable trade-off being made. It feels like being asked to do the job properly and quickly, and only ever being thanked for the quickly part.

The corners get cut quietly, and they get remembered loudly. Nobody notices the test that got written. Everyone notices the bug that got shipped. That imbalance sits with you longer than it probably should.

Just go and discover it, they said

It's a bit like being told to "go make some magic happen," except with a ticket attached and a deadline two sprints away.

At some point, someone in a meeting says a phrase like "let's A/B test this" or "we should do some discovery first," and everyone nods, because it sounds sensible. It is sensible. Nobody's arguing with the idea. The trouble starts afterwards, in the quiet moment when the meeting ends and it's actually down to you to work out what that sentence means in practice 😬.

• A/B test it... against what, exactly? With how many users? For how long, before the result actually means anything?
• Do some discovery... talking to who? Reading what? And how do you know when you've done enough of it to start building?
• Validate the idea... with what counts as validation, and who decides that it's been reached?

None of these are difficult concepts. That's not really the issue. The issue is that they get handed over as instructions, when really they're entire disciplines that some people spend their whole careers getting good at. Saying "let's A/B test it" takes about two seconds. Actually designing a fair, meaningful test takes rather longer than that.

So you end up doing your best impression of the process. You cobble together something that resembles discovery. You run a test that's probably not statistically rigorous, but is better than nothing. And you carry a small, nagging feeling the entire time that you're doing a slightly wrong version of a thing you were never really shown how to do properly in the first place.

It's not that the advice is bad. It's that "go and do the hard, specialised bit" is a strange thing to say so casually...

By the time you've learned it, it's already changed

To be fair, we're past the era of a brand new frontend framework landing every six months. Things have settled, a bit. But "settled" doesn't mean "stopped." 😅

There's still a particular flavour of tiredness that comes from trying to keep up with an industry that refuses to sit still, even if the shape of that movement has changed. It's less about entirely new frameworks now, and more about the constant churn underneath the ones you already use: major version bumps, deprecated APIs, a new "recommended" way of doing the thing you only just got comfortable doing the old way.

• A tool you finally understood, now with a v2 that changes half the syntax
• A "best practice" that's quietly become an "anti-pattern" while nobody was looking
• An entirely new category of tooling turning up, built around something (AI, most likely) that didn't really exist as a serious concern eighteen months ago

The strange part is that none of this is really optional. You can't just opt out and stick with what you know, not indefinitely. The landscape shifts, the job market shifts with it, and eventually the thing you were confidently good at quietly stops being what people are hiring for. So you keep reading. You keep experimenting on evenings you'd rather not be working. You keep half an eye on things, just in case you've missed something important.

It's less "lifelong learner" and more "trying not to drown while everyone insists the water's fine." Most days you manage it. Some days you just quietly close the tab and pretend you'll catch up at the weekend.

Everyone else seems to have this figured out...

There's a very specific kind of low mood that comes from scrolling through a timeline of people who all seem to be shipping side projects, landing promotions, and speaking at conferences, all before you've finished your second coffee...

Comparison is a strange thing in this industry, because the evidence is everywhere and almost none of it is representative. You see the shipped feature, not the three days spent debugging it. You see the "excited to announce" post, not the eighteen rejected applications that came before it. You see someone's polished side project, not the four abandoned ones sitting in a private repo somewhere.

• The engineer whose blog posts always seem to know exactly what they're talking about
• The one who somehow contributes to open source and has a full time job and apparently sleeps 🤯
• The one who got promoted after two years, when you're on year four wondering what you're doing wrong

The uncomfortable truth is that most of this comparison happens against a version of someone else that's been carefully edited, whether they meant it to be or not. Nobody posts the merge conflict that took an entire afternoon. Nobody writes the thread about the meeting where their idea got quietly shot down. You're comparing your full, messy, unfiltered experience of the job against everyone else's highlight reel, and then wondering why the numbers don't add up.

It's not that other people aren't doing well. Plenty of them genuinely are. It's that "doing well" and "never struggling" aren't the same thing, even if it's easy to mix the two up at eleven at night when you're staring at a bug you can't quite explain.

The Burnout 🥵

It rarely happens all at once. Nobody wakes up and decides today's the day they stop caring. It's slower than that, and a lot quieter.

Burnout doesn't tend to announce itself. It creeps in disguised as other things: a bit more cynicism in code review than usual, a slightly shorter fuse in standup, a growing pile of "I'll get to that eventually" that never quite gets got to. The work that used to feel like solving a puzzle starts to feel more like just... moving tickets from one column to another.

• Caring less about the "right" way to do something, and more about just getting it done 😭
• Dreading the small talk in meetings that used to be the easy part of the day 😓
• Finding it harder to summon enthusiasm for things that would have been genuinely exciting a year ago 😔

The tricky part is that burnout doesn't really respect deadlines, sprints, or how much you've got left in the backlog. It just quietly builds, usually while everything on the surface still looks fine. Tickets still get closed. Standups still happen. From the outside, nothing's obviously wrong. From the inside, it can feel like running on a battery that never quite gets back to full, no matter how the weekend went.

It's rarely one big thing. It's usually a hundred small things, none of them dramatic enough on their own to raise a flag, all quietly adding up in the background until one day the tank's just... empty.

And then there's AI

Every other struggle in this post is one developers have been quietly carrying for years. This one's newer, and it sits a bit differently.

Most of the conversation around AI and software engineering focuses on the boring bits it's supposedly going to take away. The boilerplate. The repetitive refactors. The bits nobody particularly enjoyed writing anyway. And on paper, that sounds like a reasonable trade. Nobody's especially attached to writing the same CRUD endpoint for the hundredth time 😂.

But that's not really the fear, is it? Not the honest one.

The honest one is quieter, and it's this: what if it doesn't stop at the boring bits? What if the part it eventually gets good at is the part that was never boring in the first place? The actual problem solving. The moment you finally understand why something's broken. The satisfaction of untangling a genuinely hard bug, or landing on a clean solution to something messy. That's not the tedious 20% of the job. For a lot of engineers, that is the job. It's the reason a lot of people got into this in the first place.

There's something strange about watching a tool get better at the exact thing that used to make you feel good at yours. It's not quite jealousy. It's not quite fear, either, not the dramatic kind. It's more of a low hum in the background, a question that doesn't have a comfortable answer yet: if the interesting bit gets automated too, what's actually left for me to enjoy?

To be clear, none of this is a prediction. Nobody actually knows how this plays out, least of all the people confidently posting hot takes about it. But it's worth naming honestly, rather than pretending it's just another line item on the list of things to keep up with. It sits closer to the identity of the job than any framework churn ever did.

Maybe that's the real internal struggle underneath all the others. Not just doing the job well, but wondering if the parts you love about it will still be yours to do at all.

So, where does that leave us?

None of this is a complaint, not really. It's just what the job actually looks like once you get past the standups and the tickets and the "all good, just picking this up now" messages in Slack. There's a quiet, constant negotiation happening underneath all of it, and it's been there the whole time, whether anyone's talking about it or not.

If any of this sounded familiar, that's probably the point. These aren't signs of being bad at the job. They're just what the job quietly asks of the people doing it, day after day, mostly unnoticed. The indecision, the pressure, the comparison, the tiredness, and now this newer, harder question sitting alongside them. None of it shows up on a burndown chart. All of it is real anyway.

There's no neat conclusion here, and I don't think there's supposed to be one. Some of these struggles ease off with time and experience. Some just change shape. And the newest one, the AI-shaped one, is still working itself out in real time, for everyone, not just engineers.

Maybe the most useful thing is just saying it out loud. Not to fix any of it, just to make it a bit less lonely to carry.

If any of this struck a chord, I'd genuinely like to hear about it. There's probably a struggle or two I've missed entirely, and someone else's version of this list is likely a little different from mine.