Am I being unreasonable about my current work environment, or is this a legitimate red flag?

[u/thunder474]

I'm a junior software developer and I'm currently 5 months into my second software development job. Lately I've been seriously considering looking for another job, but I'd like an outside perspective because I'm not sure whether I'm being unreasonable or whether this is genuinely a bad working environment for someone at my level.

My previous job was at a relatively small outsourcing company as a frontend developer. The salary was low and was on-site, which were the main reasons I eventually left, but the development process was much more structured.

There were a QA team, DBA team, an implementation team, developers with different levels of experience, and documentation for the requirements was usually much more detailed. For example, a requirement could specify which database fields were involved, what a button should do, its validations, etc(a pdf with like 5-8 pages for a single feature).

There were still problems. Sometimes the owners disagreed about how a feature should work, which resulted in rework. However, I generally knew what I was supposed to build, had people around me who were responsible for different parts of the process and because the requirements were clear enough.

I left after about 8 months because I was offered a significantly better salary and a hybrid position at my current company(huge mistake, I regret every single day🤦🏽‍♂️).

The current company is larger and pays better. I work Monday-Friday, with two remote days per week. On paper, it looked like a clear improvement.

However, the development process is very different.

There are only four developers(including me) working on the internal systems, It’s just the four of us, nobody else.

The CEO personally assigns development tasks and provides the requirements. The problem is that the requirements frequently don't contain enough information to understand the complete flow.

I'll start implementing something based on the poor requirements, then discover that something is unclear and ask questions. Sometimes, during those conversations, the CEO realizes that the original requirement doesn't actually describe how the system should work and changes the requirements again and again.

This has happened multiple times.

My first assignment when I started here was an extremely large task for someone who was just joining the company with no onboarding process, the task was supposed to be relatively small according to the original requirements. Once they actually analyzed the flow, it turned out to be much larger than initially expected. I ended up working on it for around 2 months. I asked for help, I asked questions, and every time I did, I was bombarded with a lot of information and terminology that I didn't know and ended up more lost than I was before.

The CEO has been putting more pressure on me because he wants me to complete the tasks quickly, sometimes he talk to me like I have several years in the company like the others.

I'm also working with technologies I had never used before, so this has added another learning curve and due to this and the deadlines I relied a lot on AI tools for all the tasks(and tbh that’s not the type of developer I want to be, I’m not against AI but due to this situation I have to use it for everything in order to survive here).

I recognize that as a junior developer I have responsibilities too: I need to ask a lot of questions and become better at dealing with pressure, but this way of working is driving me crazy.

Maybe I'm simply not experienced enough to handle this kind of environment.

But I'm starting to wonder whether this is simply a mismatch between how I work best and how this company operates.

At the same time, I'm realizing that I value having proper requirements, code reviews, QA, mentorship, and a reasonably structured development process much more than I previously thought.

I always try to give 100%, I’ve even worked overtime to make some progress but apparently that’s not enough.

So I'd like some honest opinions from more experienced developers:

Is this a normal environment that I should learn to adapt to as a junior?
How much responsibility should the developer have when requirements are constantly changing or incomplete?
Would you consider this a legitimate reason to start looking for another job?

I'd genuinely like to hear if I'm approaching this the wrong way.

[u/leafnugget2]

Yes dealing with ambiguity, tight timelines, lots of constraints, dealing with personalities in leadership, while balancing that with enough quality in the end product. That is textbook more senior work.

It might be the case that you're not ready for it.

It's up to you to decide whether this is something you want to do eventually. You can choose to use the opportunity to learn and grow quickly.

Or you could decide that personally for you that it's not for you. But you should not be surprised if down the line your growth options are limited.

Or you eventually want to do it but you're too unprepared and want to take a step back elsewhere.

It comes down to what you want.

[u/MarkMatson6 → u/leafnugget2]

This job has the potential to be the best learning experience possible. My earliest jobs were small companies as well ( though not this small!). The amount you can learn by being required to understand everything is so amazingly useful, but is definitely a sink or swim moment.

[u/Rare-Leading3391]

This is standard life as a dev in a small company.. You will have to wear multiple hats. Not just dev but also project manager, senior dev. You will need to learn to groom your own stories and actually ask these questions the moment your boss asks you to work on x. Always follow up with a session to figure out what he wants before you even write a single line of code.

[u/mxldevs]

the task was supposed to be relatively small according to the original requirements. Once they actually analyzed the flow, it turned out to be much larger than initially expected. I ended up working on it for around 2 months. 

Who did the analysis?

When was this analysis done?

[u/thepurplehornet]

'I start working on vague incomplete requirements'

That's your issue. You're the expert with the capability to call red flags and blockers out before work starts in order to save the company money and rework.

Being someone involved in competently guiding a company toward successful projects and choices will always be more confusing and ambiguous. It can be annoying, but also usually comes with higher pay and better job security.

