4 ms·

my framing of this is "Data outlasts Code, yet Code keeps winning" - i think data/schema design should be much more emphasized in bootcamps and college classes

by swyx 2y ago

my framing of this is "Data outlasts Code, yet Code keeps winning" - i think data/schema design should be much more emphasized in bootcamps and college classes but sadly it seems most of us have to learn these painful lessons on the job. https://www.swyx.io/data-outlasts-code-but https://www.swyx.io/data-outlasts-code-but

shubb 2y ago
Your link did not outlast your comment. I'd love to read about schema design if you have an article you liked...
- swyx 2y ago
  i really liked the schema design exercises in https://www.dynamodbbook.com/ https://www.dynamodbbook.com/ and ofc there's the classic Kleppmann DDIA book
arcbyte 2y ago
I've never bought this distinction between code and data. They are two distinct things but they are inseparable. Neither outlasts the other.
ElevenLathe 2y ago
Unfortunately most non-{architect, principal} engineers have little say over the structure of existing data, and often no ability to change it. They are given APIs (controlled by teams they aren't allowed to talk to) and requirements (that they aren't allowed to question or modify) and have to crank through tickets. This seems like a massive waste but in theory it's because, while things take much longer and end up much worse this way, they are at least predictable and resilient to any one engineer quitting. Even if not, the people writing the checks think this, so that's what gets done.
snowfarthing 2y ago
In my career as a web developer I have worked on accounting systems three or four times now. At one point, it occurred to me that the quirky feature of Common Lisp's FORMAT that prints numbers as English names was very likely put there to make it easier to print checks for payroll! I have often reflected on how it would have helped me if I had been required, or even merely strongly encouraged, to take an "Introduction to Accounting for Programmers" class, that would discuss payment processing, invoices, accounts receivable, even how to store dates and times (UTC for the win, darn it!) -- if more developers understood these things from the outset, I strongly suspect a lot of systems would be more robust than they are now!

by swyx 2y ago

shubb 2y ago

Your link did not outlast your comment. I'd love to read about schema design if you have an article you liked...

swyx 2y ago
i really liked the schema design exercises in https://www.dynamodbbook.com/ https://www.dynamodbbook.com/ and ofc there's the classic Kleppmann DDIA book

arcbyte 2y ago

I've never bought this distinction between code and data. They are two distinct things but they are inseparable. Neither outlasts the other.

ElevenLathe 2y ago

Unfortunately most non-{architect, principal} engineers have little say over the structure of existing data, and often no ability to change it. They are given APIs (controlled by teams they aren't allowed to talk to) and requirements (that they aren't allowed to question or modify) and have to crank through tickets. This seems like a massive waste but in theory it's because, while things take much longer and end up much worse this way, they are at least predictable and resilient to any one engineer quitting. Even if not, the people writing the checks think this, so that's what gets done.

snowfarthing 2y ago

In my career as a web developer I have worked on accounting systems three or four times now. At one point, it occurred to me that the quirky feature of Common Lisp's FORMAT that prints numbers as English names was very likely put there to make it easier to print checks for payroll! I have often reflected on how it would have helped me if I had been required, or even merely strongly encouraged, to take an "Introduction to Accounting for Programmers" class, that would discuss payment processing, invoices, accounts receivable, even how to store dates and times (UTC for the win, darn it!) -- if more developers understood these things from the outset, I strongly suspect a lot of systems would be more robust than they are now!