Blog

Part 3 kept everything on one machine: namespaces as workloads, veth as cables, bridge or macvlan or ipvlan as the attachment. That is enough for a single Docker host. Two hosts do not share a broadcast domain just because both run Linux. Something has to carry Ethernet (or IP) across the real network between them. VXLAN is one common way to do that. CNI is something else entirely: a contract so Kubernetes (and other runtimes) can plug a pod into whatever network architecture you chose. ...

Partner companies ask me to help hire their frontend developers. Not “sit in on the final call.” The work starts in a room with their CTO, someone from HR, and whoever currently leads the development team. I listen to what they think they need. Then I tell them who they can actually use, read the incoming resumes, choose who is worth an interview, and run the loop. I follow the same path for my own team. The difference is who lives with the result. When I hire badly for myself, I absorb it — I mentor the person, or I carry the gap in the sprint. When I hire badly for a partner, they keep the person and I keep the reputation. ...

Part 1 built Layer 2 stacks on a host. Part 2 moved packets between IP networks. Both assumed one network stack: one set of interfaces, routes, and firewall rules. This post isolates whole stacks on the same machine. A network namespace is a private view of networking. A veth pair is a cable between views. A bridge, macvlan, or ipvlan is how those cables join a shared domain or a parent NIC. ...

In VLANs, Bonding, and Bridging, the host stayed inside one or more Layer 2 domains: bonds for uplinks, VLANs for separation, bridges for VMs. That stack answers “who shares this Ethernet segment?” This post answers a different question: how does a Linux box move packets between IP networks? That is routing — forwarding, policy routing when you have more than one path, and nftables rules that decide what is allowed to cross. ...

I was deep in a research thread that was not going to become a weekend post. The topic started small: juniors asking an AI to format code that Prettier already owns, or to invent a debounce helper the repo already has. It got larger fast. Sometimes the person is not a developer at all — they have an idea, they paste a warning into ChatGPT, the “build” goes green, and they never learn that the message was ESLint. The software can become more sophisticated than the operator’s mental model. That is a different problem than “juniors are lazy,” and it is too big to finish in one sitting. ...

Command & Conquer Generals: Zero Hour is not a demanding game in 2026. On the internal panel of this ASUS Vivobook Pro 15, it stays quiet. Plug the same laptop into an old 1080p HDMI monitor, launch the same Wine/Lutris game with no prime-run, and the chassis warms up. The fans come on. Unplug the monitor, and it cools down again. That is a bad mental model if you assume “old game = Intel GPU = cool laptop.” On a hybrid machine, who renders the frames and who owns the physical connector are two different questions. My native HDMI port is wired to NVIDIA. As long as that monitor is connected, the RTX 3050 has to stay in the display path — even when Mesa Intel Arc is doing all the actual drawing. ...

Cross-team trust is one of the strongest assets a senior developer can build. People tell you what is not working before it becomes an escalation. Designers invite you into early conversations. Product asks whether an idea is feasible. Support sends you the user complaint that explains a confusing metric. You see the product beyond the boundary of your team’s backlog. Then the strength turns. Another team believes you promised a fix. Your lead learns about new work after you have started it. Your teammates feel that your review comments carry an unofficial veto. You still think you are helping, but the organization has begun treating you as the owner. ...

In the first post in this series, I called the pattern shadow ownership: a senior developer builds real cross-team influence, then commitments and product authority begin moving through that influence without a clear role. For a team lead, this can feel personal. You are accountable for delivery, but another person appears to be setting expectations. Other teams go to them first. Work enters through conversations you did not see. Their care for the product can sound like a judgment on everyone else’s care. ...

On a small development team, one senior developer often becomes the person everyone else knows. People in product, design, support, and adjacent engineering teams message them directly. They listen well. They notice the rough edge that never became a ticket. They understand why a technically correct interaction still feels wrong to the person using it. When another team is frustrated, they do not reply with a Jira link and disappear. ...