DEV Community: Roger Oliveira

Linux from Zero #4 — Users, Groups and Permissions for Platform Engineers

Roger Oliveira — Wed, 02 Sep 2026 13:48:36 +0000

ou deploy a pod. It crashloops. You check the logs and find the most generic error in computing:

Permission denied

Then comes the ritual: someone suggests chmod 777, someone suggests running as root, the pod comes up, everyone moves on. It worked. But nobody knows why — and three months later the same error shows up somewhere else.

Linux permissions are among the easiest topics to explain and the most poorly learned in our field. Not because they're hard, but because almost everyone memorized 755 and 644 without ever understanding where those numbers come from.

Let's fix that.

Linux doesn't know your name — it knows your number

This is the idea that unlocks everything else.

When ls -l shows roger, that's decoration. The kernel has no idea what "roger" is. It knows a number: the UID. Same for groups — the GID.

bash
$ id
uid=1000(roger) gid=1000(roger) groups=1000(roger),27(sudo),999(docker)

The number-to-name mapping lives in plain text files:

bash
$ grep roger /etc/passwd
roger❌1000:1000:Roger Oliveira:/home/roger:/bin/bash

name:password:UID:GID:comment:home:shell

File Holds
/etc/passwd user, UID, primary GID, home, shell
/etc/group groups and their members
/etc/shadow password hashes (root-only)

Why this matters for platform work: a container has its own /etc/passwd, but shares the kernel — and therefore the UIDs — with the host. If the container process runs as UID 1000 and the file on the volume belongs to UID 2000, no username on earth will fix it. It's number against number.

That's why chmod 777 "works": it gives up on the check instead of resolving the mismatch.

The three digits, finally explained

Every file has one owner (a UID) and one group (a GID). Permissions are defined for three classes:

Class Who
user (u) the file owner
group (g) members of the file's group
others (o) everyone else

And three permissions per class:

Letter Value On a file On a directory
r 4 read contents list names inside
w 2 modify contents create/delete/rename inside
x 1 execute traverse
-rw-r--r-- → 6 4 4 → 644
│ │ │ └── others: r--
│ │ └───── group: r--
│ └──────── user: rw-
└────────── type (- file, d directory, l link)

No memorization needed: add 4+2+1 within each block of three.

Common patterns:

644 — owner writes, everyone reads. Config files.
600 — owner only. Private keys and secrets.
755 — owner writes, everyone executes. Binaries and directories.
777 — everyone does everything. This isn't a permission, it's the absence of one.
The directory x trap

This one catches good engineers. On a directory, x doesn't mean "execute" — it means you may pass through.

A directory with r but no x lets you see filenames but open none of them. A directory with x but no r lets you open a file if you know its exact name, but not list the contents.

And it must hold across the entire path. If /data has no x for you, it doesn't matter that /data/app/config.yml is 777 — you'll never reach it.

The command that solves this in five seconds:

bash
$ namei -l /data/app/config.yml
f: /data/app/config.yml
drwxr-xr-x root root /
drwxr-x--- root infra data ← here
drwxr-xr-x app app app
-rw-r--r-- app app config.yml

Found it. data only allows entry for root and members of infra.

namei -l should be the first command of any permission investigation. It walks the whole path, layer by layer.

Changing ownership and mode bash chmod 640 secret.env # octal chmod u+x deploy.sh # symbolic chmod g-w app.conf chmod o= secret.env # zero out "others"

chown app:platform config.yml
chown -R app:platform /opt/app
chgrp platform config.yml

Recursion without collateral damage — capital X applies execute only to directories:

bash
chmod -R u=rwX,go=rX /opt/app

chmod -R 755 would mark every data file as executable. Don't.

The three bits nobody explains Bit Octal Shows as Effect setuid 4000 -rwsr-xr-x runs with the file owner's privileges setgid 2000 drwxr-sr-x new files inherit the directory's group sticky 1000 drwxrwxrwt only the file's owner can delete it

