Network

I can’t remember for sure, but I am guessing the year was 1996 or 1997. I had a Pentium 133 MHz, which was now far behind the newly released Pentium MMX 166 MHz.

I was living with my parents, and while I had a job, I made peanuts, so any upgrade would require parental sponsorship.

My dad never allowed me to have video games or expensive toys, but I think he realized that computers were an actual path to a professional life. Not only did I manage to convince him that an MMX was necessary (he had no idea what that was), but I also talked him into buying a second PC instead of upgrading the existing one.

I set them both up in my bedroom, on two different desks in an L-shape, and I could easily move between them and work on different things in parallel.

But just a couple of days in, I was already annoyed at having to carry floppy disks back and forth between the two machines whenever I needed to exchange data.

I was familiar with the concept of computer networks since I had Internet access and had studied network topologies (Token Ring, remember that?) as part of my high school technical curriculum. But besides using Trumpet Winsock and reading books, I had no practical experience setting up a network myself.

Well, long story short, I managed to get two network cards and set up an IPX/SPX network. Not only could I share files, but I could even play Doom over the network. My poor dad definitely didn’t expect that part.

Looking back, that was probably the first time I realized what truly interested me about computers.

A lot of people, when talking about their first experiences with computers, will tell you how they started coding games, discovered Fortran, Pascal, or Assembly, and how that became their gateway drug into IT. Not quite so for me. From the beginning, I liked infrastructure. While my peers were taking extra courses in C or learning algorithms, I was attending courses on TCP/IP, Solaris, and Novell NetWare. I even completed the full MCSE coursework.

Over the years, I have noticed that understanding networking is the most fundamental skill for doing almost any kind of IT work. No matter how fancy your application is, if you publish it on the loopback interface, nobody will be able to access it. Once you understand network latency and how unreliable the average home Internet connection is, you realize there is little point in obsessing over low-level optimizations that save microseconds while the network adds milliseconds.

The funny thing is that networking rarely gets the same attention as programming. We celebrate elegant algorithms and clever language features, but packets do not care how beautiful your code is. Every request still has to traverse switches, routers, firewalls, DNS servers, load balancers, and who knows how many other devices before it reaches its destination. Every one of those components can fail, misbehave, or simply add a little more latency than you expected.

That reality has followed me throughout my entire career. It did not matter whether I was working as a systems administrator, an infrastructure engineer, or, years later, building cloud platforms and leading Site Reliability Engineering teams. The technologies changed, the buzzwords changed, and the hardware became unimaginably faster, but almost every interesting production problem eventually involved the network in one way or another. Sometimes the network was the root cause. More often, it was simply where the symptoms first became visible.

There is an Internet meme that goes, “It can’t be DNS. It can’t be DNS. It was DNS.” There is a lot of truth to that. Back in my day, there was also a pervasive idea that anytime something was not working as expected, “it was the firewall.” Which was true only 80% of the time.

Back when infrastructure, networking, and development were handled by separate teams, troubleshooting could be frustrating, but once the right people got involved, they would usually pinpoint the problem quickly. Today, we expect software engineers to also understand Kubernetes, load balancers, CDNs, and cloud networking. Eventually, they encounter a network anomaly and freeze because the underlying concepts are unfamiliar.

When junior and less experienced engineers ask me what they should be learning, networking is always near the top of my list. It is foundational knowledge that applies to almost every branch of IT involved in building and operating production systems. Whether you end up writing software, administering systems, designing cloud infrastructure, or working in DevOps or SRE, a solid understanding of how networks work will make you better at your job.

Looking back, it is funny that one of the most influential moments in my career started simply because I got tired of carrying floppy disks between two computers in my bedroom. I had no grand plan to specialize in infrastructure. I just wanted a more convenient way to move files around. That small annoyance led me to learn about network cards, protocols, routing, and eventually an entire field that I would spend the next three decades working in.

I still write code from time to time, and I enjoy learning new programming languages. But if I had to choose one skill that has consistently paid dividends throughout my career, it would not be a language, a framework, or a cloud platform. It would be understanding how computers communicate with each other. Everything else in modern computing is built on top of that.