Trying to Explain Networking
At one point, I was asked to help with a work experience placement. Someone young, spending a week in IT to see what it was all about. I decided to explain networking. Not casually. Not with a whiteboard and a few diagrams. Properly.
I built a document that walked through:
- what networking is
- how devices communicate
- the OSI and TCP/IP models
- how a request actually travels across a network
From the document:
“As Network Engineers, we’re interested in how your Computer… reaches remote resources”
I even included a full example. What happens when you type a URL into a browser. How it moves:
- through application protocols
- into transport (TCP vs UDP)
- into IP addressing
- down to physical transmission
It made sense to me. I used analogies:
- MAC address as a house number
- IP address as a postcode
- TCP as recorded delivery
I broke everything down into layers. Explained how they interact. How each part has a role. It was probably the most structured explanation of networking I’d ever written. By day three, they were bored.
Not just with me. With IT in general and that’s fair.
Looking back, I realise I was proving to myself that I understood it. Because there’s a difference between:
- knowing how something works
- and being able to explain it clearly
This was me doing the second and maybe overdoing it slightly. The document itself covered everything from physical cabling through to application protocols.
From Layer 1:
“the medium used to carry our traffic”
To Layer 4:
“all about reliability… TCP or UDP”
It was thorough. Probably too thorough for the audience. But it taught me something useful. Understanding a system deeply often makes it harder to explain simply, because you see all the moving parts. All the layers. All the interactions. And not everyone needs that level of detail. Sometimes they just need:
“this is roughly how it works”
I didn’t do that. I gave them the full stack. They didn’t become a network engineer, at least I don’t think they did. As far as I know, they didn’t even consider IT after that week. But I kept the document because it represents something else. A moment where I stopped just using a system… …and tried to explain it properly. Even if the audience wasn’t quite ready for it.