Forty-Five Years

I got my first computer in 1981. A Commodore VIC-20.

I was born in 1966, so I was fifteen. Old enough to know this thing was interesting. Young enough not to have any sensible idea where it would lead.

At the time, the computer was not a polished appliance sitting quietly in the corner. It was the whole event.

You turned it on. You typed things. Sometimes it crashed. Sometimes it did not.

There was no gentle layer between you and the machine. No cloud service waiting patiently in the background. No friendly operating system trying to hide the unpleasant parts. If you wanted something to happen, you had to learn enough to make it happen.

I did not think of that as hardship.

Not then.

I used the VIC-20, and later the Commodore 64, to write my own games back when sprites were a thing. Real sprites. Small, stubborn, limited, weirdly satisfying things.

If you wanted a character to move across the screen, you had to work for it.

If you wanted sound, you had to understand enough to coax it out of the machine.

If you wanted the game to fit in memory, you had to make choices. Ruthless choices.

A few kilobytes could make you very humble.

That was part of the pleasure. The machine pushed back, and every small success felt earned. The first time a sprite moved properly. The first time a routine worked. The first time something on the screen looked vaguely like the thing I had imagined.

Yep, that felt good.

So no, it was not that computers were uninteresting. Quite a lot of it was interesting.

That is the part that gets missed when people hear me complain about operating systems now. They assume the complaint comes from impatience or ignorance. As if I want computers to be simpler because I never learned how they work.

That is not it.

I learned how they work because, for a long time, that was the only way to use them well. And because I liked it.

Both things were true.

Interest and necessity were tangled together from the beginning.

The curiosity kept me engaged. The necessity kept me learning.

Then came the Commodore 64 in 1983. An IBM-compatible PC in 1986. Windows when Windows 3 was released. Linux in 1994. macOS in 2005.

That list looks tidy when written down.

It did not feel tidy while living through it.

It was more like a long series of machines, operating systems, tools, drivers, cables, manuals, command lines, configuration files, and moments where something that should have worked simply did not.

My professional life followed the same pattern.

My first job involved machine language coding for microcontroller hardware. That is not exactly a low-friction introduction to work. You deal with the hardware because the hardware is the point. There is nowhere to hide. The machine does what you told it to do, not what you meant.

Helpful little distinction.

My second job was in R\&D, writing C for microcontroller hardware through UNIX. C was powerful, sharp, and perfectly willing to let you embarrass yourself. UNIX was direct. Useful. Demanding. It assumed you were paying attention.

Then I coded websites in Perl and PHP on Linux.

Then I secured applications running across UNIX, Linux and Windows.

Then, eventually, security architecture.

Looking back, I did not move away from technical complexity. I kept walking towards it.

Closer to the hardware. Closer to the operating system. Closer to the application. Closer to the risk.

For years, that was the work. And some of it was genuinely satisfying.

There is a particular pleasure in understanding a system well enough to predict where it will fail. There is satisfaction in finding the bug, fixing the flaw, tracing the chain backwards, and seeing the shape of the problem. That feeling has not really gone away.

I still like elegant engineering. I still like a clean design. I still like when a system makes sense.

What changed is my patience for unnecessary friction.

That took longer to notice.

When I was younger, friction often felt like part of the bargain. Of course the machine was difficult. Of course the operating system exposed its rough edges. Of course you had to know which file to edit, which flag to set, which driver to load, which command would reveal the thing that was broken.

That was normal. Or at least it felt normal because there was no better option sitting right beside it.

Now I see it differently.

Some friction teaches you something. Some friction is just bad design wearing a serious expression. That distinction matters.

When I say, “A computer is an appliance, not a hobby,” I am not saying computers are boring. I am saying the tool should not keep demanding to become the task.

When I sit down to edit a photograph, I care about the photograph. When I write, I care about the writing. When I review a security architecture, I care about the architecture, the controls, the risks, and whether the documented design can stand up to scrutiny.

I do not want the operating system to become the main character.

Not for a routine task. Not for opening a file. Not for previewing an image. Not for doing ordinary work that should have become ordinary by now.

This is probably why macOS appealed to me when I moved to it in 2005. Not because it removed all complexity. It did not. Nothing does. But it usually made the everyday parts feel less like a negotiation.

That matters more to me now than it did when I was fifteen. The fifteen-year-old version of me wanted to know what was inside the box. The older version already knows enough about what is inside the box.

Too much, some days. Now I want the box to help me do the work and then leave me alone.

That may sound like a rejection of technical depth. It is not. It is what technical depth eventually taught me.

There is a difference between understanding technology and requiring everyone to understand it.

I am grateful I learned the hard parts. The machine language. The C. The UNIX. The Linux. The Windows. The application security work. The years spent close enough to the machinery to respect it and occasionally resent it.

I would not trade that background. It shaped how I think. It shaped how I work. It shaped how I judge systems.

But after forty-five years, my standard has become surprisingly simple. Can I sit down and get the task done without thinking about the platform?

If the answer is yes, good. That is the job. If the answer is no, then the platform has made itself part of my day.

Sometimes that is necessary. Often it is not.

The younger version of me happily spent an evening figuring out why a sprite flickered or why a routine would not fit into memory. The older version still respects that kind of problem. He simply does not want every routine task to feel like a small engineering project.

After all these years, I still like computers. I just like them best when I do not have to think about them too much.