How to Learn Technology

Nearly everything confusing about computers becomes clear once you can place it in a stack. Hardware runs an operating system; the operating system runs applications; applications work on files; files travel over networks. Almost every support question anyone has ever asked is a question about one specific layer.

The practical benefit is diagnostic. When something breaks, knowing the layers lets you ask which one failed. Is the network down, or the service, or the app, or the file? People who cannot do this try random fixes; people who can narrow it in two questions.

The internet is infrastructure - machines agreeing on how to pass messages. The web is one thing built on top of it, and it arrived two decades after email did. Both use the internet; neither is the internet.

Keeping them separate clarifies an enormous amount. It explains why an app can be down while your connection is fine, why email works differently from a website, and why the phrase the internet is broken is almost never accurate.

Most compromises are not technical break-ins. Somebody was persuaded to hand something over, or reused a password, or clicked a link. The cryptography is generally fine; the humans are the attack surface.

The consequences for what to actually do are unglamorous and effective: a long unique password per account, ideally from a manager; two-factor authentication on anything that matters; scepticism about urgency, because manufactured urgency is the common ingredient in nearly every scam.

Length beats complexity in passwords, which is the opposite of what most advice said for twenty years. Guessing attacks scale with length, not with whether you substituted a zero for an o.

You do not need to become a programmer, and a few hours of actually writing code changes how you understand everything else in the subject. Nothing else teaches as quickly that a computer does exactly what you wrote rather than what you meant.

The three ideas that matter are sequence, condition and repetition - do this then that, do this only if, do this until. Essentially all software is those three composed. Once you have written a loop that ran one time too many, the phrase off-by-one error stops being jargon.

The single most useful frame for machine learning is that it inverts normal programming. Instead of writing the rules, you supply examples and the system derives rules that fit them. Everything else follows from that.

It follows that a model reflects its training data, gaps and biases included. A system that performs badly for a group usually saw too little of that group, and no amount of tuning fixes absent data. It also follows that these systems are confident in exactly the same way whether they are right or wrong, because confidence is not connected to correctness in the architecture.

That is enough to be neither credulous nor dismissive, which is a more useful position than either of the ones on offer publicly.

A large share of your experience of technology is designed by people whose interests differ from yours. Attention is sold, defaults are chosen deliberately, and friction is added and removed on purpose.

Asking who benefits from a design decision explains a great deal: why unsubscribing is harder than subscribing, why the accept-everything button is bigger, why an app wants notification permission at first launch. This is not paranoia, it is reading the product correctly.

The test of whether this has worked is whether you can approach an unfamiliar device or service and make sensible guesses about how it works. That is what structural knowledge buys, and it is why it is worth the extra effort over learning where the buttons are.

Start with what a computer is, then how computers talk to each other, then how not to be the weak point. Those three cover most of what a person actually needs.