Why I Still Learn Networking Before Frameworks

I started in networking. For a couple of years my job was running cable, configuring routers, and working out why a link that tested fine in the morning was dropping packets by the afternoon.

When I moved into web development, I assumed that background was behind me. It turned out to be the most portable thing I'd learned.

Abstraction is a promise, not a guarantee

The web stack is a tower of abstractions, and each one is a promise that the layer below will behave. Frameworks assume the network works. TLS assumes DNS resolved. DNS assumes routing.

Those promises hold almost all the time — which is exactly what makes the failures so expensive. When something breaks below your abstraction, you can't debug it by reading the framework's docs.

The concrete version

A real example. An app worked locally and timed out in production, only for some users.

• At the framework layer: nothing wrong. Logs showed slow queries. The instinct was to optimise the database.
• At the network layer: the affected users were on a different route with a smaller MTU. Large responses were fragmenting and being dropped silently.

The fix had nothing to do with the application. The people who found it fast weren't better developers — they just had a mental model that included the layers underneath.

What's actually worth knowing

You don't need to be a network engineer. You need enough to reason about where a problem lives:

1. DNS — resolution order, TTLs, the difference between a record not existing and not propagating.
2. TCP and TLS — handshakes, timeouts, what a certificate error actually means.
3. Routing and NAT — enough to read a traceroute and know what it's telling you.
4. MTU and fragmentation — the source of a whole genre of "works for me" bugs.
5. Packet capture — when in doubt, look at the actual traffic.

That's a weekend of reading. It pays back the first time you're on a call at 2am and someone asks whether the problem is the app or the network.

The broader point

The abstraction layers are someone else's decisions, frozen. Understanding one layer down means you can tell the difference between a bug in your code and a bug in your assumptions — and that's most of the work.