Mental Models of Programmers for Non-Programmers

Programmers are a tricky lot. We have a certain mental model of how things should work and we "hack" systems in order to make sure they fit our mental model instead of changing ourselves and our mental model to fit with existing systems. Programmers are the bureaucrat's worst nightmare -- our brains are wired to look at the rules and go "why?" and our immediate reaction to anything that's not at least optimal is "well, that's stupid".

If you have a programmer in your life -- a parent, sibling, cousin, partner, or friend -- it would help if you understood how most of programmers brains work. I would even say as far as certain kinds of people -- not necessarily programmers -- gravitate towards becoming programmers (or engineers, or any profession/occupation where it involves building systems or just rigorous analysis and design) so you may recognise these people. I know these things work really well for me so if you know someone like me it might help you a lot with your interactions with them.

Logic

First off, we have a twisted sense of logic. Anything illogical or something approaching even asymptotically the thought of being illogical cause two things to fire in our brains (or at least my brain):

• Quick! Someone's wrong! At least that's the immediate reaction. Being illogical is something we equate to being wrong. What's right is when something is logical. Religion is hard to understand for most of the people who have this way of thinking about the world. Logic is the measuring stick by which everything is evaluated. If you must, see Spock.
• Bullsh*t. Usually we stop listening to the person or to the source of the logical fallacy or just whatever is being said. The masters even just acknowledge the illogical statements and leave it at that. The newbies will call it out, usually followed by some snarky remark about the person or the statement being stupid. Again if you must, see Spock.

We have a myriad of actual outward actions ranging from the incredulous shouting and being "rude" interrupting the logically inaccurate person, to just outright ignoring the other party. We are straight-forward like this and it's only logical for us to stay this way.

I realize that I'm painting of a very dim picture of programmers and our ilk. What matters to us in these situations is restoring (or affecting) the situation such that all is right and logical in the world. You can help us by saying something to the effect of the following:

• "In reality..." -- this qualifies that you're stating an observation, not an assertion or an argument. You can use this when you get into one of the logical flame traps that we inadvertently place when we hear illogical or potentially illogical (or logically interesting) statements.
• "I understand that you think it's illogical. However ..." -- this is almost like the above, except you are now acknowledging our thinking, which is important in programmer-speak (or protocol if you must) because we tend to repeat what we say until we are acknowledged.
• "Yes, it is illogical. Let me re-state that as ..." you can agree it's illogical which dowses water on the spark initially raised in our brains when we hear something potentially or really illogical. We usually don't mind it when people are wrong, as we all make mistakes ourselves. Dwelling on mistakes is not something we do a lot -- but when we see others dwelling on it is when we think it's wrong or illogical. In which case read back up to the top.

Now we also tend to get illogical when we feel attacked and that's the next point.

In general, when having a conversation with a programmer, please try to be logical. We appreciate it.

Feelings

We are a sensitive bunch. We don't like acknowledging it but we are humans too. We are tied to the result of our labours and we treat them as children. Our projects become our lives typically and we have this somewhat illogical search for perfection -- I know, the irony is not lost on me. When you're going to say something about the following, please be mindful:

• A gift. See the point on being logical above. Then consider that we are really sensitive. If you think you don't like the gift we've given you break it to us gently.
• Our project. If you have not heard the programmer talk about the project they're working on in disgust, do not ever do it first. Even in cases where the project we're working on is not our choice, do not ever feel obliged to tell us our babies are ugly.
• Our accomplishments. It is taboo to downplay accomplishments -- so if you're going to ever say anything about accomplishments, you better be saying something good. Otherwise, say nothing at all.

Programmers also typically do not show feelings outwardly very well. From an outsider perspective we may be in only three states: asleep, indifferent, or thoroughly incensed. See the point about Logic again -- you will notice that programmers get angry a lot because in the rare cases we do show emotion, we show the strongest and most effective one. How do you know a programmer is happy? When they're asleep or indifferent. If you notice they are incensed a lot of the time, something is definitely wrong -- probably something that's illogical.