setuid is how passwd lets an ordinary user modify a root-owned file. It's also the first thing an attacker looks for:

bash
find / -perm -4000 -type f 2>/dev/null

setgid on a directory is genuinely useful — it's the right way to build a shared directory:

bash
chgrp platform /srv/shared
chmod 2775 /srv/shared

Every file created there inherits the team's group. This is exactly what Kubernetes fsGroup does under the hood.

Sticky bit is why /tmp is 1777 and not 777. Without it, any user could delete any other process's temp files.

umask — why your file is born 644

umask is a mask that removes bits from the creation default.

bash
$ umask
0022
umask File (666−) Directory (777−)
022 644 755
027 640 750
077 600 700

If a pipeline-generated file comes out with the wrong mode, the cause is almost always the umask of the process that created it.

Where this hits Kubernetes yaml securityContext: runAsUser: 1000 runAsGroup: 3000 fsGroup: 2000 runAsNonRoot: true readOnlyRootFilesystem: true

Now that you understand the model:

runAsUser sets the process UID. It does not need to exist in the image's /etc/passwd — the kernel only wants the number. That's why you see whoami: cannot find name for user ID 1000 in a container with no matching user: nothing is broken, there's just no number-to-name translation.
fsGroup makes the kubelet apply that GID to mounted volumes and turn on setgid on the directory — exactly the mechanism from section 4. Without it, a volume owned by a different UID simply isn't writable.
runAsNonRoot: true makes the kubelet refuse to start a container that would run as UID 0. Cheap and effective.

And the classic trap: fsGroup does not work on NFS. NFS resolves permissions server-side, not client-side. If the export maps to a different UID, no securityContext will save you — the fix belongs on the NFS side.

The investigation checklist

Next time you hit Permission denied, follow this order instead of guessing:

bash
id # 1. who am I really (UID/GID, not name)
ls -ln file # 2. who owns it — -n shows numbers, not names
namei -l /full/path # 3. does the whole path allow traversal?
stat file # 4. detailed mode, including special bits
getfacl file # 5. is an ACL overriding the classic model?

Use ls -ln (with n) instead of ls -l when debugging containers. Seeing the number is what reveals the mismatch — the name hides it.

If all five come back clean and it still denies, look one layer up — SELinux or AppArmor:

bash
getenforce
ausearch -m avc -ts recent
Exercise

Five minutes, on a throwaway box or container:

bash
mkdir -p /tmp/lab && cd /tmp/lab
touch public.txt private.txt
chmod 644 public.txt
chmod 600 private.txt
mkdir shared && chmod 2775 shared
ls -ln
stat shared | head -5
umask

Then answer without looking:

Why can't a user in the same group read private.txt?
What does the 2 in 2775 change about shared?
With umask 0022, what mode does a new directory get?

If all three come easily, you understand the model — you didn't memorize the numbers.

This is part #4 of the Linux from Zero track — free, open material for people building a solid foundation before taking on platform work and Kubernetes.

Full repository: kubernetes-do-zero-ptbr

Linux From Zero Networking, DNS, Ports and Sockets for Platform Engineers

Roger Oliveira — Mon, 31 Aug 2026 17:12:12 +0000

In the first two posts of this series we covered the terminal, files, permissions, processes and systemd. By now you can look at a Linux box and understand what's running and who's allowed to touch what. What's missing is the piece that shows up in almost every real incident: networking.

My thesis for this series stays the same: Platform Engineering starts before Kubernetes. Before you debug a CrashLoopBackOff or an Ingress that won't resolve, you need to know how to investigate networking on the bare operating system. Without that, troubleshooting is just guessing.

How Linux sees a network interface

Every conversation starts with an interface. On modern systems, the reference tool is ip, not the old ifconfig:

ip a

This shows interfaces (lo, eth0, ens160, container/bridge interfaces like docker0 or cni0), assigned IPs, and state (UP/DOWN). To understand where traffic actually goes, the routing table is next:

