Talk to the Process, not the Machine.

Decades ago, computers could run exactly one process at a time. Nowadays, modern operating systems let us run multiple processes on a single processor. Modern  microprocessors generally have multiple cores, as well. This means that on any modern machine, there are generally many different processes, all running in parallel.

I’m writing this using a text editor (vim) on a desktop computer. The desktop computer is currently running an operating system, which is switching rapidly between dozens of other processes at the same time.

Suppose I switch between the text editor, my web browser, and a chat client while writing. Someone on the outside watching me might conclude that “I have spent this entire time interacting with the computer.” This much is true, because I’ve remained sitting in front of the same physical object.

And yet, even though my physical position hasn’t changed, and i’m typing on the same keyboard, the processes I’m interacting with have changed throughout the course of my action.

If you want to really understand what I’ve been doing, the processes are usually more important than the physical box I’m interacting with. For example, if I have this text file saved on a cloud storage platform, I can edit it from different machines. This is a very different situation from using the same physical computer to edit different text files.   The first version of this paragraph was written on one machine, using vim. A later version of the paragraph was written using Google Documents, on a different machine. Yet in both cases, I’ve interacted with the same piece of data.

In short, when you are thinking about computer systems, you generally need to look past the physical box, and instead focus on the flows of information involved. The physical boxes themselves can do all kinds of things, but one of the biggest benefits of the way computers work is that that we can often ignore the computer itself.

You get much more understanding from knowing which flow of information you are dealing with, rather than knowing exactly which box you’re interacting with. I think physical people are similar to physical computers: they are elements of information flows, but not as important as the information flows themselves.

Imagine that each person is running a number of different processes inside of them at all times.   When two people communicate, it’s really these processes communicating with each other, through your bodies, and the outside world.

In other words, I think most engineers are entirely familiar with the idea that we can usually ignore all of the boxes in the middle here:

My point is that even the people should just be seen as intermediate hardware. What matters are the raw thought processes. These processes are communicating with each other, through a network of computational hardware, which includes both human machines and the physical devices those human machines have built.

Ok, but what are the processes themselves?  If you’ve been reading thus far, you might feel like I’ve just said the same thing over and over again. “Humans are machines.”  The key point with this ‘process’ idea is that lots of processes are running at one time, and it’s important to understand the dynamics of whatever process you’re talking to.  There’s one process, however, that always runs. On machines, we call it the operating system. In humans I’d say it’s an “animal process”,  – but you can also say it’s “emotion.”

Humans have fears, drives, desires, and hopes. These are the operating system we use. If you send bad signals to a process running on a human, the human operating system will step in and try to protect its host. Human cognitive hardware is very security-conscious.

For example, consider a secretary at your office. This secretary might be running a number of processes, such as:

  • Animal: looks for safety, food, comfort, and relationships.  This process runs on all humans, at all times!
  • Employee: Listens on a port for instructions from an authenticated user, executes those instructions.
  • Musician:  Listens to music. Generates musical sequences and evaluates them.  Searches for information about music. Engages in small talk about music.
  • Citizen: Has identifying information. Has a place of residence. Has preferences in political systems. Votes.
  • Animal Lover: Has two cats. Volunteers at a shelter.

When you attempt to interact with the secretary (the physical machine), your attempt may fail if you attempt to interact with only the employee processes. Even if you are an authenticated user and you submit a valid request, you may still get results that you don’t like. the reason is simple: the operating system got in the way.

Imagine that the building is on fire. The ‘animal’ OS that runs on the employee’s hardware will immediately seek shelter. At this point, other processes, such as employee, will stop receiving any processor cycles. If you approach the secretary while the building is on fire, you will probably get an unpleasant response – even if your approach is a validly formatted ’employee’ request.

That unpleasant response is coming from the animal operating system. Remember, the human hardware is just the messenger. The message itself is transmitted by their animal software, to your animal software, through a physical medium which consists of facial expressions and swear words.

The animal process has top priority. All human beings run this animal process, at all times. All of the input you wish to send to other processes has to go through the animal process first. The animal process might reject input you’ve intended for other internal processes.

If someone’s animal process feels unsafe, that person is unlikely to be interested in engaging in logical back and forth with you.  Any messages you try to send to their logical processes will be intercepted and modified by the animal process – or simply dropped. This is true even if you’re not the one threatening them. Rather than conclude ‘this person is irrational’, there is more utility in seeing that your attempt to interact logically with an animal was irrational. The rational approach when dealing with an animal system that is no threat to you is to be kind, calm, and caring. This approach will get you the best outcomes.

I think most people understand, intiutively, that it would be a bad idea to ask someone for help filing a document when the building is on fire.  What I think is less obvious is the fact that, for similar reasons, it’s a good idea to engage in small talk with people that help you out.

To ensure valid interactions with processes running on any human machine, you need to be on good terms with the animal process on the same human machine. If you have interacted with processes on this machine many times, and know nothing about its other processes (musician, animal lover, citizen), the animal process may reject your input. Humans are pack animals. If you fail to interact with this human along any dimension other than ’employee’, you are telling this human’s animal process ‘I do not consider you to be a member of my pack. I consider you to be a machine.’ Most humans do not like to be considered as machines.

Yes, I see the irony here. The whole blog is about how to think of people as machines. The goal, ultimately, is to help other engineers improve the ways they interact with people. I think people don’t like being considered as machines because people don’t generally empathize with machines. Because I do empathize with machines, I find it natural to think of persons this way as well.

One of the first lessons I learned, in attempting to improve my interaction with humans, was to consider the entire machine, and not just the single process I was interested in engaging with at the present moment.

So we can think of a mind as being like a computer running a lot processes in parallel, with an animal process as the operating systems. Well, what exactly are those other processes? We’ll get to that next time!

Further Reading

The book ‘Crucial Conversations‘ is a how-to manual for improving your ability to have difficult conversations with people. The authors don’t seem to think humans are computers – as far as I can tell. However, the basic premise the book advances is that you need to make sure the animal process on the remote machine you talk to feels safe. They also model conversations as involving “a shared pool of information”, which sounds somewhat like distributed databases converging on a consistent state.

If you’d like a model of the human stack that’s more complex than just ‘animal process’, check out the book “Hardwiring Happiness“, by Rick Hanson. He uses a stack-based model of the animal process. At the bottom, the ‘lizard’ process seeks safety. Its primary drive is to avoid danger. Above that, the ‘mouse’ process seeks rewards; its drives are to obtain food and shetler. Above that, the ‘primate’ process seeks relationships and connections with other people. Of course, Hanson doesn’t use the word ‘stack’ or ‘process’, but we all know what he’s talking about.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.