Lecture Friday: Intro to Empirical Software Engineering: What We Know We Don't Know
Facts? Get out of here! We rely on sophistry alone in this field, sir.
Facts? Get out of here! We rely on sophistry alone in this field, sir.
https://infrequently.org/2024/01/performance-inequality-gap-2024/
I keep talking about performance, this is exactly what I'm talking about.
I really like this mental model. It's not that hard to succeed if your idea of success is reasonable.
https://wiki.postgresql.org/wiki/Don't_Do_This
Huge list of great tidbits.
https://postgres.ai/blog/20210831-postgresql-subtransactions-considered-harmful
Great explanation on why carelessly wrapping and rewrapping things with transactions in your ORM will cause you problems.
https://postgres.ai/blog/20220525-common-db-schema-change-mistakes
Know your tools.
The trick to reading code is to stop trying to play computer in your head. It's also how you debug code, modify other's code, etc.. You're sitting in front of a computer. Let it compute things for you. Said another way, don't think when you should compute and don't compute when you should think.
https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/tr-2008-11.pdf
Design for Conway's Law, not against it. Seriously, what this shows is that software that has multiple people working on it who's lowest common manager is high up in the org (i.e. they don't share direct manager but only a director or worse vice president) have the highest number of bugs in them.
https://blog.danslimmon.com/2023/08/11/squeeze-the-hell-out-of-the-system-you-have/
Getting performance right is important. Deciding to change everything and rewrite it all because you can't be bothered to measure and try and fix things is an all too common hubris.
Very simple concept, if your writing isn't obviously valuable to the reader it's worthless. Acting on this is much harder, but at least with the right direction you can aim to improve.