ip route

The default route (default via ...) decides where a packet goes when no more specific route matches. On platforms with multiple interfaces (production, management, storage), one of the most common operational mistakes is assuming traffic leaves through one interface when the routing table actually sends it through another.

DNS: the most underrated cause of "it's down"

A huge share of incidents that look like "the app is down" are actually name resolution failures. The basic flow on Linux goes through:

the local resolver, historically configured in /etc/resolv.conf (on many modern distros, now managed by systemd-resolved or NetworkManager);
the lookup order defined in /etc/nsswitch.conf (local /etc/hosts before or after DNS, depending on configuration);
the DNS server actually queried, which in corporate environments is usually an internal DNS with forwarders to the internet.

Three commands solve 90% of DNS investigations:

dig example.com
dig example.com +trace
resolvectl status

dig +trace is the most underused one: it shows the full resolution path, from the root servers down to the final answer, and usually exposes exactly where the chain broke — a dead forwarder, an expired cache TTL, a record that no longer exists.

A pattern worth memorizing: "I can't ping the name, but I can ping the IP" is almost always DNS, never networking. Plenty of engineers waste time looking at firewalls and routes when the whole problem is name resolution.

Ports, sockets, and what "LISTEN" actually means

A socket is the meeting point between a process and the network — a (IP address, port, protocol) tuple the kernel uses to hand packets to the right process. To see this live:

ss -tulpn

-t and -u show TCP and UDP sockets;
-l shows only the ones listening — accepting new connections;
-p shows the owning process;
-n skips name resolution, keeping the output fast and literal.

The gap between a service "listening" and a service "actually accepting connections" is where a lot of platform bugs live: a process can be LISTENing on the right port and still refuse a connection because it's bound only to 127.0.0.1 (loopback) while the client comes from a different interface, or because a firewall rule drops the packet before it even reaches the process.

For TCP connection states (SYN_SENT, ESTABLISHED, TIME_WAIT, CLOSE_WAIT), ss -tan gives the full picture — and an abnormal pile-up of CLOSE_WAIT, for example, usually points to an application not closing connections properly, not to a networking issue at all.

A troubleshooting checklist I actually use

When a service "won't connect," the order that wastes the least time is:

