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:“Concurrency diagrams are very simple and usually quick to create. They force you to put your assumptions in front of everyone to see, including yourself. Sometimes the act of creating a concurrency diagram can change your own mind about how different parts of a system should be sequenced. All you need are boxes, arrows and text.”
tl;dr:“Because of all that evolutionary pressure, there are many little cues and behaviours embedded in our personalities, which help to make society work. The way we stand or sit, the way we speak, the direction we choose to look, what we do with our hands; these are all ways in which we project our status. Every interaction between people is filled with these little status transactions and most of the time we don't even realise it.” Phil discusses how this impacts engineering orgs and how to manage accordingly.
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:“Here are some ways that I've seen engineers pathologically try to elevate their own status: (1) Build a new thing that doesn't need to exist. (2) Build a thing using different technology that the rest of the team are unfamiliar with. (3) Rewrite from scratch something that was already working fine. (4) Work on easy changes that touch many lines of code but don't impact the business. (5) Claim to be working on big and/or complicated changes, which nobody else has visibility of.” Phil discusses how to defuse these games early before they escalate.
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.”