Good companies wouldn’t fire someone for this because:
There should be processes in place to prevent this, or recover from this, anyway. It’s a team/department failure and you would just be the straw that broke the camel’s back.
They now know you’ve experienced this and will hopefully know to never do it again. Bringing in someone else could just reintroduce the issue.
I did something like that once, I wasn’t very good at SQL but I needed some data, so I logged in into the production database and run my SELECT queries, I didn’t change anything so everything was good, or so I thought.
I created a cross product over tables with millions of entries and when it didn’t respond I thought it was odd but it was time to go home anyway. On the way home they called me and asked what I did. They had to restart the DB server because once the cache timed out one application after another started failing.
At university the by far coolest and most fun course was compiler construction. We had to write something which would compile a small subset of Java (Javalette) into the Java Virtual Machine instruction set.
I wrote my compiler in Haskell because it seemed that it’d be much less hassle compared to do it in a object oriented or procedual language.
Lmao, I can’t tell if this is stupid, or genius access control. Like if they had problems figuring out which one of their six employees was leaving the lock open, give them each their own lock!
You usually see these on fields that are co-owned or need to be accessed by several municipalities. Everybody gets their own key but can still have access to the area whenever needed.
programmerhumor
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.