Junior Dev Brags About 1000 Lines of Prisma Schema in 3 Hours
Description
A quote tweet from Shayan (@ImSh4yy) saying 'POV: you're about to find out why senior devs spend weeks/months on database design.' The quoted tweet from John doe (@sachindev69, Oct 4) reads: 'Today I wrote 1000+ lines of code using @prisma. And literally it takes only 3hr to design the database. Now I am exhausted and I think I deserve some goodies.' Below is a photo of a screen showing Prisma schema code around line 1047-1072, featuring models like 'Applications' with fields (id, status, User, userId), an enum 'applicationStatu' (truncated name, missing the 's'), and a 'Hackathons' model with fields (id, title, tagLine, logo, banner). The code shows classic junior mistakes: the enum name is misspelled as 'applicationStatu' instead of 'applicationStatus', the schema structure suggests poor normalization, and the pride in LOC count reveals the misconception that more code = more productivity
Comments
24Comment deleted
1000+ lines of Prisma schema in 3 hours is impressive -- that's roughly the same speed at which you'll be rewriting it once you discover what database normalization is
Scaffolding a schema in three hours is easy - just reserve the rest of the quarter for the migration that fixes “applicationStatu” after prod dashboards are already hard-coded to it
Nothing says 'production-ready schema' quite like optional User relations and string fields for everything - can't wait for the sequel where they discover why we have foreign key constraints, indexes, and why 'logo' probably shouldn't be a String field in the database
Ah yes, the classic '3 hours of database design' followed by 3 months of migration hell when you realize your optional User relationship and String-based IDs don't scale, your enum can't be extended without a migration, and you've accidentally created a many-to-many relationship that should have been many-to-one. Senior devs don't spend weeks on database design because they're slow - they're preemptively debugging the production incidents that junior devs schedule for 2 AM on a Saturday
John's schema proves every user-team relation spawns three junction tables - like a fractal of indirection no query planner can love
Anyone can ship a 3‑hour Prisma schema; seniors spend three weeks deciding cardinality and constraints because backfilling a misspelled enum on 200M rows teaches you CAP: Can’t Alter in Production
Designing the schema in 3 hours just means your next 3 quarters are spent writing zero‑downtime migrations to fix pluralized models, optional FKs, and an enum that will inevitably need a fourth state during Black Friday
application statue Comment deleted
It's statu, plural form of stat (according to slop) Comment deleted
YES we Absolutely NEED UUID AS Primary KEY Comment deleted
jokes aside its has its own advantages Comment deleted
aside from GIGA CORP like system its best used in loggings,traces it can act as timestamp and UUID what you use it for? Comment deleted
any customizable parameter system would run over bigint quite fast while being run in relatively active prod. or any other case of m-m relation table between 2 big tables that could be autogenerated Comment deleted
UUIDs are inevetible in distributed systems, as you don't have single issuing service for incremental bigint Comment deleted
good enough for a first prototype Comment deleted
Fuck prisma Comment deleted
all my homies use drizzle Comment deleted
That one is REJECTED one I guess Comment deleted
Oops, ment for the comment above Comment deleted
humor brigade pls Comment deleted
the implication is that AI-generated code will suck massive cock "POV" means it will be John who finds it out Comment deleted
literally just learn SQL and it looks exactly the same Comment deleted
looks even better Comment deleted
Why prisma and not atlas? Comment deleted