The year was 1997. A younger, spikey-haired version of myself was running a shiny AMD K6 processor on Debian 1.3 “Bo.” At the time, I was working at a German ISP doing UNIX System Administration. It was a trial by fire where I learned how practical networking functioned whilst supporting customers in two languages.
Flipping through an issue of Computer Shopper, I came across a DEC advertisement for their 500 MHz Alpha chip.
My own machine was running at a blazing 166 MHz, leaving me deeply jealous. No matter how many Deutsche Marks I saved, there was no world in which I could afford one. That advert went up on my bedroom wall anyway, right where other kids hung posters of Ducatis.
With time, I did save the money. I eventually bought every single CPU architecture I lusted after during my youth. Today, my home rack is packed with gear from that golden age of computing.
My goal was straightforward: buy them, learn them, and get them networked.
- I spent days running Nessus and Cain & Abel against various retro setups to study vulnerabilities.
- I analyzed different hardware architectures to understand operating systems, filesystems, clustering techniques, and their respective processing strengths and weaknesses.
- I was forced to learn legacy protocols like IPX and Banyan VINES just to get these ancient systems talking to modern infrastructure.
- I used pure curiosity to jumpstart a deep understanding of a decade’s worth of protocols, designs, and architecture.
This wasn’t just a trip down memory lane. It was a foundational investment that paid off when I joined the Air Force in 2002.
On military deployments, cutting-edge systems were frequently racked right next to legacy hardware running 1980s technology. As a young airman, I was uniquely equipped to troubleshoot those hybrid environments. I understood that Active Directory was structurally similar to the NDS and LDAP frameworks I had broken and fixed at home.
Beyond the technical capability, it gave me a unique way to communicate with senior leadership. I spoke their operational language and understood the exact systems where they had cut their own teeth.
Every generation of engineers worries about technology becoming too abstract. I first learned BASIC during the BBS era, where the “true geeks” openly despaired about the new kids skipping assembly code. For the record, I absolutely skipped assembly code.
Now, as a CTO, my primary focus is growing people. When engineers join my team, I want to ensure they leave years later as significantly better professionals. It is the leadership problem I think about most.
The rise of AI brings this abstraction dilemma back to the forefront:
- Is AI simply the new interpreted code, or is it something entirely different?
- Will the newest cohort of engineers understand the underlying technology well enough to fix it when it breaks? Because it will break.
- Or is this simply another shift in how we interface with infrastructure?
If I were starting fresh today, I am not sure I would be content just tossing prompts into a system. I have always been the person who buys the latest tech gadget, voids the warranty, and tears it apart to see how it ticks.
Tools change, but the underlying requirement for deep technical curiosity does not. If you want to build systems that last, you still have to understand the foundations they are built upon.