why i quit my first developer job with nothing lined up

I can't get a better job because I'm not good enough.

And if I stayed at this job, I'll probably never be good enough.

That was the thought that ran through my mind that finally pushed me to hand in my notice and quit

my software engineering role after just 7 months with nothing else lined up.

Actually, after just a couple of months at that role, I realized that I wasn't getting better. I wasn't getting better

getting better. I wasn't getting better at programming.

I started to question if any of the code that I was writing, any of the actually more generally the work

that I was doing even mattered.

I started also questioning if staying another year or two at the role will help. Will help make me

will help. Will help make me a stronger engineer.

And I also questioned whether it will even make me more employable.

I was hired hired as a front-end web developer, React, TypeScript, at a legal tech software company. It's called a practice

software company. It's called a practice management system. And what a practice

management system. And what a practice management system is, it's like an all-encompassing single place where law firms can manage their work, track their billings,

automate documents.

There were a few reasons why I felt like I was never going to be good enough if I stayed longer, even if I stayed longer at the job. The first was I wasn't

actually doing much engineering. The

second is even when I write code there's no meaningful feedback from it.

And the third is building software in the dark.

Going into the job as a front-end web developer, I guess I expected most of my time would be spent

in code bases. Whether that's writing code, refactoring code.

That's what I thought that the role was as a front-end web developer, but in reality the percentage of time that I was spending writing code

slowly dwindled over time.

To the point where in the final couple weeks before I put in my notice I was coding

like 2 hours out of a 40-hour week.

Although we were all developers, we had to take on multiple roles in a traditional SDLC, including business analyst, including UI/UX designers.

Those roles did not exist in our part of the company.

In fact, I I don't know if business analysts even exist in the entire company. Our software gets delivered as

company. Our software gets delivered as you get a subject matter expert who drafts a word document

of specifications. The challenge there

of specifications. The challenge there was that those specification documents, they were almost never ready to

be worked on immediately. They weren't

really like user stories, there weren't acceptance criteria for those user stories, and a lot of the times there's not even like a low-fidelity wireframe.

There's no user journeys. So, even

though we were developers, we were handling everything.

When I first joined in May 2025, there were no pull requests. I actually

suggested to my manager at the time and she accepted that we should have code reviews. And part of that was because

reviews. And part of that was because one of the first codebases I worked on was this really legacy Angular application and the codebase was so bloated and filled with

tightly coupled code.

It's like very nested if-else statements and it was just like really hard to work with. So, I think that was what was push

with. So, I think that was what was push pushing me to go like we should probably look at each other's code so that we don't replicate this codebase.

But, over time those pull request reviews became more of a rubber stamp.

Architectural questions often was un- were unanswered and my branches would sit open until they became stale.

And when I when I did ask questions, the majority of the time I was just met with, "Well, you you should just ask AI."

AI." Requirements were constantly shifting.

They were constantly changing.

Priorities were constantly changing.

Like often we had to like heavily rework features right after building them.

I spent months working on this like calculator app for law firms to to calculate how much their client is able to claim on certain

compensations. Several months into the

compensations. Several months into the development it was shown to law firm users on a client visit. But, the

clients apparently pointed out that the entire calculation logic was wrong.

It turned out that the initial specifications did not incorporate the actual statutory requirements that that were in the

legislation and the regulations. So,

I had to actually stop all of the the building, go back, and work with the SME to map out the legal logic into logic diagrams,

and then undo a massive chunk of the code base, and redesign and rebuild the UI. From

experience as a as a BA prior to being an engineer, I think it's tough to have conversations about prioritization of features

if it's not anchored in something like what do the users actually want? So,

what ends up happening is like there's changes in requirements, changes in priority, they're constantly shifting.

And these shifts, these changes were coming from internal assumptions, rather than real user validation. When I suggested to

user validation. When I suggested to management that we get earlier user feedback, as early as possible, before the code gets even planned, so that we

understand what the user wants, what are the problems we're trying to solve, the general response was, "Well, that's why we hire ex-lawyers,

ex-paralegals, ex-legal assistants, and ex-users of the software, so that we don't have to talk to users."

When I heard that, I was kind of I was taken aback. It just made me realize

taken aback. It just made me realize that like I wasn't really in an environment where I could build apps that actually last,

or even solving the right problems. We just have very different expectations about well, how we actually helping people,

helping our end users make their lives better when we're not talking to them.

I realized that I wasn't getting any younger. I was already someone who

younger. I was already someone who had transitioned in career.

Um So, I I really felt like I there was no there was no time for me to waste. And

so, I handed in my notice and uh left at the end of 2025.

The part of me that I'm not sure about is whether this what I experienced is normal

in software engineering in 2026. Like

it's Yeah, I just I guess I just want to know if this is normal or I just like like fell fell into somewhere that that was an exception or that thing I maybe

like gaslit myself on what the role was and and stuff like that. So, I guess I just wanted to see

that. So, I guess I just wanted to see what you guys think if like what I experienced was normal.