tl;dr:What does a good code review look like? Phil outlines 5 things you want to get right as a reviewer: (1) The description: “Is there one? Does it make sense? Does it include all of the information required to understand the code?” (2) The code: Build a mental model of the code, then ask yourself: "Am I happy to maintain this?" (3) The tests: Compare the tests and code side-by-side. Look for things that seem missing or out of place. Ask questions about anything that doesn't match your expectations. (4) Commenting: Be considerate, honest and open-minded. (5) Approval: Withhold approval until you're confident that you fully understand the change.
tl;dr:Several PostgreSQL patterns that might not be immediately obvious to many developers including: (1) Always define explicit ON DELETE semantics. (2) If in doubt, use ON DELETE SET NULL. (3) Mutually exclusive columns. (4) Prohibit hidden nulls in jsonb columns. (5) Declare your updated\_at columns NOT NULL to make sorting easier.
tl;dr:Phil shares lessons learned from production outages caused by misusing Redis. They highlight the importance of handling concurrency by sharding data across multiple instances, avoiding long-running operations in scripts, setting memory usage alerts, and using the appropriate Redis abstractions. Serializing objects to JSON for storage is discouraged, and understanding tradeoffs between data structures can prevent future issues.
tl;dr:(1) Aggregate other services into your app’s healthcheck. (2) Set a short timeout on healthcheck requests. (3) Set a long timeout on healthcheck requests. (4) Leave a long delay before starting healthchecks on new instances. (5) Set a low threshold on consecutive failures before turning unhealthy. (6) Set a high threshold on consecutive successes before turning health.
tl;dr:“One of my stock interview questions goes: "When picking between dependencies to use in production, what factors contribute to your decision?" I'm surprised by how often I receive an answer along the lines of "Github stars" and not much else. I happen to think Github stars is a terrible metric for selecting production code, so this post sets out my idea of a healthier framework to evaluate dependencies.”
tl;dr:(1) Keep the default value for work\_mem. (2) Push application logic into Postgres functions and procedures. (3) Use lots of triggers. (4) Use NOTIFY heavily. And more.
tl;dr:These steps are not specific to a particular language or paradigm, Phil's explains each of the following debugging steps: (1) Reproduce the bug. (2) Reproduce it again. (3) Don't reproduce it. (4) Understand the code. (5) Observe state. (6) Write down what you (think you) know. (7) Rule things out. (8) Walk the dog. (9) Rewrite a component. (10) Write a failing test case. (11) Fix it.