These were impactful to me, one way or another.
Comics #
Did you just tell me to... is a classic from @jrecursive.
Migrations are a fact of software engineering life, and this, by Manu Cornet, is on point.
Zines #
Julia Evans's comics and zines are a national treasure. I
learned some options to strace! I learned about CSS! I've shared the post on
SQL queries don't start with
SELECT
many times!
Code Review #
Google published The Standard of Code Review which includes the following:
In general, reviewers should favor approving a CL once it is in a state where it definitely improves the overall code health of the system being worked on, even if the CL isn’t perfect.
Visualization #
I learned a lot from the ggplot2 book. I've followed Jeff Heer's work including Vega Lite, and you could do much worse than reading some of it.
Organizations #
Matt Eccleston wrote a blog post on code-centric versus product-goal-centric teams.
Typescript #
My friend Dan wrote Effective Typescript.
Testing #
Sometimes, coming up with the right approach to testing a problem is the key to solving the problem. Don't take just my word for it; here's FoundationDB
Testing and debugging distributed systems is at least as hard as building them. Unexpected process and network failures, message reorderings, and other sources of non determinism can expose subtle bugs and implicit assumptions that break in reality, which are extremely difficult to reproduce or debug. The consequences of such subtle bugs are especially severe for database systems, which purport to offer perfect fidelity to an unambiguous contract. Moreover, the stateful nature of a database system means that any such bug can result in subtle data corruption that may not be discovered for months. FDB took a radical approach— before building the database itself, we built a deterministic database simulation framework that can simulate a network of interacting processes and a variety of disk, process, network, and request-level failures and recoveries, all within a single physical process. This rigorous testing in simulation makes FDB extremely stable, and allows its developers to introduce new features and releases in a rapid cadence.
A Quote from The Mythical Man-Month #
When I approach a new code base, I look first at what happens on disk (typically, the database schemas) and what happens across the wire (the RPC definitions like protobuf or thrift files, OpenAPI/swagger/typescript schemas, clicking around in the network tab in Chrome). This quote, from The Mythical Man-Month (Brooks) strikes a chord:
Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious.
Systems #
Tracing. I had the privilege of using
Dapper
while at Google.
X-Trace
is similar. The ad-hoc version of this is to add a random identifier to log statements (especially "canonical log lines") and
pass those identifiers along across RPC boundaries (e.g., via an HTTP X-Trace-Id header).
Add canonical log lines (thanks, Stripe and Brandur Leach, for the write up) to your system. If you can make it queryable with SQL, you have a lovely analytics system!
Nelson Elhage's "What does a cache do?" is a great discussion of why read replicas and caches are different.
In Search Of #
E-mail me if you have pointers to these!
- A history of UI library APIs. How did we get from Apple II graphics to React? These libraries seem so dynamic; I'd love to read a history!
- A picture of the Cauldron visualization for a CDH build. (This is very specific!)