Issue #364

tl;dr: Will discusses the concept of a type of work called "reminiscing": when under pressure, most people retreat to their area of highest perceived historical impact, even if it isn’t relevant to today’s problems. "When you see your capable CEO start to micromanage words in a launch email, or your talented CTO start to give style feedback in code reviews, take it for what it’s worth: they’re reminiscing. If you dig deeper, they’re almost certainly panicking about something entirely unrelated."

tl;dr: "This article is about a few quick thumb rules I use when writing shell scripts that I’ve come to appreciate over the years. Very opinionated." 15 rules in total, including: (1) Use bash. Using zsh or fish or any other, will make it hard for others to understand / collaborate. Among all shells, bash strikes a good balance between portability and DX. (2) Just make the first line be #!/usr/bin/env bash, even if you don’t give executable permission to the script file.

tl;dr: Nicolas identifies 2 problems: (1) HTTP status codes were specified for human-to-machine interactions via browsers, not for machine-to-machine interactions via APIs. Hence, selecting a status code that maps one-to-one to the use case is rarely straightforward. (2) The error payload's structure is unimportant if a single organization manages the client and the API provider. However, the issue occurs when a team decides to use a third-party API.

Quastor is a free newsletter that sends summaries of big tech engineering blog posts. Learn about the strategies and technologies companies use to scale up to serve millions of users. Past articles include How WhatsApp scaled to 1 billion users with only 50 engineers and How PayPal prevents fraud with Graph Databases.

Join 30,000 developers who read Quastor. It's Free!