Donald Davies called them packets so the network’s pieces wouldn’t become your message
The June 1966 wording made an interface distinction explicit, while his later interview describes the machinery around it.
A message can be one thing to its sender and several pieces to the network carrying it. Donald Davies gave those pieces a distinct name: packets. The ordinary little word helped stop two different engineering objects from borrowing the same identity.
In his historical note on packet switching, Davies points to a June 1966 proposal and explains the naming distinction. Its smaller transmission units needed to be distinguished from the user’s message. Calling both objects a message would have saved a noun while spending a great deal of clarity.
The everyday comparison is a shipment sent in several boxes. The person receiving it thinks about the complete order. The delivery operation needs to handle the separate boxes. Neither viewpoint is wrong, but a label describing one object can’t quietly stand in for the other when somebody is counting what arrived.
Davies’s 1988 interview with James Pelkey places the work amid communication problems posed by interactive computing. The machinery had to suit the traffic. A user sending small bursts of information presented a different practical demand from simply keeping a traditional communication arrangement occupied.
The interview discusses his expectation of special hardware for switching. Davies imagined pointers to prepared packets moving through the system, with handling work separated from other tasks. He also acknowledges optimism in the early calculations. An inventor admitting where the estimates were ambitious is rather more informative than a retrospective slide in which everything was inevitable.
The name therefore belongs alongside an architecture. A packet could be discussed as the thing being queued, moved, and transmitted. That vocabulary gives engineers a way to describe operations at the right level. Your entire message doesn’t have to be the object inside every sentence about a switching node.
This matters for reading performance claims too. A count of transmission units and a count of user messages need not be the same quantity. The relationship depends on how those units are formed. A large number attached to the wrong noun can look impressive without answering how much useful work a sender completed (marketing remains available).
The historical note supports this particular reason for the term. A broader story about how easily it translated into other languages needs its own evidence. The practical distinction already stands on the proposal’s words, without asking the name to prove every later anecdote attached to it.
Davies’s interview also describes the work of providing useful services around a network, including shared storage. A switching mechanism alone does not give every potential participant a reason to join. Users need something they want to reach, after the engineers have settled what the moving units are called.
The naming problem keeps returning in systems that divide one user operation into many internal jobs. A dashboard can count the pieces while its reader assumes it counts completed requests. Preserving both names makes that assumption easier to challenge. The next reassuring throughput figure still needs a noun that describes what was actually counted.