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
Search - "fire drill"
-
Just had a fire drill at school. I yelled "GIT PUSH!! GIT PUSH!!".
I've always wanted to do that... :P13 -
#4 Worst thing I've seen a co-worker do?
Not a direct co-worker, during a fire drill, a call center manger told all the agents to ignore the alarm and keep working.1 -
Fucking drills.
I spent 1 hour to get in my zone and they have to do an unorganised unhelpful fire drill. Fucking timewaste. Why? 😫3 -
That moment when your arrogant client arrives at your office and you have a fire drill at the same time ...and you see him running down 5 floors for no reason at all 🤣🤣🤣
-
It took literally days to get our software installed onto the client VMs and get the services started correctly.
On our own test VMs the same task takes all of about an hour or so. Mind you these VMs are supposed to be created and match the client's environment almost too the T. Same configurations, same third party software, same environment variables and the whole 9 yards.
This was not the case at all.
Environment variables were not set, third party software was not installed, and I honestly don't remember the list of things wrong with how they setup the VM. Sparing the details, the errors were also not helpful.
They also gave us critical information we needed for development days before we were going on site to test. The amount of hackery we had to do could be a completely separate rant on its own.
While desperately trying to to stay sane long enough to get our services started, the only thing I could think was how great it would be if there was a fire or something. Anything, just to have an excuse to go back to the hotel and actually sleep. The second day there we finally had everything installed and running.
I shit you not, just as we began our first test, the fire alarms went off.
At this point in time the team was extremely (pissed tf off) annoyed to put it mildly. Assuming it was just a drill, we left our stuff and went to eat dinner. After we came back we found out it in fact was not a drill...
Moral of the story:
Don't wish bad fortune on a customer even if out of impulsive spite.
Other moral of the story:
Don't leave your belongings behind only because you think the fire alarms are just a fire drill. It may not be.
P.S. Karma's a bitch.1 -
FIRE DRILL!!!!!
Customer who decided to deploy our system in the middle of their busiest time ... and kinda ad hoc-ed their ... human processes (not sure what to call it). Just to get by, and then sort of let things rot.
So last week they contact us and say "OMG some poor soul at this company was spending hours making spreadsheets to track what they were doing... and they keep fucking it up because it's nigh impossible to get right".
Real story, big shake up at the company, and someone said "lets look at our process" and they discovered "holy fuck we have this software but we're doing shit like it's the damned civil war".
This naturally raised questions about the competence of the folks we work with ... who chose our software, and thus our software.
So now we're flushing out all the stuff we asked the customer to figure out months ago that is usually done via a months long implementation / integration ... in a few days. Also ... I'm making some new things for them.
WEEEEEEEE
Granted, we're billing them like mad for this so no big deal really.1 -
When all your work is due, and you're busy as all get out.... And there's /literally/ a fire drill 😡2
-
Just discovered https://twitter.com/ExpertBeginner1. It's the story of my life. Giant classes, copying and pasting, and architects who create frameworks. It's great when we combine all three: A "framework" created by an architect which is made of giant classes that you copy and paste. Imagine a giant generic class where the generic argument is only used by dead code. Pause for a moment and try to visualize that.
It inherits from a base class with lots of virtual methods called by base methods that throw NotImplementedException, so if you don't need them you have to override them to return empty collections. If you're going to do something so messed up you could just put those default implementations in the base. But no, you can inherit, it compiles, and then it throws a runtime error unless you override methods the compiler doesn't require you to override.
The one method you're required to override has a TODO comment telling you what to put there. Except don't ever do what the comment says because that's the old standard. The new standard says never, ever do that.
Most of the time when I read about copy-and-paste coding it's about devs who copy and paste because they don't know how to write or reuse code. They don't mention the environments where copying and pasting the same classes over and over again is the requirement and you're not allowed to write your own code.
Creating base classes where you just override a method or two can potentially work, but only in the right scenarios and only if you do it right. If you're copying and pasting a class that inherits from the base class and consists entirely of repeated code, why the heck isn't that the base class? It could be a total mess, but at least it would be out of sight and each successive developer wouldn't become responsible for it by including it in their own code.
It's a temporary engagement, but I feel almost violated. I know it's a first-world problem, and I get to work indoors and take vacations. I'm grateful for those things.
Before leaving I had to document the entire process of copying and pasting an entire repo, making a ton of baseline edits that should just be in the template but aren't, and then copying and pasting from other places into the copied and pasted code. That makes me a collaborator. I apologize more than once in the documentation, all 20 pages of it that you have to read and follow before you even get to the part where you write the code for what you actually need it to do.
This architect has succeeded in making every single thing anyone does more about servicing the needs of his "framework" than about writing actual code to do what needs doing. Now that the framework is in and around everything it creates the illusion that it's a critical part of our operations. It's not. It's useless overhead.
Because management is deceived into thinking they need it they overlook the fact that it blows up, big and small, every single day. The log is full of failures that I know no one ever sees. A big chunk of what they think it does fails silently, and they don't even notice until months later when they realize how much data they're missing. But if they lose, say, 25% they'll never notice.
When they do notice they just act like it's normal, go into fire drill mode, and fix it. Doom. You're all doomed. I'm standing on the deck of the Titanic next to my jet ski.1