Ever wondered what it was like to work in IT back in the 1980s and early 1990s?

Today, we talk about cloud computing, APIs, microservices, DevOps, containers, Kubernetes, AI and automation as if they have always been part of the technology landscape.

But for those who started their careers in the 80s and 90s, the world of technology was very different.

There were no smartphones, no cloud consoles, no SaaS applications, no Slack or Teams, no GitHub, and certainly no ChatGPT to help troubleshoot an error at 2 AM.

Technology was physical, centralized and, in many ways, much more hands-on.

And perhaps the biggest difference?

When something broke, you couldn’t just reboot a cloud service or open a support ticket. You often had to physically go and fix it.

The term Information Technology (IT) eventually became the common terminology, particularly as technology evolved beyond simply processing business data.

But in many organizations during the 80s and into the 90s, technology departments were commonly known as EDP — Electronic Data Processing.

The name itself tells us a lot about the era.

Computers were primarily there to process business information.

Payroll, accounting, inventory, banking transactions, billing and other business processes were typically centralized and highly controlled.

The idea of having every employee carry a powerful computer in their pocket would have sounded like science fiction.

For large organizations, the mainframe was the heart of the enterprise.

Applications were centralized on large mainframe systems, and users interacted with them through terminals.

A typical workstation might consist of a monitor and keyboard connected to the central system.

The terminal itself had very little intelligence.

It was essentially a window into the mainframe.

There was no Windows desktop with dozens of applications running locally. No browser. No Teams. No local database.

You logged into the system and interacted with the applications hosted centrally.

The mainframe did the heavy lifting.

This architecture had an interesting characteristic that modern cloud architects will immediately recognize:

centralized computing with thin clients.

In many ways, the industry has come full circle.

For many of us who started during this period, the famous green screen was the user interface.

Black background | Green characters | Cursor | Keyboard

And lots of function keys.

There were no fancy dashboards.

No drag and drop.

No mouse-driven user experience.

You learned keyboard shortcuts and transaction codes.

You became extremely efficient at navigating screens because every keystroke mattered.

And if you knew the application well enough, you could probably enter transactions faster than someone using a modern graphical interface.

Today, connectivity is something we take for granted.

Plug into Wi-Fi and you’re connected.

Back then?

Connectivity could involve cables, connectors, serial communications and physical infrastructure.

RS-232 serial communication was widely used for connecting terminals and other equipment.

And this meant that knowing how to deal with cables was sometimes part of the IT job.

A broken cable wasn’t simply:

Raise a ticket with the network team.

You might actually need to inspect the cable.

Check the connector.

Test the connection.

And, in some environments, get out the soldering iron.

Yes—soldering could be an IT skill.

The boundary between hardware, networking and software was much less defined than it is today.

Today, an architect might design infrastructure without ever touching the physical servers.

In those days, the infrastructure was right in front of you.

Large computers | Disk drives | Tape drives | Network equipment | Printers | Air-conditioning systems | UPS units.

And lots of cables.

The computer room was often treated almost like a restricted facility.

• Temperature and humidity mattered.
• Power mattered.
• Physical security mattered.
• And the sound was unmistakable.
• Fans running.
• Disk drives spinning.
• Printers hammering away.
• Tape drives operating.

It was the sound of computing.

Unix was already an important operating system in the early computing world.

One of the things that made Unix powerful was its philosophy of small tools that could be combined to perform complex tasks.

But there was no modern file explorer.

You lived on the command line.

Commands such as:

`ls`, `cp`, `mv`, `grep`, `find`, `vi`. and `cpio`

were part of everyday life.

And if you accidentally deleted something important, there wasn’t a recycle bin waiting for you.

You learned very quickly to respect the command line.

Backup and recovery were also very different.

Tools such as cpio were used for archiving and backup operations, often alongside magnetic tape.

And yes, `tar` existed too—it just wasn’t necessarily the tool everyone used in every environment.

The important point is that you needed to understand what the commands were actually doing.

There was very little abstraction.

Today, we casually talk about gigabytes and terabytes.

Back then, storage was expensive and limited.

You didn’t casually store everything.

Disk space had to be managed.

Files had to be archived.

Backups had to be planned.

And magnetic tapes played a major role.

Backup wasn’t something that happened magically in the background.

Someone had to make sure the backup completed.

Someone had to manage the media.

Someone had to store it safely.

And someone had to know how to restore it.

That last part was particularly important.

A backup that cannot be restored isn’t really a backup.

And then there were the printers.

Not your modern laser printer.

I’m talking about large line printers.

These machines could be enormous.

They used continuous stationery with perforated edges.

When a report ran, the printer would start hammering away.

And it could continue for a very long time.

Minutes.

Sometimes hours.

You might be responsible for changing the paper, checking the printer and making sure the report completed successfully.

And then came the next challenge:

What do you do with hundreds or thousands of pages of printed reports?

Today we complain when a PDF takes a few seconds to download.

Back then, waiting for a report to finish printing was simply part of the job.

Not everything happened in real time.

Batch processing was a fundamental part of enterprise computing.

Jobs were submitted to the system and processed according to schedules and priorities.

A business process might look something like:

Input → Batch Job → Mainframe Processing → Output → Printed Report

You didn’t necessarily click a button and immediately get a dashboard.

You submitted the work and waited.

The concept of overnight processing was very real.

Organizations would run jobs after business hours because the computing resources were heavily shared.

Morning could begin with checking whether the overnight batch jobs completed successfully.

If something failed?

Time to investigate.

There was no DevOps culture in the modern sense.

There were developers.

There were operations teams.

There were system administrators.

There were database administrators.

And there were very clear procedures around production changes.

