My load balancer worked. That's what made me uncomfortable.

Dani Sam — Mon, 20 Apr 2026 15:57:07 +0000

I didn't expect a load balancer to make me uncomfortable.

But here we are.

I built one in Go for my MSc case study. Round-robin distribution, health checks, mutex for concurrency, timeout handling. It worked. Requests going in, responses coming out, servers behaving exactly as they should.

I should have felt good about it.

Instead I felt uneasy.

I kept staring at http.Get() thinking — I have no idea what's actually happening here. I know what it does. But I don't know what it's doing. TCP handshakes, socket creation, buffer management, kernel calls — Go handles all of it quietly, without ever asking if I understand any of it.

For a while I told myself that's fine. That's the point of abstractions.

But then I thought about what kind of engineer I actually want to be.

Not just someone who can make things work. But someone who knows what's happening at the wire level. Someone who understands the ground beneath the tools they're standing on.

And I realized — I wasn't that person yet.

So I'm going back to the foundation. Learning C properly. Raw sockets, memory management, system calls — the actual ground floor of how networked systems work. This week I wrote my first TCP echo server in C with no libraries. Just socket(), bind(), listen(), accept() — and strace to watch every syscall it made. It was slower. It was harder. It felt completely different from Go.

It felt like understanding.

This isn't about Go being wrong for the job. Go is excellent at what it does. It's about me not being okay with borrowed understanding anymore.

There's a difference between standing on the ground and standing on someone else's abstraction of it. Both get the job done. Only one of them is actually yours.

I'd rather build slower on solid ground.

The load balancer in action — round-robin distribution across three servers, health check catching a server going down and back up.

If you want to see the code: go-load-balancer on GitHub

The Architects and the Tenants: Your Place in the AI-Driven Future of Code

Dani Sam — Sun, 19 Apr 2026 19:51:34 +0000

Photo by reyna on Unsplash

AI can write code now. Pretty good code, honestly.

And that should make you think — not panic, just think. Because if AI can generate the same Python script, the same REST API, the same web app that you spent weeks learning to build — what exactly are you bringing to the table?

Most of us started at the surface. High-level languages, frameworks, tutorials. That's fine. That's how everyone starts. But a lot of people never leave the surface. They get comfortable there. And now AI lives there too, and it's faster than all of us.

Below that surface though — something different is happening.

Memory. Networking. Hardware. The kernel. The wire. This layer doesn't care about your framework or your prompt. It only speaks one language — understanding. Not usage. Not generation. Actual, hard-won understanding of why things work the way they do.

Why does this packet drop halfway through a handshake. Why does this process eat memory at 3am. Why does this protocol fall apart under real load. AI can guess at these. The engineer who truly understands systems doesn't guess.

I think about it this way. There are architects and there are tenants.

Tenants use what's available. They ship features, use tools, move fast. Nothing wrong with that — the world needs tenants. But tenants are also one better model away from being automated.

Architects build what the tools run on. They go below the abstraction on purpose. They understand the foundation that everyone else is standing on without realizing it. AI doesn't replace architects — it gives them better tools to build with.

The surface is getting crowded. AI is making it more crowded every month. But the deeper layers — networking internals, systems programming, embedded hardware, protocol design — those are getting quieter. Because going deep is hard and slow and uncomfortable and most people won't do it.

That's exactly why it matters.

The future belongs to the people who understand what's happening below the abstraction. Not because they're anti-AI. But because they understand what AI is actually running on.

Architect or tenant. The choice is still yours to make.

Forem: Dani Sam

My load balancer worked. That's what made me uncomfortable.

The Architects and the Tenants: Your Place in the AI-Driven Future of Code