About

Don Castle, founder of Digital Life Compass

I’ve worked in the information technology field before it was called IT. Starting as a typical 80’s geek, dragging my 19″ CRT monitor over to friends’ houses to play Doom all day. For more than 30 years, I have been fascinated and amazed by computers and their potential. The last 23 years of my career were spent supporting a postgraduate school at a university in the southwestern United States.

I was the first IT person they hired when they opened, which meant that for a while I had my hands on essentially all of it — every computer, every printer, the network, the servers, whatever had stopped working that morning or in the middle of the night, it was I who fixed it. Others joined as the school grew. With them we kept the school operating day to day and kept it updated on technology from Audio Visual in the classrooms to mail servers to just about everything.

Somewhere in those years, I learned the thing this entire site is built on. Computers have a language of their own, and that language is great if you speak it, but if you don’t, it can cause problems for those who can or will not learn it.

The lesson that changed how I worked

If I fixed someone’s problem, be it a problem with a mailing list or a Word template or even why they should not use their built-in coffee cup that comes with all computers. (CDrom) Even if I fixed a server issue, I then had to explain to my boss why it was down for so long or why it went down in the first place. All of this came down to finding a way to explain things in a way they could understand. What I learned was that if I found a way to explain and not just assume they understood, I had fewer return visits or questions afterward.

Taking two extra minutes to explain why it had happened, and explain it in non-technical details, I found I had far fewer repeats of the same mistakes.

Not because I’d turned anyone into a technician. Because they could now see it coming, they knew why doing things the way they thought worked did not.

I want to be careful not to oversell this. It wasn’t magic, and it didn’t work every time. But across a lot of years it cut the common calls down noticeably. Someone who understands roughly why a login keeps looping, or why a file didn’t save where they expected, tends to stop walking into it. Teaching someone to hit save on a Word document in the mid 2000’s every few minutes saved a whole day’s worth of work when they existed and forgot to save.

That’s the whole idea here. Concepts rather than specifics. Enough understanding to work with something confidently — not enough to build one or become an expert but enough to understand why.

The second thing that helped

The other habit was less interesting and more useful: use software and hardware the way the people who made it intended. If you use a Mac, please use it the way Apple intended.

We ran what the work required. But we ran it the way the vendor designed it to be run. The documented setup, the recommended settings, the ordinary path. Not because vendors are always right. They aren’t. But the well-worn path has fewer surprises, and clever configurations tend to break in clever ways, usually on a Friday afternoon while a professor needs to send off a document that was due 2 hours ago.

Why I started writing this

I was fortunate enough to retire, and what strikes me now is that both of those principles still hold. If anything, they matter more, because the things people are being asked to trust have gotten stranger.

AI is the obvious example. Almost nobody needs to know how a language model works internally—but knowing roughly what it’s doing — that it’s producing plausible text rather than looking anything up — changes how you use it. You stop being shocked when it invents a source. This should help you start checking the things that are actually worth checking. That’s concept-level understanding, and it’s the difference between a tool you can use and a tool that occasionally embarrasses you.

Who this is for

People who use technology and would like to understand it a bit better. Not people who work in it.

If you’ve ever found that technology writing is either too basic to be useful or clearly written for somebody who already knows the answer, that gap is what I’m aiming at. I’ll assume you’re intelligent. I won’t assume you know the jargon. People vary on how they take in information, so please let me know if what I say is still confusing.

I’m not writing for developers, IT professionals, or anyone already deep in a subject — there’s plenty out there for them already.

How these articles get made

Every article is checked against primary sources: vendor documentation, security advisories, government guidance. Those sources are linked in the article so you can review my work rather than relying on my word. Anything that depends on a date, a price, or a version number gets dated in the text, because that kind of fact goes stale quietly. I do my best. Don’t assume I am always right. Sorry I have to say this: for one, it’s true, and two, it covers me legally. No one is perfect.

I read and approve everything published here, and I’m accountable for what’s in it. Where AI tools help me is in research.

And if I get something wrong, I’d rather hear about it and fix it in the open than leave it sitting there.

What I’m not

I’m not selling anything. I do consult but not often and mostly for family and friends. I’m not a replacement for a professional when the stakes are genuinely high. If a business network has been compromised, or money or a legal question is riding on the answer, get someone who can look at your actual situation.

What I can do is explain what a thing is, why it behaves the way it does, and what a reasonable person might do about it. Most of the time, that turns out to be enough.

Where to start

If you’re new here, three that cover the most ground:

Or browse everything and start wherever your own question is.