If you want us to convey our emotion, you have to pull it out from us -- we optimise our emotion showing to the bare minimum required (unless there's something wrong or illogical). If you want, see the conundrum on Shrödinger's cat -- our emotions are in a box, and the only way to find out whether we're happy or unhappy is to open the box; that way you cannot tell whether you made us happy or unhappy by opening it.

There are ways to ask us if we're happy or unhappy and here's a few that are really effective for me:

• Logic dictates predicates. That's the long way of saying "I observe you are unhappy. Is this accurate?"Okay, just ask us, but only if we see there's a reason for the question. Context is important, and if we're at work and intently doing something, do not ever think that your knowing whether we're happy is more important than what we're currently doing. Ask us when we're idling. More on when to find out whether we're idling later.
• Smalltalk is irrelevant. Get to the point. If you want us to do something, ask us directly -- we prefer questions that can be answered immediately with "yes" or "no". Again we optimise for the minimal interaction and emotion showing required.
• We usually don't play politics (unless we have to) so we usually don't care what other people think. If you want to know what I'm thinking, what I'm feeling, or our opinion do not predicate it with some notion of being politically correct -- just ask me. Preferably by email. If it's important, maybe via IM. If it's something politically motivated, we're probably only going to engage you if it's a logical dispute in some social realm (like family, friendships, community groups, etc.).

Another thing that's important to note is that when it comes to us volunteering our emotions, do not interrupt us because it is a high-bandwidth exercise for us. If we're telling you we're happy, unhappy, angry, sad, or <insert emotion here> please acknowledge that you received the message at least.

This then leads me to the final point about communication.

Communication

If you for some reason have a programmer in your life that works on network systems (websites, distributed systems, or something else involving communicating systems) you may find that they are sometimes really engaging when communicating. You find people who work on these systems really fascinated by three things: latency, throughput, and protocol. Let me explain a little of why these are and why I think it translates to the wetware systems of human society:

• Latency is the amount of time between message transmission and reception  It is something measurable and usually detectable (and hence, manageable and can be optimised). We care about getting our messages across as fast as we can so that we see the effect as soon as possible. If we ask you a question we typically expect latency to be low -- otherwise we view it as illogical and proceed to diagnosis and troubleshooting mode; see the point on logic above.
• Throughput is the amount of information you can transfer in a given period of time. This is important to us because the more time we spend sending the message across (at acceptable latency) that means the less time we're working on our project or we're somehow becoming "sub-optimal". We tend to cram in as much information as we can in the smallest amount of time we can so that we don't have to do it for longer than we have to -- because doing that would just be illogical. See point about logic above again.
• Protocol is a systematic approach to sending, receiving, and coordinating the exchange of information through a medium. We like minimalist and flexible protocols, especially if that helps the latency and throughput. The less time we spend worrying about protocol, the more information we can transmit and hopefully the less latency between message sending and receiving. We view heavy protocols as being something "illogical" and hence "wrong". This is the reason why we like email, sending long messages in a single go, and worry very little about the sugarcoating of the message.

There are exceptions to optimising out these things -- usually when we are idling (more on this later) we prefer to waste as much time as possible doing as little as we can. This is the complete opposite of worrying about latency, throughput, and protocol. Another exception is when we realize we are in a setting that is not optimal for any sort of hacking -- like in the presence of a huge crowd, crammed in a social setting that's unescapable (a train, bus), or when we're in non-programmable situations (like when on a date).

The thing to remember is, when you're communicating with a programmer is: content trumps delivery. This is why we prefer email and avoid the awkward emotion conveyance involved with face to face communication. We typically do not optimise for sending the correct emotion, we rather send the correct content. We tend to be blunt and direct but this is optimal in our brains -- or at least we logically concluded somehow that emotions are a waste of bandwidth (the practical limits of the amount of information we can convey in a period of time).

So when you think we're being rude or direct, chances are we're in programmer mode. There are two things you can do to manage this situation:

• Acknowledge the content, then engage us by asking more questions if you need more information. We are being direct because we usually think much of the information we're not sharing is not worth sharing, or that we assume you already know most of it. We are optimising for transmission and if what you seek is engagement you should engage us further -- and no, we will not pick subtle hints and our default position usually is brevity.
• Convey that you want to be informed more and that if this is not a good time that some other time should be scheduled for actual interaction. We usually make a decision of whether this is a good idea, whether there's no other information needed to be conveyed, or we take this as a signal that we're being too terse and would probably need to elaborate.

This communication thing usually reverts to "normal person mode" in the weekends or during non-project working hours. With that point, I lead to the last thing to recognise: we like our breaks and we like idling.

Idling

This is usually (maybe correctly) perceived as procrastination. This is however an important part of programmer routine. You will usually find us idling when:

• We seem to be "reading". It usually involves a device or some physical artefact -- book, magazine, etc. You know we don't want to be disturbed when we are in a secluded location but otherwise (unless we're doing actual deep thinking, which should be obvious (logically)) this is a good time to engage us in conversation.
• TV time. If we're flipping through channels, that's a good time to interrupt. If we're watching our favourite show, we're decidedly not idling. If you are a child or significant other, sitting beside us and watching with us is enough to count as bonding time (at least for us). If you show genuine interest in what we're watching, we will definitely engage you on the same subject. It's only logical that we do.
• Recreation time. Some people like playing pool, card games, board games, going out for a swim, or in general just playing. This time is perfect for conversation because it's the few times we're almost completely switched off from whatever project we were involved in. If you can schedule meaningful non-emotional conversation during these times, you're golden.

In general when programmers take a break (or wait for their code to compile) is a good time to have conversations with us. You might find that we have a routine -- I for one like watching the news until late into the night to "switch off", and I definitely appreciate having conversation at those times instead. Another thing I do is lie in bed reading some book I've thought interesting through a device (usually my mobile phone or a tablet).

It is best if you can synchronise and recognise the idling times and make the most out of it with the programmer in your life.

Conclusion

This is a piece I've wanted to write for a long time now and I thought I might as well write it down while I was "idling". I also thought it might help some friends I know who are programmers realize how sometimes we are a little too Spock and a little less Kirk (and I submit we should be a good mix of both for good balance in our lives). Some of us are lucky that we have people who understand while I'm positive there may be a few programmers out there (and friends or family of programmers) who have very little idea in how to interact with us.

I do not claim for this to be a definitive guide, I'm just sharing my thoughts and throwing it up to the void. As with anything you read on the internet, take with a grain of salt and your mileage may vary.

Do you have any other tips for non-programmers on how to synchronise their mental models with ours? I'd love to know your thoughts on this.