A production deployment wasn’t something you casually did from your laptop.

You needed authorization.

You needed documentation.

You needed a change window.

And you needed to be very sure about what you were doing.

Because when the system was down, there weren’t multiple cloud regions waiting to take over automatically.

There was usually one production environment that mattered enormously.

Today, when something goes wrong in production, someone sends a message on WhatsApp, Teams or Slack.

Back in the 80s and early 90s?

You had a pager.

And when that pager went off, you knew it probably wasn’t good news.

There was no WhatsApp group called “Production Support”.

No Teams notification.

No Slack alert.

No push notification showing the application health dashboard.

You carried a small pager with you.

If a production system experienced a problem, the support team or operations centre would page the person on duty.

The message might be nothing more than a phone number or a short code.

And that was your signal:

“Something is wrong. Call the support centre.”

The Pager Was Your Notification System

The typical support process could look something like this:

System failure → Operations detects problem → Pager activated → Engineer receives page → Find a telephone → Call operations → Troubleshoot

And finding a telephone wasn’t always as easy as pulling a smartphone out of your pocket.

You might be at home.

You might be having dinner.

You might be driving.

You might be out with friends.

But when that pager started beeping, you knew you had to find a phone.

There was no screenshot of the error.

No log file attached to the WhatsApp message.

No Teams chat containing the last 50 troubleshooting attempts.

You had to call someone and ask what was happening.

You might then need to remotely access the system—or, depending on the situation and environment, physically go into the office or data centre.

There was no smartphone with SSH, cloud consoles, monitoring dashboards and ChatGPT sitting beside you.

You were the monitoring system.

Today

Observability → Automated Alert → Incident Platform → AI-assisted Diagnosis → Engineer

The technology has evolved from a simple beep to sophisticated observability and incident-management platforms.

But the fundamental objective remains exactly the same:

Detect the problem, notify someone and get the system back up.

Another major difference was documentation.

When technology was less accessible, knowledge was often stored in manuals, runbooks and physical documentation.

You couldn’t simply Google:

Why is my Unix process failing?

There was no Google.

You searched manuals.

You looked through technical documentation.

You spoke to someone who had encountered the problem before.

You experimented.

You learned by doing.

And perhaps because of this, many IT professionals from that era developed a strong troubleshooting mindset.

You had to understand the system rather than simply search for a solution.

Then came the internet.

For those working in IT during the 90s, this was one of the most significant technological transformations.

Suddenly computers could communicate globally.

Email became increasingly important.

Websites emerged.

Browsers appeared.

And organizations began asking a completely different question:

“How do we connect our business to the internet?”

This started a transformation from centralized enterprise computing toward distributed systems.

The architecture began changing.

Mainframes were still there.

But now we had:

Client → Server → Database

Then:

Web Browser → Web Server → Application Server → Database

And eventually:

Mobile → API → Services → Databases → External Systems

The architecture kept evolving.

One of the fascinating things about looking back is seeing how far connectivity has evolved.

1980s:

Terminal → RS-232 → Mainframe

1990s:

PC → LAN → Server

2000s:

Browser → Internet → Web Application

2010s:

Mobile → API → Cloud

2020s:

Mobile → API → Cloud → AI → Intelligent Services

The underlying objective remained the same:

connect people, systems and information.

The technology used to achieve it changed dramatically.

Perhaps the biggest difference wasn’t the technology.

It was the relationship between the technology and the people operating it.

IT professionals often had to understand multiple layers.

Hardware.

Cables.

Operating systems.

Networks.

Applications.

Databases.

Printers.

Storage.

Backup.

And sometimes even electrical or physical infrastructure.

The modern separation between infrastructure, platform, network, security, development and operations was not always as pronounced.

You were often expected to figure things out yourself.

It is easy to romanticize the past.

Technology was certainly simpler in some ways.

But it was also slower.

Computing resources were expensive.

Deployments were difficult.

Storage was limited.

Connectivity was slower.

Troubleshooting could take hours or days.

And automation was nowhere near what it is today.

Today we can provision infrastructure through Infrastructure as Code, deploy applications through CI/CD pipelines and monitor thousands of services through centralized observability platforms.

That’s an incredible evolution.

Despite those limitations, organizations built incredibly important systems.

Banks processed millions of transactions.

Airlines managed reservations.

Governments processed huge volumes of records.

Manufacturers managed complex supply chains.

Businesses automated payroll, accounting and inventory.

All of this happened with technology that, by today’s standards, had extremely limited resources.

And that’s perhaps the biggest lesson.

Good technology isn’t simply about having powerful hardware.

It is about understanding the problem, designing the right solution and making the best use of the technology available.

For those who started in the 80s or 90s, the journey has been extraordinary.

Some started with mainframes.

Then learned Unix.

Then PCs.

Then networking.

Then client/server.

Then the internet.

Then web applications.

Then enterprise integration.

Then APIs.

Then cloud.

And now AI.

Imagine learning an entirely new technology paradigm every few years.

That is the story of many technology professionals from that generation.

We didn’t just witness the evolution of technology.

We lived through it.

And perhaps that is why those old skills still matter.

Understanding how systems actually work.

Knowing how to troubleshoot.

Understanding networks.

Understanding operating systems.

Understanding data.

Understanding integration.

And most importantly, knowing how to solve problems when the documentation doesn’t have the answer.

Because whether you’re sitting in front of a green-screen terminal in 1989 or designing an AI-enabled cloud architecture in 2026, the fundamental question remains the same:

“How do we make technology work for the business?”

The tools have changed.

The platforms have changed.

The terminology has changed.

But the problem-solving mindset?

That never went out of date.