Dev: If you force this to be done in this timeframe it will fail in a month.
Manager: Do it anyway.

A month later:
@@FAILS@@

Manager: Why didn't you tell me this would happen??

FUCK YOUUUUUUUUUUUUUUUUUUUUU

For these kind of things, I like to either add a comment on the ticket or send an email to the involved parties going like:

"As discussed with @manager, I implemented solution X (which has the downside of Y)."

If it is more clear what needs to be done, I open directly a follow up ticket with the yet open things.

Then, whenever the issue pops up again, I can show them that very ticket.

The most satisfying one was where I was asked "why doesn't your application do x" and I could state:

"I wrote a ticket about that very feature. You didn't deem it important enough half a year ago."

Definitely put concerns like that in writing. Managers who behave like incompetent twats deserve to be made to LOOK like incompetent twats whenever possible.

The ceo asked me to rewrite the analytics backend (which I have reviewed for 2 weeks with tech I haven't worked with before) in a week....

Amomg the stated arguments were "easy", "should be fast - if not we're doing something wrong"

I am planning to quit after the next paycheck...

You can understand I think that putting in writing won't do much here :)

@antonis179 in what way is the CEO qualified to make judgements about technical difficulty? Is he a technician himself? There is nothing i hate more than being told something should be easy and quick by someone who lacks the knowledge to make that judgement.

@MrXero well he sells honest to god crap to clients. Thats what he's good at.

Our analytics are just metrics for instance: installs, downloads, etc.

And clients have bought this. As analytics.

Really not in a good mood today as you can tell...

@k0pernikus my manager is a very nice person. One of the things I learned from him is if you fail, you fail. It's your fault. You can point fingers and give justification that it was discussed this way only and it might not be your fault. But if your code fails it's your fault. Better think about everything even if it's not in your area.
We do a lot of Number crunching. And sometimes numbers differ and sometimes stakeholders wants us to change a number on which a lot of calculations are dependent.

@Sainathl This was actually for the entire backend of my company.
One month - no design - no documentation.
Now we're rewriting it...
One week initial deadline.

I've been pointing fingers all day today!! (Well... Just the one!)

:)

#no_hope

@antonis179 pointing fingers doesn't help. I have also tried doing that.. kind of makes me sad..

@Sainathl I agree.
However also telling them what should be done changed nothing...

They had their chances to make things better for years and right now I'm just wasting my time patching things up and not developing my skills.

So while I agree this attitude doesn't help they have made me not care anymore.
8 people out of 30 have quit the last 2 months. Soon to be 9

@Sainathl For me, it's not about fingerpointing (though I grant you the fact that I use it as a defense mechanism). I use it more as an advise and sometimes warning, and also stating my assumptions.

I want to own my mistakes. Yet sometimes you are at the sake of your superior's decision and have to make do with it against your own judgement.

It's quite easy to say that you own the mistake when your code fails.

Yet when is your code deemed a failure?

If it's a syntax error or a failing unit test, it's quite easy. If it's business logic / unclear requirements / missing features, it becomes fuzzy fast.

@k0pernikus you are right. My manager says even if the business requires were unclear or contradictory you have to understand them first before implementing. But sometimes things change along the way making it harder.

Yes, definitely document it. I, however, was blessed with managers who managed to still claim things like this were my fault even after publicly & privately warning about consequences of tradeoffs. YMMV.