Introduction

Matklad argues that sustainable engineering hinges on turning manual rituals into automated, repeatable habits. The post presents a set of mechanical practices that, when combined, keep a codebase healthy, reduce toil, and foster a culture of continuous improvement.

The Power of Weekly Releases

The most impactful trick is to release every Friday. By keeping releases small and frequent, developers avoid the “feature‑bunching” trap that forces large, risky deployments. The mental overhead of assessing risk drops to a simple mental check of a week’s work, and the pressure to push a release through a weekend is eliminated. When a release is skipped, the friction is low enough that a single message can cancel it, ensuring that the team never feels compelled to force a release at the expense of quality.

Automating the Merge Queue

A key enabler of weekly releases is the merge queue. Instead of developers waiting for continuous‑integration (CI) to finish before deciding whether a pull request can be merged, a bot advances the tip of the master branch only after a green build. This inversion of the traditional workflow means that the CI pipeline stays clean: flaky or unrelated failures cannot block a critical change, and every merge is guaranteed to pass the full test suite.

The merge queue also encourages a holistic view of CI as a set of invariants. If the repository can always be brought to a state where all tests pass, the team can treat every automatable check as a test. This mindset turns linting, formatting, and other quality gates into first‑class tests.

Tidy Scripts as Code‑Quality Tests

Borrowing from Rust, the author recommends a tidy file that collects project‑specific linting checks. The tidy script is a lightweight test that runs as part of the CI pipeline, catching issues such as:

  • Large binary blobs in history
  • Excessive line or function length
  • Usage of disallowed standard‑library APIs
  • Placeholder comments like // FIXME
  • Dead code in languages with lazy compilation

Because the tidy file is just a script, adding a new rule is trivial, and the CI remains fast.

DevHub: The Internal Whiteboard

Another habit is maintaining a static directory that is automatically deployed from the master branch as an internal web page. This “DevHub” acts as an office whiteboard, providing real‑time visibility into:

  • Release rotation
  • Benchmark and fuzzing results
  • Issues that need triaging

The simplicity of JSON files in the repository makes DevHub a lightweight database that can be updated by any developer.

Micro Benchmarks as First‑Class Tests

Micro‑benchmarks are notoriously fragile. Matklad proposes treating each benchmark as a test that can be run in two modes:

  1. Test mode – run the benchmark with minimal parameters, compile in debug, and suppress output.
  2. Benchmark mode – run with large parameters, compile in release, and print timing results.

By chaining benchmarks onto the existing test framework, the codebase avoids a separate entry point for benchmarks, reducing bitrot and making it easier for new contributors to add or update benchmarks.

The Bigger Picture

These mechanical habits share a common theme: they transform the development process into a set of simple, repeatable actions that reinforce code quality and reduce human error. When a system is designed to enforce invariants automatically, the human engineer’s job shifts from firefighting to continuous improvement.

The approach is not limited to Rust or TigerBeetle; any project can adopt weekly releases, a merge queue, tidy scripts, and a lightweight DevHub to achieve the same benefits.

Source: https://matklad.github.io/2025/12/06/mechanical-habits.html