Glean 拾遗
Daily · timeline

A few picks a day.

Wed, Sep 16, 2026 3picks
← 09-15
Calendar ▾
2026 · 09
MoTuWeThFrSaSu ·123456789101112131415161718192021222324252627282930
has picks today
06:00

antirez on code comments: a nine-part taxonomy from Redis

antirez 拆解 Redis 源码:代码注释的九种类型

antirez works through the Redis source (unstable branch, 32e0d237) to argue that comments are not a crutch for weak code. He sorts comments into nine kinds, namely function, design, why, teacher, checklist, guide, trivial, debt and backup, judging the first six useful and the last three suspect. His two reasons: many comments carry information the code cannot express, such as why a statement is there instead of a more natural alternative, and comments lower the reader's cognitive load, as when scripting.c annotates the Lua stack layout after every call. Each category comes with real examples: the replication code that swaps replication IDs before freeing the backlog, the expire.c loop that increments current_db early, the trigonometry behind LOLWUT, the checklist duty created by Redis's 4-bit type field, and the TODO left in t_stream.c. Reading and writing comments, he argues, is bug hunting and design review in disguise.

antirez.com · 31 min · Code Comments · Code Readability · Redis · Software Engineering · Writing
06:00

Write code that is easy to delete, not easy to extend.

好代码容易删掉,而不是容易扩展

The thesis: treat lines of code as lines spent, not lines produced. Every line carries a maintenance cost, and abstractions built for reuse bind callers to both the intended and unintended behaviour of an implementation, making later change more expensive. The goal should be disposable code, not reusable or extensible code. The author walks through tactics: don't write code at all; copy-paste a few times before extracting a function; keep stateless, application-agnostic helpers in a util directory with one utility per file; accept boilerplate so static library code stays away from fast-changing business logic; layer policy over protocol the way requests wraps urllib3; let one big ball of mud hold things together; split modules by what they don't share rather than by shared functionality; use uniform interfaces, HTTP caches/CDNs and feature flags as replaceable seams; handle errors at the outer edges (end-to-end principle), as Erlang's supervision trees do by restarting instead of recovering in place. Aimed at engineers maintaining long-lived codebases.

programmingisterrible.com · 20 min · API Design · Code · Essay · Software Engineering
06:00

How to ask good questions about software

提问的技术:先说清你已知什么,再问可回答的事实

Julia Evans argues that asking good questions is a trainable software engineering skill, not a personality trait. Her core technique: state what you already understand, then ask 'is that right?'. She rewrites vague questions ('how do SQL joins work?') into questions with factual answers — is joining N and M rows O(NM) or O(NlogN)+O(MlogM), does MySQL always sort join columns first. She shows the rkt-dev mailing list question where she first wrote down how rkt and Docker store container images differently, then asked why; and the term dictionary she built for Hadoop, Scalding, Hive, Impala and HDFS when joining a data team. She also covers choosing whom to ask (a 5-minute answer that saves you 2 hours is a good trade; the most senior person is not always the right target), stopping an explanation to ask what a term like optimistic locking means, and reading the Etsy Debriefing Facilitation Guide for questions that surface hidden assumptions. She is explicit that asking dumb questions is fine, and criticizes ESR's 'How To Ask Questions The Smart Way' for putting an unreasonable burden on askers. Aimed at engineers ramping up on unfamiliar systems.