[notmeknees]

Funny that I decided to finally create an account to answer this.

Our team is heavily silo'ed, and each developer is responsible for a specific set of code. Since we have gone through a bunch of reductions and reorganizations, this ends up meaning that often one person is responsible. Our customer is a 24/7/365 operational unit, and it is our only customer.

So, the end result is any given developer is on call all the time, with no pay compensation for that at all. Not only that, but you should expect to be called about not only a defect, but in cases where the customer is trying to use our software in a way it was never designed to be used. So, get a call at 2 AM on the weekend and design and implement a new feature, release to production to debug and test.

I really dislike the way we operate, and recently the entire QA team was let go so I have a feeling things are only going to get worse.

[FLUX-YOU]

Get out ASAP. If that 2am feature causes issues because of an honest mistake from coding at 2am, they will blame you, not their incredibly horrid practices. It is doubly worse they do not compensate you.

[Amezarak]

Yeah, I have to say I envy a lot of the other people in this thread.

I had a very similar deal. I was on call 24/7/365 for two years. Generally something came up at least twice a week. Usually in the evening or on holidays. Often a production issue or an "urgent" ad-hoc query request (they always needed some crazy slicing of data RIGHT AWAY because of customer X or Y or...) but we did, once or twice have a "WE NEED THIS CRITICAL FEATURE WE NEVER EVEN HINTED AT NOW NOW NOW" deal.

No extra pay and the job itself paid only 45k.

I recommend you get out. It just wears too much on you to effectively always be at work.

Now I don't get to do basically any development and the work is boring, but at least I get paid a lot more and I'm not on call. Sigh. Guess you can't have everything.

[acveilleux]

Holy crap, I thought places like that only existed as straw mens in articles about bad practices. It'd unlikely that any other place would be worse, you have little to lose by changing jobs.

A company that behaves like that is actively trying to find ways to cut your job too and they will just as soon as they think they can get away with it... Or maybe they'll cut someone else and have you do their job too, for efficiency.

[angelbob]

The really good and really bad places tend to exist and not get talked about. That is, a surprising number of "strawman" workplaces, good and bad, tend to actually exist.

[ChrisArgyle]

So many red flags, time to find a new job. The big one I recognize from a previous job is the 2AM feature implementation. In our shop it generally went like this:

* Sales, having trouble closing a sale, promises a non-existent feature

* Customer tries to use imaginary feature, calls sales to complain

* Developers have to drop what they're doing and implement imaginary feature full steam

edit: formatting

[jeletonskelly]

> So, get a call at 2 AM on the weekend and design and implement a new feature, release to production to debug and test.

Oh no... just no. Production is not where debugging and testing should ever happen, obviously. If that's what your company expects I'm not surprised QA was let go when your customers are doing it for you. This makes me sad.

[poooogles]

>Oh no... just no. Production is not where debugging and testing should ever happen.

Debugging sure. Testing in production however is incredibly valuable.

[RankingMember]

Are you kidding? Testing in a copy of production (integration, staging), sure. You should never be testing anything in production if you value your clients and reputation (and sanity).

[toomuchtodo]

That's what a canary is for, where you only send it a percentage of traffic.

I guarantee you that you'll never be able to accurately reproduce production traffic in staging or development.