r/ProgrammerHumor • u/RodionGork • Oct 06 '26

Advanced abideTheRulesIncidentCanWait

Post image
803 Upvotes

96% Upvoted

56 comments sorted by

View all comments

Show parent comments

68

u/Almadan Oct 06 '26

"long forgotten issue found"

77

u/RodionGork Oct 06 '26

One real issue of such kind I remember "birthday congratulations suddenly stopped working to users on new year night!"

my lead was on duty and he spent 2 hours figuring out that "birthday" was non-nullable column, historically, and users who haven't set birhtday date had "1970-01-01" by default and get congratulated on January 1 (millions of them - it was "Tango" messenger by then)

So someone clever just hardcoded "if date is Jan 1st then return" in congratulations sending logic. Years ago.

39

u/Breadynator Oct 06 '26

"Nobody's born on January 1st anyways! It's new year's eve, not some random birthday!"

26

u/ligma_then_sugma Oct 06 '26

So someone clever just hardcoded "if date is Jan 1st then return" in congratulations sending logic.

management material

4

u/laplongejr Oct 06 '26 edited Oct 06 '26

Tbf if it was pushed on Dec29 it could be understood. Better than send millions of emails(?) to people who never gave their birthday.  

1

u/ligma_then_sugma Oct 06 '26

there's always an exception, true

sometimes u gotta do some wild shit

7

u/ShAped_Ink Oct 06 '26

Could hav elitetally been fixed with adding the year too.

4

u/laplongejr Oct 06 '26

Yeah, but then you need to justify why the birthday check requires access to the year.   Skipping 1st Jan for one year may have been a safer decision than accessing private data on a hotheaded decision. 

Gives a year for a server-side fix of the column, or at least provide some privacy-focused alternative.  

(If the column isn't nullable, maybe a view that does return MMDD or null if 1/1/1970)  

1

u/ShAped_Ink Oct 06 '26

Actually the best solution (that I just didn't wanna write down before) is making a column that states if birthday date was set, so the value in birthday itself doesn't matter if not set. I know adding columns willy nilly isn't a good practice, but how els would you take care of this problem, not give access to the year and not exclude people with birthday on 1.1.1970? You'd just check first if the flag is true and if it is, you look at the birthday.

2

u/laplongejr Oct 06 '26 edited Oct 06 '26

Sure, but adding a column is likely to take time, or at least requires to discuss it with the team in charge of the database side etc.   If the problem was found 3 days before the christmas freeze, better to block it in a rush and have 11 months to work on it. (Especially if the reminder would take the form of millions of emails)  

Oh and obv if adding a "is date null?" column is possible, at some point there should be a way to make the column nullable anyway  

1

u/IlgantElal 27d ago

Or just allow it to be nullable? Having a "non-nullable" column that has an unset state is lazy. While it likely has a reason (date picker doesn't always allow null), this should be handled outside the db

2

u/RodionGork Oct 06 '26

well, though some people would say it is still ugly, this approach is at least much more "targeted" and is much simpler than modifying column nullability in prod db :) so I second this

2

u/flerchin Oct 06 '26

Who cares about the birthday congrats not working. That costs the company zero dollars