On the first class of cryptography professor says, "Hackers are people who dropped out of school, didn't obey their parents and turned to drugs and alcohol and steal money from people by hacking their facebook."

Then goes on to say, "People tend to keep their birthdate as their debit card's PIN so hacker checks their facebook account, finds their birthdate and goes to ATM machine and hacks their bank account."

I was speechless.

Best "error" I've ever seen today.

We have a very large database with millions of people, some of those records are duplicates. So I had a long project to write something that would automatically merge duplicate records while allowing employees to review them. Today we had a duplicate show up in the list which should not have.

Same name (apart from one letter), address, employee ID (off by 1 number), same manager, title, phone number, birthdate. But we figured out it wasn't the same person and therefore wasn't a good match.

Turns out they are twin sisters who live together and we're hired by the same manager for the same position at the same time. What are the odds...

Seriously anyone who doesn't use english names for variables and shit, get the fuck out! I don't care how many dicks you sucked, don't fucking do it!

I'm working on redoing a somewhat big database with a small team and the fuckers who designed the new database decided to use danish names everywhere and misspell shit! What the fuck are you doing!

Who the fuck calls it a birthdate? and misspells the danish equivalent?

And what the fuck is this, using _id and ID like they are the fucking same thing!?!

For the love of all that is holy, stick to english, one naming convention and check your crap spelling!

AARGH!

Today I made like the dirtiest hack I ever made. I needed to convert people's birthdate into days (starting from 0), and then had to find out the oldest person. It didn't work, because the output was the youngest person... So instead fixing the mistakes in my code, I simply made the value be negative ¯\_(ツ)_/¯

Oh null, how I detest you.

select birthdate, isnull(birthdate) from Users;
>> [null, 0]

Maybe I wrongfully accuse the abstract concept, and should rather loathe the engineers who can't wrap their heads around null despite their heads being a skull literally wrapping fucking nothingness.

Oracle engineers:
"Wait that's invalid input. What do we do?"
"Default the date to 0000-00-00?"
"That kind of looks like a null..."
"Hmm but it isn't *really* a full-on, butt-clenching, hardcore, intrinsic, I-can-taste-it-in-the-air null"
"Yeah not really feeling it either. It's not giving me the typical null-goosebumps."
"Oh, I know! Let's make it a pretend-null, where the actual type totally depends on the layer of the application!"
"Yeah developers love ambiguous random conversions!"

Oh gosh.. i can finally understand the CV and application nightmare stories... We're getting new people in, and there are quite a few interesting ones.

0) pages of randomly placed info. PAGES. I'm lost in there!!

1) no basic info whatsoever. Like, no nationality(we're recruiting internationally), no birthdate, barely his name and email. I know that the first ones are not really needed for the job, but they're still customary.

2) entry level back and/or frontend job. This guy's a phd graduate, working research with big data in a bio-something department. We're a web startup.

3) there are some listing so much unrelevant stuff, I'm not even sure if they meant to apply to us.

4) (my favourite) email subject: application, email body: empty, attached: short_application.doc ("hi, this is an application to the posted job. Best regards, Name") WAIT WHAT?

Tips from the "oh that wasn't the best idea" category: Don't store "date of birth" as UTC date/times.

Just found the most embarrassing security hole. Basically a skelleton key to millions of user data. Names, email addresses, zip codes, orders. If the email indicates a birthdate, even more shit if you chain another vector. Basically an order id / hash pair that should allow users to enter data AND SHOULD ONLY AUTHORIZE THEM TO THE SITE FOR ENTRING DATA. Well, what happend was that a non mathing hash/id pair will not provide an aith token bit it will create a session linked to that order.

Long story short, call url 1 enter the foreign ID, get an error, access order overview site, profit. Obviously a big fucking problem and I still had to run directly to our CEO to get it prioritized because product management thought a style update would be more important.

Oh, and of course the IDs are counted upwards. Making them random would be too unfair towards the poor black hats out there.

if(system.date == birthdate)
Age++;
else
Keep_surviving! ;-)

A user didn’t remember creating an account and didn’t understand why they received an “account created” email. Best case: this person just forgot. Worst case: someone impersonated them.

I look up this person’s order history and see only one order in the database. The account was created right after the order. Order was for $10k. I’m thinking, oh shit was there a fraudulent payment?!

I dig deeper and see it’s actually for a membership renewal. And our records are showing a birthdate for 1937. Now I’m thinking, ok I have a high roller who is very old. So I have to be REALLY careful about my response to this person.

I manage to reproduce the scenario and…it’s totally user error. The person just forgot they created an account. I’m letting customer service handle the correspondence for this. Sorry CS.

An Italian provider in his webservice documentation defines a date (birthDate) as string. Why ?
I discovered the format provided is d-m-Y, my database store it as Y-m-d and my users prefer d/m/Y (as many Italians).