Databases
Post #1309 · source on Telegram
When Your Name Is an Unhandled Exception
Description
A screenshot of a tweet from user 'yeff' (@yephph) that expresses confusion with the text 'I- What does this even mean'. The tweet contains an image of an email or message addressed to 'Hello Jeffrey,'. The message reads: 'Unfortunately due to company policy, we are unable to offer positions to people with the name Jeffrey since it will not work with our database schema'. The tweet is dated 4:03 AM, 12 Apr 20. The humor lies in the absurdity of a database schema being so poorly designed that it cannot accommodate a common name like Jeffrey. For developers, this suggests a catastrophic level of technical debt, hardcoded values, or a complete failure in data validation, making the company's excuse both hilarious and terrifying
More like this
More like this in Databases →
Use J and K for navigation
Comments
7Comment deleted
Their schema probably has a UNIQUE constraint on `first_name` and they already hired a Jeffrey. It's either that or their entire backend is a single regex that panics on the letter 'J'
Welcome to enterprise tech, where rejecting every “Jeffrey” is still cheaper than ALTER TABLE first_name MODIFY VARCHAR(32)
Somewhere there's a senior engineer who hardcoded "Jeffrey" as the test user in production, and now the entire authentication system depends on it being unique
When your database schema is so rigidly designed that it becomes your HR department's excuse generator. This is what happens when someone takes 'fail fast' literally and applies it to the hiring pipeline - apparently they've got a CHECK constraint on applicant names. One can only imagine the schema: CREATE TABLE employees (name VARCHAR(50) CHECK (name != 'Jeffrey')) - because why fix your data model when you can just reject perfectly qualified candidates? It's the ultimate manifestation of 'it's not a bug, it's a feature' meeting 'we can't change it, it's in production.' Somewhere, a senior architect is explaining that migrating to support the name 'Jeffrey' would require a three-sprint epic and extensive regression testing
Nothing says 'data-driven HR' like an ATS with first_name VARCHAR(6) and a CHECK constraint forbidding 'Jeffrey'; the approved migration path is legally renaming yourself to 'Jeff'
When your legacy schema's VARCHAR(3) finally enforces HR diversity quotas - Jeffs denormalized on sight
At this company HR is ACID-compliant: “Jeffrey” violates the CHAR(6) constraint, so we roll back the candidate