Was it really better before, or why us old geeks think so

Those of us who have been in IT for a while often say it was better before. Not because we miss floppy disks or Windows 3.1, but because we see a fundamental difference in how knowledge was built and used. We had to learn the basics in a way that created deep understanding. That kind of understanding risks being lost in a time when AI, automation, and abstraction allow people to jump straight to the result.

The question is simple: if the next generation never learns the foundations, who will understand the machine when something really goes wrong?

When the basics were everything

In the 80s and 90s, IT was not packaged. If you wanted to understand a computer, you had to know how a hard disk actually spun, why 640 KB of RAM was a real limitation, what an IP network was, and how routing tables looked in practice. You had to calculate with binary numbers, understand checksums, and keep track of IRQ conflicts. It wasn’t academic - it was survival.

If you built a network, you crimped your own cables, set IP addresses manually, and analyzed why two machines couldn’t talk to each other. Often, you sat with a blinking LED trying to figure out where the signal disappeared. There was no AI to generate troubleshooting steps for you. Documentation was scarce. You learned by failing.

This created a competence that went deep. You didn’t just know what worked - you understood why. When you later faced more advanced systems, you already had the reference frames. You knew what was happening under the surface.

When everything became abstraction

Fast forward to today. A newly graduated developer can deploy an entire application in the cloud with just a few lines of code. Kubernetes takes care of scaling, Terraform builds infrastructure, and the CI/CD pipeline pushes it all into production. It looks impressive - but do they really understand what happens when containers suddenly can’t talk to the database?

The truth is often no. The understanding of the IP stack, firewall rules, DNS handling, or even how network packets move through infrastructure is weak. Troubleshooting becomes guesswork. At best, someone finds a guide on Stack Overflow. At worst, they point at the cloud provider and say “it doesn’t work.”

The problem isn’t the individual. It’s the system we’ve built. Everything is packaged to go fast. “Move fast and break things” became a slogan (After Facebook:s quote), but we forgot the other half: someone still needs to know how to fix what breaks.

AI, it is a blessing and a trap

AI amplifies this trend. For better and for worse.

On the positive side, AI can be the best teacher you’ve ever had. Ask it about the TCP handshake, and you’ll get a clear, structured explanation in seconds. It can compare architectures, explain code, and suggest fixes. For those who already have a foundation, AI can accelerate learning dramatically.

On the negative side, AI can also become a crutch. Give it a problem, and it hands you a solution you don’t actually understand. It can write an entire module for you, but you have no idea what happens under the hood. It can do your homework, but in reality, it’s the AI that’s learning - not you.

The risk is that we produce a generation of engineers who can order code from AI but cannot troubleshoot it when something goes wrong. It’s like being able to drive a car without knowing what happens when the engine light comes on. Convenient, yes. Safe, no.

Our hidden strength: attention span

This is where us old geeks have an advantage. We trained something that’s becoming rare: a long attention span.

Back then, there were no quick answers. If you wanted to understand routing, you read RFC documents. If you wanted to understand hard disks, you went through hundreds of pages of manuals. If you wanted to build a web server, you spent nights tweaking Apache configuration files.

It was slow, frustrating, sometimes hopeless. But it built patience and persistence. We could sit with a problem for hours without giving up. And when we finally solved it, the lesson stuck for life.

Today’s environment doesn’t train this as naturally. Young engineers grow up with instant answers, autocompleted solutions, and short-form content. Focus is scarce. But troubleshooting, security work, and infrastructure design require exactly that: deep focus sustained over long periods.

When the basics are missing, risks become real

Here the difference between “knowing” and “understanding” turns into a real risk. For hobby projects, it’s harmless. For mission-critical platforms, it’s a ticking time bomb.

Imagine a SOC team that has never really understood how IP packets move through a firewall. When they see signs of an advanced attack in the logs, they can’t piece together how the attacker actually got in. Or a developer who has only learned cloud through AI-generated answers and prebuilt pipelines. When someone suddenly exfiltrates data, they don’t even know where to start looking.

CIOs and CISOs need to understand this: building organizations on staff without fundamentals is gambling with resilience. It may work fine day to day, but when the crisis comes, you’re left without tools.

What needs to be done

This is not nostalgia. It’s a leadership issue. 1. Require fundamentals. Don’t only ask for cloud certifications when hiring. Test whether candidates understand IP, DNS, storage, operating systems. 2. Train for real. Put junior engineers in lab environments. Let them break things and fix them. Hands-on experience sticks far better than slide decks. 3. Use AI correctly. AI should accelerate learning, not replace it. Set clear boundaries for when AI is allowed in development and security work. 4. Train focus. Encourage long projects, not just short sprints. Reward persistence and deep learning. 5. Value experience. Senior engineers are not blockers. They carry the institutional memory and deep knowledge you’ll need when the unexpected happens.

So was it better before?

No. Technology today is better. We have more powerful tools, faster platforms, and opportunities that were unthinkable thirty years ago.

But we did have something back then that risks being lost: a deep grasp of fundamentals, trained focus, and the habit of not giving up when things got hard.

If we combine today’s tools with yesterday’s depth and persistence, we can build a new generation of engineers who can both move fast and stay steady. If we don’t, AI and modern IT become not just an asset but a blind trap.