Is the port actually listening? (ss -tulpn on the service's host)
On which interface? (0.0.0.0 vs 127.0.0.1 binding explains half of "works locally, not remotely")
Does the name resolve to the right IP? (dig, compared against what you expect)
Does a route to the destination exist? (ip route get <destination-ip>)
Is a firewall/security-group rule dropping the packet somewhere in between?
Does the TCP handshake actually complete? (ss -tan on the client side during the connection attempt)

That sequence — port → bind → DNS → route → firewall → handshake — is an evidence-based investigation, not a guess. It's the same principle behind this whole series: you don't guess where the problem is, you eliminate one layer at a time until only one explanation is left.

Why this matters beyond plain Linux

This entire toolkit reappears, almost untranslated, inside Kubernetes: ClusterIP and Service objects are, underneath, iptables/ipvs rules doing the exact same job of routing a packet to the right socket; CoreDNS is the same name-resolution problem, just running inside the cluster; an Ingress that won't respond usually boils down to the same six steps above, with one more layer of abstraction on top.

Engineers who understand networking and sockets at the OS level debug Kubernetes with evidence. Engineers who don't just memorize kubectl commands and hope for the best.

This is the third post in the Linux From Zero series. Previous posts cover terminal/files/permissions and processes/systemd — hands-on labs live in the kubernetes-do-zero-ptbr repository. Next up: SSH and remote administration.

Connection refused" has three different root causes here's how to tell them apart with evidence

Roger Oliveira — Tue, 25 Aug 2026 15:04:11 +0000

Connection refused" and a silent timeout look like the same failure to whoever's paging you at 2am. They're not. They come from different layers of the stack, and conflating them is why people restart services without ever fixing the actual cause.

The mental model:

Name (DNS) → Route to IP → Port open on target → Filter in the path → App responds

Reproduce it yourself (Docker required):

bash
docker network create rede-lab
docker run -d --name servidor --network rede-lab nginx:alpine
docker run -it --name cliente --network rede-lab busybox sh

Then break each layer independently:

DNS broken — overwrite /etc/resolv.conf inside the client container. Symptom: name doesn't resolve, but the same request by raw IP succeeds. That's your evidence it's DNS, not the network.
Port closed — stop nginx but keep the container alive. Symptom: immediate Connection refused. Evidence: ss -tlnp on the server shows nothing listening on port 80.
Firewall dropping — add an iptables -A INPUT -p tcp --dport 80 -j DROP rule. Symptom: silent timeout, no error. Evidence: tcpdump shows the SYN going out with no SYN-ACK coming back.

Reference table:

Symptom Likely cause Confirming evidence
Name doesn't resolve DNS Direct IP access works
Immediate refusal Port closed ss -tlnp shows nothing listening
Silent timeout Firewall DROP tcpdump shows unanswered SYN
Timeout with RST Firewall REJECT / closed port at OS level RST visible in tcpdump

The same three failure modes show up, renamed, in Kubernetes: DNS → misconfigured CoreDNS, closed port → empty Service Endpoints, firewall → a NetworkPolicy silently dropping traffic. Same method, different label.

Full write-up with the "why it matters for platform/SRE work" framing and the GitHub reference chapter (with an exercise checklist) are linked above.

Curious how people here debug this in practice: do you reach for tcpdump early, or only after ss/dig/nc rule out the obvious layers? And has anyone had a case where the symptom actively lied — e.g., a REJECT rule dressed up to look like a closed port? Drop it in the comments, I'm collecting real-world edge cases for the next chapter on containers.

Platform Engineering starts before Kubernetes

Roger Oliveira — Fri, 21 Aug 2026 19:42:38 +0000

Why the right question isn't "where do I start with Kubernetes", but "what problem am I actually solving".

The claim that tends to bother people

Every time someone asks me "where do I start to become a Platform Engineer", the answer they expect is "Kubernetes". The answer I give is: no. Kubernetes is the tool you use once you already know what you're trying to solve. Platform Engineering is about the problem, not about the orchestrator.

What actually separates someone who "knows Kubernetes" from someone doing Platform Engineering

After years running and evolving Kubernetes platforms in production — with hundreds of workloads and thousands of pods running in a regulated corporate environment — the difference I see in practice isn't in kubectl. It's in three questions most tutorials never make you ask:

Who is your platform's customer? It's not the cluster. It's the development team that needs to ship without pinging you every time. If you can't name who uses what you're building, you're operating infrastructure, not building a platform.
What happens when something breaks at 3am? A tested rollback, a defined RTO, a clear incident owner — that's a design decision made long before any YAML manifest exists. A platform that wasn't designed to fail well, fails badly.
How do you measure whether the platform is helping or getting in the way? If the answer is "I don't know", you have a cluster, not a platform. Capacity planning, adoption metrics, reduced cross-team rework — that's what turns operations into an internal product.

Where Linux comes in

This is the connection the "Linux from Zero" series has been building since the first post: every abstraction Kubernetes gives you — pods, namespaces, resource limits, network policies — is an elegant repackaging of concepts that already exist in plain Linux: processes, kernel namespaces, cgroups, iptables/nftables. Once you understand the process before the pod, the kernel namespace before the Kubernetes namespace, you stop treating the cluster as a magic black box and start debugging like someone who understands the engine, not just the dashboard.

It's not a coincidence that the worst production incidents I've had to solve had their root cause one layer below Kubernetes — disk I/O, DNS, kernel limits — not in the orchestrator itself. Someone who only knows how to operate Kubernetes is blind exactly where the problem lives.

The path I advocate for (and the one this series follows)

Linux → processes → networking → containers → Docker → containerd → Kubernetes → observability → SRE → Platform Engineering → architecture.

That order isn't arbitrary. It's the order that gives you solid ground before it gives you altitude. Each layer explains the one above it. Jumping straight to "Kubernetes from zero" is like learning to fly a plane without understanding what makes it fly — you can memorize the controls, but you can't diagnose it when something goes off-script.

Where this takes you in practice

If you're trying to move from operations into Platform Engineering — or from Platform Engineer to Staff/Principal — the real test isn't "how many YAML manifests have you written". It's: can you explain, in one sentence, to a non-technical executive, why the platform you're building reduces risk and speeds up delivery? If yes, you're already thinking like a Platform Engineer. Kubernetes is just the tool you chose to execute that vision today — tomorrow it might be something else.

Full track (free, in Portuguese): github.com/roger-oliveira86/kubernetes-do-zero-ptbr

Agree or disagree? Curious to hear whether, in your experience too, the worst incidents also started "one layer below" Kubernetes.

Linux from Zero #2 Processes: what's actually running under your terminal

Roger Oliveira — Fri, 21 Aug 2026 19:40:58 +0000

Part 2 of the "Linux from Zero" series. If you haven't read #1 yet, it's on Medium and DEV.to — start there to understand the approach: investigate through evidence, not by memorizing commands.

The problem nobody explains properly

Have you ever run ps aux and watched a huge list of lines scroll by, without really knowing what to do with it? Most tutorials teach you the command, but not how to think about what it returns. This post is about exactly that: turning a list of numbers into reasoning about what your machine is actually doing.

The experiment

Open two terminals side by side. In the first one, run:

sleep 300 &

This creates a process that just "sleeps" for 300 seconds — doing nothing useful, on purpose, so it can be our test subject.

In the second terminal, run:

ps -eo pid,ppid,stat,etime,cmd | grep sleep

You'll see a line similar to this:

  PID   PPID STAT     ELAPSED CMD
12345   9876 S           0:03 sleep 300

Now the question that actually matters: what is each of these columns telling you about this process's life?

PID — the unique identity of this process for as long as it exists.
PPID — who created this process (the parent process). In your case, probably the shell in your first terminal.
STAT — the current state. S means "sleeping" (interruptible). You'll see R (running), Z (zombie), and D (uninterruptible I/O wait) in other contexts — each one tells a different story about what is or isn't blocking the system.
ETIME — how long it's been alive.

Why this actually matters

In production, nobody runs sleep on purpose — but every performance incident I've ever investigated started with exactly this question: "which processes are running, who's the parent of what, and what state are they stuck in?". A process stuck in D state (uninterruptible sleep) for a long time, for example, is almost always a symptom of a disk or storage problem — not an application bug.

Now try killing the process through its parent, not the sleep itself:

kill -TERM <your_shell_PPID>

Don't actually run this in your main terminal — it's just so you can mentally picture what would happen: killing the parent process usually kills the sleep child too (or it gets "adopted" by init/systemd, depending on the system). This reparenting behavior is the same logic behind why, when a container dies unexpectedly, the processes it was hosting disappear along with it.

The bridge to where this series is going

This parent/child relationship between processes is exactly what Linux uses as the foundation for isolating processes into namespaces — the mechanism that, later in this series, becomes containers, and that Kubernetes orchestrates at scale. Understanding processes today, without rushing, is what makes the "aha" moment happen when you get to cgroups and namespaces a couple of posts from now.

Try it yourself

Before the next post, try answering these on your own machine (no need to reply here, this one's for you):

Run ps -eo pid,ppid,stat,etime,cmd --forest and visually identify which process is the parent of which.
Find (or fail to find) a process in Z (zombie) state — if you don't find one, that's already useful information: your system is healthy on that front right now.
Compare ps aux with top (or htop) running at the same time — what changes between a static snapshot and a continuous view?

Next in the series: namespaces, and what actually isolates one process from another — the foundation of everything we now call a "container".

Full track (free, in Portuguese): github.com/roger-oliveira86/kubernetes-do-zero-ptbr

Have you ever run into a process stuck in D state during a real incident? What caused it? I'm collecting real-world examples for the next posts in this series — drop them in the comments.

Linux from Zero #1: What Is Linux and Which Distribution Should You Choose?

Roger Oliveira — Mon, 17 Aug 2026 23:31:30 +0000

Linux from Zero #1: What Is Linux and Which Distribution Should You Choose?

When people start studying DevOps, SRE, or Kubernetes, they usually find a long list of tools. But there is a layer underneath all of them: the operating system.

If you do not understand processes, permissions, services, networking, and logs, every container or cluster error can feel mysterious.

Which distribution should you choose?

Ubuntu LTS

My recommendation for a first lab. It has a large community, extensive learning material, and is widely used in cloud environments.

Debian Stable

A strong choice for learning a stable server foundation and the Debian ecosystem. Use it after your first contact with Linux.

Kubernetes from Scratch What It Is, How to Avoid Crashing Your PC, and Creating Your First Pod

Roger Oliveira — Tue, 11 Aug 2026 12:34:35 +0000

How to understand the world's most famous orchestrator using the cargo ship analogy — and run your first lab 100% in your browser.

If you are starting out in IT, migrating to DevOps, or looking to advance toward technical leadership roles (such as Staff/Principal Engineer), the word Kubernetes crosses your path every single day.

However, the first barrier is almost always the same: "Where do I start without drowning in heavy theory and without freezing my computer?"

In this first article of the Kubernetes from Scratch series, we will demystify core concepts using real-world analogies, understand the basic architecture, and launch your first live application in less than 5 minutes — completely free and directly inside your browser.

1. The Core Analogy: The Automated Port 🚢

To understand Kubernetes, you don't need complex jargon. Think of global maritime logistics:

The Application (Your Code): This is the goods needing delivery (e.g., an e-commerce store or a banking system).
The Container (Docker): This is the standardized metal cargo box. It doesn't matter if there are shoes, electronics, or food inside: from the outside, the dimensions and locking mechanisms are universal. It runs the exact same way on your laptop as it does in the cloud.
The Pod: This is the exact space (the rack or ship deck area) where one or more containers sit and work together. In Kubernetes, the Pod is the smallest unit you manage.
Kubernetes (The Port Captain): This is the robotic conductor. If a cargo box falls into the sea (an application error), the Captain instantly creates a brand-new box in its place within seconds. If traffic surges during Black Friday, the Captain automatically requests more ships.

2. The Golden Rule: Forget Local Clusters at First 💡

One of the biggest mistakes beginners make is trying to install tools like Minikube or Kind on resource-constrained laptops. The computer freezes, the cooling fans go wild, and learning turns into frustration.

Pro Tip: In the official CNCF exam (the CKA - Certified Kubernetes Administrator) and in real-world production environments, work is done via a Linux terminal and a web browser.

That is why we use Killercoda (killercoda.com): a free platform that provides a real Kubernetes cluster running directly in the cloud through your browser.

3. Hands-On: Your First Pod in the Browser 🛠️

Go to killercoda.com/playgrounds and select the Kubernetes Playground environment.

Once the terminal screen loads, follow these 3 quick steps:

Step 1: Terminal Survival Kit

Whenever you start a new lab environment, set up an alias to save keystrokes and adjust the .yaml file formatting for the vim editor:

# 1. Shortcut for kubectl
alias k=kubectl

# 2. Configure Vim to respect 2-space YAML indentation
echo "set tabstop=2 shiftwidth=2 expandtab" >> ~/.vimrc

Step 2: Spin Up an Application Imperatively

Instead of writing dozens of lines of YAML manually from scratch, use imperative commands to generate resources quickly:

# Create a Pod running an NGINX web server
k run my-web --image=nginx:alpine

Step 3: Inspect Your Resource

Check if your Pod is up and running:

k get pods

If the status shows Running, congratulations! You have just placed your first container under Kubernetes orchestration.

4. What To Do When Things Go Wrong? 🔍

The most valuable skill in daily operations is Troubleshooting. If your Pod fails to start, follow this investigation sequence in your terminal:

# 1. Check the general status of the Pod
k get pods

# 2. Inspect cluster events (WHAT happened?)
k describe pod my-web

# 3. Analyze container logs (WHY did the application fail?)
k logs my-web

📚 Next Steps & Official Sources

This article is just the gateway. To deepen your learning in a structured way:

GitHub Open-Source Repository: All code, guides, and practical exercises from this series are hosted on GitHub: https://github.com/roger-oliveira86/kubernetes-do-zero-ptbr.
Official Documentation (CNCF): Get comfortable searching kubernetes.io/docs — it is your best friend in production and the only allowed reference material during certification exams.
Practice Platform: Work through guided scenarios covering RBAC, Storage, and Troubleshooting at Killercoda.

💬 What About You?

What was the biggest challenge you faced when you first tried to learn Kubernetes? Leave a comment below and share this article with anyone starting their Cloud Native journey!

Kubernetes #DevOps #CloudNative #Docker #TechCommunity #CKA

What 9 articles in 15 months taught me about writing with consistency

Roger Oliveira — Mon, 03 Aug 2026 22:57:56 +0000

I have a strange publishing pattern. Five articles in four months. Then seven months of complete silence. Three articles in five weeks. Then almost three months of silence again. One article. And here I am, trying to understand what this pattern actually means before I simply promise "I'm going to post every week" and repeat the cycle.

Between April and July 2025, I wrote about the fundamentals: a platform engineering study plan, the signs that an infrastructure needs modernization, the strategic role of someone who operates beyond technical execution, and the bridge between engineering and business. In the middle of all that, I also wrote about workplace burnout—not because I planned a "different" kind of article, but because it was what I had to say at that moment. That article, by the way, is still the one that represents me most from this first phase: it shows that consistency in producing technical content isn't incompatible with admitting that sometimes you just lack the energy to produce anything at all.

Then, silence. Seven months.

It wasn't for lack of topics. It was the kind of period where operations consume all the energy that would otherwise be left to reflect on them—and reflecting in writing requires a different kind of energy than resolving an incident.

When I came back in March 2026, the tone had shifted. "Software Architecture is Actually Decision Management" is no longer about tools or warning signs—it's about how technical decisions carry consequences that survive far beyond those who made them. Two weeks later, "Systems Scale the Same Way Organizations Do" continues that line of thought: architecture isn't just code, it's decision structure. And three weeks after that, "You Don't Scale Systems While You Remain Their Central Point" hits the most uncomfortable point of the three—that sometimes, the bottleneck is me.

Three dense articles in five weeks. And silence again—this time almost three months, until "Rollback Isn't a Backup Plan. It's a Culture." in July, written in English and targeting a broader audience than the previous ones.

This isn't a pattern of laziness. It's a spike pattern: I write when a thought has matured enough to become a piece of writing, not at the artificial pace of an editorial calendar. The problem is that spikes are unpredictable—and unpredictability, for someone trying to build a consistent technical presence, is the opposite of what works.

So the change I'm testing now isn't "writing more." It's reducing the step size: instead of waiting for a full article to mature, recording a single paragraph, an unformed idea, or an unanswered question—every week, not just when the spike hits. If it yields an article, great. If it doesn't, at least there's a trace showing that the thinking didn't stop during the silent months; it just wasn't ready for publication.

If you also write in spikes, or have tried a cadence that didn't hold up—leave a comment below with what worked (or didn't) for you.