Skip to main content
Settings
Search
Appearance
Theme Mode
About
Jekyll v3.10.0
Environment Production
Last Build
2026-05-27 23:28 UTC
Current Environment Production
Build Time May 27, 23:28
Jekyll v3.10.0
Build env (JEKYLL_ENV) production
Quick Links
Page Location
Page Info
Layout article
Collection posts
Path _posts/technology/2021-10-27-build-destroy-repeat-mastery.md
URL /posts/build-destroy-repeat-mastery/
Date 2021-10-27
Theme Skin
SVG Backgrounds
Layer Opacity
0.6
0.04
0.08

Build, Destroy, Repeat: How Iteration Becomes Mastery

The Setup Trap

The first time you wire up a stack — say a Jekyll site behind a Cloudflare proxy or a Docker Compose file for a small API — the tutorial does most of the thinking for you. You copy commands. Something runs. You move on.

A week later, you cannot explain why it works. That is not a learning problem; it is a repetition problem.

The Practice That Actually Sticks

The fastest way to convert a tutorial into knowledge is to throw the result away and rebuild it from scratch without the tutorial. The first round is fluent only because someone else made every decision for you. Rounds two and three force you to make those decisions yourself.

Three loops is usually the sweet spot:

  1. Build with the tutorial open. Get the happy path working end-to-end.
  2. Destroy everything and rebuild from memory. This is where you find the gaps. Notes are allowed; the tutorial is not.
  3. Rebuild with a twist. Change the framework version. Swap SQLite for Postgres. Add a feature the tutorial did not cover.

By the third pass, the moving parts are no longer abstract — they are decisions you have personally made and re-made.

What “Destroying” Actually Means

Deleting the directory is the safe version. The interesting version is keeping the artifact and breaking it on purpose:

  • Comment out a dependency and watch what fails.
  • Remove an environment variable and follow the error.
  • Swap a working command for a near-miss and read the message carefully.

Errors written under controlled conditions teach faster than errors that surprise you in production. You already know what changed; the only question is what happens next.

When to Stop

Iteration has diminishing returns. The signals you are ready to move on:

  • You can sketch the architecture on a whiteboard without checking your notes.
  • A new feature request prompts a design discussion, not a Google search.
  • The setup steps feel obvious enough that you start optimizing them — scripting installs, adding pre-commit hooks, sharpening the README.

That last one is the tell. When you find yourself caring about the seams instead of the parts, you have internalized the system. Pick a new one.