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

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