Skip to content
ROOT
META

Blog Template

For posts on abukix.dev/blog. Engineering writing — opinionated, specific, time-stamped. Not LinkedIn motivational content.

The blog is the public-facing surface where ROOT’s internal artifacts (patterns, runbooks, postmortems, weekly logs) get translated into posts the wider engineering audience can read. It’s not a separate effort — every good post is a promotion of something that already exists in ROOT: a pattern entry that hit DEEP, an incident worth sanitizing, a year-end milestone worth reflecting on.

The voice is the same voice you use in phase docs and postmortems: confident, direct, technical, opinionated where the trade-off is real. Marketing-speak (“robust,” “leverage,” “scalable”) is banned. Hot takes designed to drive engagement are banned. The bar is did this teach a working engineer something they couldn’t easily get elsewhere.

The blog also functions as a routing surface. Posts cross-link back to the pattern library, project plans, and ops-handbook — so a reader who lands on a post about Iceberg vs Delta finds the pattern entry, the project that uses it, and the runbooks that operate it. The blog is the front door; the docs are the rooms.

Template

Copy into abukix/portfolio/posts/{NN}-{slug}.md:

---
title: "<Post title>"
slug: <kebab-case>
date: YYYY-MM-DD
tags: [<topic>, <year-N>]
draft: false
---


# <Post title>


> One-sentence elevator pitch. What this post is about + why anyone should care.


## The problem


What's the situation that motivates the post? Be specific. (3-4 paragraphs.)


Concrete shape:


> Year 3 of basecamp landed a lakehouse on top of MinIO. Two table formats are credible — Iceberg and Delta Lake. The phase doc said "pick one, build for a quarter, then revisit." This post is the revisit: nine months of operating Iceberg later, here's what I'd tell past-me.


## The pattern


What's the underlying pattern this is an example of? Link to your `patterns/` library entry if applicable.


> The deeper pattern is "table format = metadata layer over an object store." Iceberg and Delta both implement it; they differ on commit semantics, catalog story, and write contention. The pattern outlasts the choice.


## The implementation


The concrete thing you did. Code blocks, diagrams, screenshots. (5-10 paragraphs.)


Show the actual config, the actual catalog choice, the actual `OPTIMIZE` cadence, the actual workload shape. Generic prose is the failure mode here.


## What I learned


The honest "this worked / this didn't" + what you'd do differently.


- "Iceberg's metadata file count grew faster than I expected on hourly writes; weekly `OPTIMIZE` wasn't enough."
- "Nessie's branching model paid for itself the first time I needed to roll back a bad ingest."


## What I'd do differently next time


A specific action you'd take, not a vague hand-wave.


> "I'd configure `write.metadata.delete-after-commit.enabled=true` from day one, not 4 months in after the metadata directory hit 80GB."


## What's next


What's the follow-up? What's blocking it?


> "Year 4's ML workloads need upsert semantics. Iceberg v2 row-level deletes are the path; the blocker is the Spark connector version pinning. Will revisit when the connector lands."


## References


- Pattern library: [table-formats](#) (DEEP since 2026-04)
- Related ROOT phase: [Year 3 Phase 16 — Lakehouse](#)
- ops-handbook: [postmortem 2026-W18 — Iceberg metadata cliff](#)
- External: [Iceberg spec](https://iceberg.apache.org/spec/), [the original paper](#)

How to write a good post

Five rules:

  1. Specific, not generic. “I built basecamp’s monitoring stack” not “thoughts on monitoring.”
  2. Time-stamped. “As of 2026-08, Cilium is…” not “Cilium is…”
  3. One pattern per post. Don’t bundle 3 ideas into one post; split.
  4. Show your work. Code blocks, command outputs, screenshots. Not abstract advice.
  5. Honest “what didn’t work” — bigger differentiator than the win. Most engineering blogs sanitize the failures; the ones that don’t are the ones engineers trust.

What kinds of posts work for the abukix brand

Three genres:

  1. The journey post — “Building basecamp at end of Year 3 — what I learned.” Tied to a launch or year-end milestone. Draws directly from the weekly logs of that period.
  2. The pattern deep-dive — “Iceberg vs Delta Lake: I built both for a year. Here’s what’s different.” Promoted from a pattern library entry that hit DEEP.
  3. The incident postmortem (sanitized) — “How my homelab Postgres went down at 3am, and what I rewrote.” Connects ops-handbook content to public reading. Strip identifiers; keep the system analysis.

What kinds of posts to AVOID

AvoidWhy
Tutorial-style “how to install X”A million such posts exist; not differentiated
Hot-take opinion piecesBurns trust
AI-generated motivational contentWorse than not posting
Long marketing-speak about “robust” / “scalable”Engineering writing has no marketing words
Posts not backed by a pattern, project, or postmortemThe cross-link is the credibility — without it, the post is just an opinion

Cadence

Aim for 1 post / month during ROOT (12 posts/year × 5 years = 60 posts by graduation).

Loud-launch months get 2 posts (the announce + the deep-dive). Quiet months can skip without guilt — quality > schedule.

Every post should link to:

  • The relevant pattern library entry (if applicable)
  • The relevant phase doc / project PLAN
  • Your ops-handbook/ if drawing from a real incident

The cross-linking turns the blog into a marketing surface for the OSS work. Visitors who click links land in the project / pattern / runbook — exactly where you want them.

Cross-reference