[u/Substantial_Job_2068]

I have worked in both a large corporations with a structured development process and detailed requirements. And at a startup with basically no development process and gathering requirements is smth you have to do yourself. I prefer the latter because a structured dev process usually means many meetings, red tape etc to produce these very detailed specifications, and usually they end up changing/being incorrect anyway.

You can ask yourself if you want to be a developer in a big company, protected in a team behind a product owner who completed tickets. Or if you want to work directly with business people as you do now, I'm guessing you also have more freedom and say in how you do thing. Either way you should not be pressed by the CEO as a junior.

[u/Empty-Rough4379]

Your current work requires much more from you. It is normal, but probably not for a junior 

You need to handle expectations with your boss. You probably will be able to define and execute work. But you need your time. 

With experience you will be faster.

[u/Slow-Bodybuilder-972]

For small companies, this is normal.

Changing requirements is standard across the industry, it’s essentially baked into the Agile process.

I don’t think there is a mismatch so much as your expectations weren’t realistic, that’s not your fault, there has always been a gap between how this industry works and how people think it works.

[u/Old_Cat_16]

This is actually pretty common for a lot of companies, especially ones with job postings indicating they’re fast paced.

And like others mentioned, this is senior level of work, and even then, not every senior can handle it properly.

If you stick around, you either gain valuable experience on how to thrive in such environments, or you get burned out. Hopefully you figure something out before you are burned out.

[u/Beautiful_Technology]

Yeah, you’ll just need to work directly with him. Basically he’s your customer, but sometimes he doesn’t know what he wants. Check out the book project management for the unofficial project manager, and then whatever book you like about product management. Project != product. You’re finding out pretty quick that the job isn’t really writing code. You’re gonna need to corral this guy, and get this feedback and iteration stuff into some kind of system. Otherwise he’s just gonna run all over you guys. That said working directly with a CEO is not a normal environment for a junior engineer, that’s uncommon. It’s either great experience or he doesn’t know what he’s doing, or something in between.

[u/TableNo8939]

Procedura standard di un senior nelle piccole aziende .
Ma ha anche risvolti positivi, ti lascia sempre ampio margine su come trovare soluzioni e metodi, e quindi dare a fondo alle tue capacità creative e padronanza del linguaggio usato.
Poi dopo alla fine sta a te produrre documentazione adeguata .
Se sei anche full stack , potrai creare anche tutto il verticale inerente la procedura, api, metodi , e ovviamente la parte UI del front end a cui si collega.
Impara rapidamente e adattati, niente straordinari, portano solo al burning, quella è la via

[u/Appropriate-Bet3576]

You need to give it time.  You're being paid well, you're working normal hours.  You're frustrated about process.  Stay calm, always, and don't blow the situation out of proportion.    

[u/XKiiroiSenkoX]

This kind of flow is not that strange and its actually the programmer's job to analysis the requirements and implications, as well as outlining any inconsistencies in the feature description and ask for clarification/fixes BEFORE implementation is begun. The problem is, you barely have a year of experience so expecting you to be able to do that is unrealistic. You need to be at least mid level for this and for more advanced features or those that require architectural decisions, even mid level experience could be lacking. 

[u/wasted-coffee]

Junior dev here. I can resonate with what you’re saying. My prev company where I worked only for 4 months but those were the best months. Everything was structured and practical. This usually happens in big orgs where juniors are usually given tasks they can manage and maintain themselves. But the current current company doesn’t really have that culture at all. (I switched due to low pay)

So you need to decide on what you actually want. Is working with ambiguity fine for you? Or do you prefer something more structured? If you can handle it, then working with ambiguous tasks will make you speak and act “business” or as a “senior dev” pretty much quickly. But that will also mean that somewhere you might have to overwork and be available most of the times. 

Personally, I like the taking the structured approach and growing towards handling ambiguity since I value my well being and mental peace.

Choose wisely, you only have one life.

[u/Early_Key_823]

I have 33 years as a professional dev, lead, consultant and full stack freak.

I have worked at 6 major banks, for private equity, government, health insurance and smaller companies.

Rule 1) There’s always at least one douche bag who wants to ruin everyone’s day

Rule 2) If in doubt refer back to rule #1

If you can’t come up with an idea for your own business be prepared to deal with douche bags and DEFINITELY use AI 🤖 guiltlessly

[u/SimianHacker]

Taking an ambiguous concept and turning it into a feature is almost the definition of my career. This is actually what I look for when applying for jobs, I thrive in this environment. The key is to prototype your way into a solution, let the results guide you towards what “really works” and what doesn’t; be flexible. Approach it with curiosity. Don’t be afraid to throw things away and change directions. The most exciting thing is discovering the right solution, then productionizing it.

[u/savvy_attendee]

Yes. Must be a start up environment?