Sam's Rails for Technology

Until we put our tech on some rails, it can only ever take us off the rails. Complexity is an emergent property of technology, and if we want simplicity we are the ones that have to create it.

Like a train on railroad tracks, we can create clear and efficient paths to carry heavy loads from point A to point B. This is very different from making systems to go anywhere and do anything. Here are my rules (well, more guidelines really!) that help keep my infrastructure robust and well-thought through so that the trains can run on time. Metaphorically speaking.

1. Anonymize whatever is legally permissible
2. Secure what is personally identifiable
3. Enter only where there are exits
4. Interoperability or bust
5. Struggle for only up to 25min at a time

1. Anonymize whatever is legally permissible

There are lots of services that want to have all our information. They sell us on all the benefits with big print and big promises, but acknowledge the risks only in small print with a “whaddya gonna do?” take it or leave it attitude.

That’d be great if they could secure this info about us, but they cannot – even if they wanted to. The big benefits go to them, and big risks are our problem.

Fortunately, there is an identity option that is totally legal in most cases: make it up! As a rule, whenever possible we can simply chose to offer nothing personally identifiable or uniquely identifying. Generally, nobody tells you that you can do this or that you might want to. Service providers will tell you that you shouldn’t or can’t, and they’re mostly wrong about that for legal reasons.

But not always. Obviously for banks, hospitals, and governments, this doesn’t work. What then? On to the next rule.

2. Secure what is personally identifiable

It’s as unfortunate as it is common, but financial institutions and medical providers and government agencies are tragically bad at securing our information. You’d think with all the regulations and other hoops they have to jump through that their security would be stronger, but instead it’s atrocious.

It’s reasonable to assume that anything you share can and will become public information. Because it probably already has! And if it hasn’t yet, just wait until the AI botswarms descend or quantum computer decryption is sold to the highest bidders. Rather than getting scared or angry about these eventualities, we can simply expect that our info will be shared, and make a rule that we always secure whatever is personally identifiable ourselves. While we can’t control how others custody our info, we can control how we do. These backups and proof create a line of bureaucratic defense and means of straightening things out in this crooked world.

3. Enter only where there are exits

All the big tech companies have their “walled gardens” where they leverage network effects to make things easier. They’re trying to increase switching costs because it’s cheaper to keep existing customers locked in than it is to convince new prospects to become new customers.

This rule is basically “do not fall for that trap.” Don’t walk into someplace you can’t freely walk out of, meaning any integrated platform that tries to do the lock-in thing. For me, that doesn’t mean won’t use Apple products, for instance. But that I won’t log into iCloud and do the iThingies across my iDevices. The hardware stands on its own, the software can be a trap.

4. Interoperability or bust

This is an extension of rule #3. Innovation is great! I often am out on the cutting edge with my workflows, but when I am, I need the safety of knowing that I can take my information and port it someplace else.

As an example, this post was written in markdown – a text format that will never expire. It stays eternally interoperable. If something isn’t at least exportable and transportable and backupable on my own local system, then it’s not for me because it is building a dependency that I cannot abide by.

5. Struggle for only up to 25min at a time

I don’t know about you, but I can rail against a technical problem for a long, long time. It doesn’t necessarily get any better over time though, it can just get worse and more frustrating and lead to poorer decision quality.

This last rule is that I can struggle as much as I like in 25-minute increments, but I can’t spend hours and hours (or days or weeks) working through something. This means I have to put my tech struggles on a calendar and keep an eye on the time. I have to scope whatever problem I’m working on to pomodoro-length, implementable, solutions. This keeps it real. When I’m taking too much time trying to make something work that clearly doesn’t work, I notice sooner. And get frustrated less.

Because the goal is simplicity, the goal is building rails.