Glean 拾遗
Recent picks

3picks · chronological

09-16

20 Things I've Learned in my 20 Years as a Software Engineer

A Simple Thread co-founder distills 20 years of engineering into 20 opinions, prefaced by an honest account of his context: small teams and startups first, then consulting inside large companies, then growing his own firm from 2 to 25 people. The list runs against received wisdom: building the right thing is harder than building it well; the best code is code you never write; every system eventually rots, so aim for continuous improvement rather than elegance; the 10x programmer is a myth and the real win is keeping 0.1x programmers off the team; data outlives your codebase; interviews predict almost nothing about teammates; prefer durable "shark" technologies to fashionable ones. Aimed at working engineers who want to sanity-check their own judgment, with the caveat that all advice is contextual.

www.simplethread.com · 14 min · Career Advice · Engineering Culture · Essay
09-14

Healthy Documentation: A CTO's Case for Docs-First Engineering

A CTO's field notes on running a docs-first engineering culture: replace half-hour check-ins with a one-page memo, budget documentation time explicitly in estimates, and require a short "why X over Y" paragraph on every merged feature. He is candid about the failure modes — stale pages are worse than none, and some workarounds should be fixed in code rather than explained in three paragraphs of handbook. Concrete mechanisms include a lightweight CI check that fails the build when a new analytics event ships without a matching wiki entry, ADR and post-mortem templates, the Diátaxis split between tutorials and reference, and a part-time "docs gardener" who prunes dead links.

vadimkravcenko.com · 11 min · Developer Tools · Documentation · Engineering Culture
08-31

Why senior developers fail to communicate their expertise

This post frames senior developers' communication failure as a clash between two business loops. The first loop tries to reduce market uncertainty by shipping fast; the second loop keeps paying customers served by controlling system complexity. Once a company has customers, both loops run at once, so developers talk in terms of complexity while everyone else worries about uncertainty. The author argues that senior developers' real skill is refusing unnecessary work and reusing existing software, and that they should express it as 'Can we try something quicker?' — a phrase that acknowledges the business's need for speed while leaving room for simplification. He also proposes separating the fast 'Speed' system from a stable 'Scale' system, and warns that AI accelerates the first loop while degrading understandability and stability in the second, without taking responsibility. A thoughtful read for engineers interested in organizational communication and system evolution.

www.nair.sh · 13 min · Engineering Culture · Software Engineering · System Design