Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
@CoreFusionX > "1) get management decisions in writing."
That includes email, Teams/Slack/whatever messages. Backup that data offsite (personal gmail, outlook, whatever) because when it does go sideways, you know they will attempt to deep clean any trace of their bad decisions. -
I find that bringing up old "I told you so - and I was proven right" arguments rarely work. Even if you are always right when you disagree - people will not remember. Most propel are so in their own heads they forget warnings.
Even if Nostradamus worked in a dev team and accurately forewarned 20 bad decisions in a row - people wouldn't remember or trust him the next time 😞
When a decision causes a catastrophic result many managers will argue it still has to be done, or that it isn't that bad. An "I told you so" argument will not be recognised.
(I can admit sometimes I've felt the same. Had a team member say "I warned everyone about not adding X" but all the rest of us had various excuses as to why that wasn't reasonable at the time) -
@jiraTicket > "I find that bringing up old "I told you so - and I was proven right" arguments rarely work."
I've found what works is pointing out the facts, identifying the data that led to the decision, recognizing we have new data, and we try to make better decisions going forward. No shaming and no "I GOT YOU!!" -
@PaperTrail Yeah, that's the reasonable approach! Not making it about a person or a specific argument but about data.
Allthough I'm used to people not really wanting to look back at what lead to the mistake, the vibe is that would be delving in the past. Some will go "oh well, bummer, let's focus on moving on". And next time someone issues a warning they will not recognize how it's similar to the last time.
But not much to do about it. -
@PaperTrail I know you are a big proponent of a paper trail but taking corporate communication off site is usually highly illegal and a security risk/breach.
Making backups on the work cleared devices is a very good idea hi of course. -
TeamLeader: I need you to stop disagreeing with the decision of the management, the people in there are taking their decision for a reason.
IHateForALiving: When integration tests were failing, the management decided to comment out the ingration tests; god knows how many bugs slipped by.
When users had problems with the idiotic migration process the management designed, the management decided to remove down migrations; it took two weeks before the QA team started screaming, as all their machines were filled with garbage data.
I was writing type definitions for my code, you removed it. You effectively ensured the only person capable of working on that particular piece of code would be me.
I have been proposing for 8 months to make a unified scheduled jobs system, you all decided to create at least 5 different -and incompatible- implementations, at least 4 of them are total garbage with setTimeout, there's no way to ever unify them and God willing they never break, if they do there's NO WAY to find out even where tf they're hidden in the code.
Every time you were making one of those bad decision I was the only one warning you of the problems you were creating. The idiotic change of the day is going MongoDB+Angular: I can keep a low profile if you want, but when this blows up you can be damn well sure I'll handle my 2 weeks notice because there's no way on earth I'll be stuck with the aftermath of you lot taking technical decisions you are clearly unable to manage.
rant
i will undog you