Emotions as a Technical Signals
Philosophy of emotion · Software engineering
Imagine you are checking production metrics before picking up a new task. Nothing is alerting yet, but you see that something about the traffic graph feels off. The shape of the throughput line is not the usual smooth waveform. You see sharp micro-spikes hitting the origin at irregular intervals. It is subtle enough that an automated alert would set off, but your heartbeat picks up and you can feel a bit of fear. You pause for a couple of seconds, your eyes locked on the dashboard. Why does this pattern feel dangerous? You check autoscaling events, CPU utilisation, load balancer request distribution. A slack message appears asking for a quick PR review. You do not answer the message straight away, as your fear keeps you concentrated on the graph. You then start to think that if this pattern keeps increasing, the service may not scale quick enough.
The fear you experience helps you notice that something is off and alerts you of its importance before your reasoning fully catches up. You send a message to your colleague: “Traffic pattern looks strange. Can we pair on this quickly please?” They join the call and, within seconds, they have the same reaction. No one is panicking but you both go into incident-prevention mode: you check the last deploy, verify autoscaling limits, recent code changes, security logs. And a few minutes later you spot a recent change that had accidentally reduced the max task count on your ECS service. The service was silently hitting its scaling ceiling. This caused irregular micro-spikes in throughput as the containers hit their limits and triggered retries. You think that if traffic kept rising, user-facing latency would have spiked. Fear drew your attention to this problem, before the service failed. It made you focus on the issue, helping you to diagnose the situation. It helped you prioritise correctly, focusing your attention on the issue.
Emotions are not always distractions, or irrelevant feelings that hinder our ability to produce good software. They are a valuable source of information when properly understood. They can alert us about what is happening in our environment. They direct our attention, they motivate us to act. They present things as having evaluative properties such as danger, opportunity, unfairness, loss. In the above story, for instance, the fear and anxiety alerted us that there was a danger, namely that the service risked becoming unavailable. Philosophers and psychologists have different views of what emotions are (e.g see Deonna and Teroni 2012 for an introduction), but in general they are understood as mental states that:
- Represent their object as having a certain evaluative property
- Are about a certain object
- Come with a certain pattern of bodily changes
- Have a certain intensity
- Influence attention and motivation
- Have a specific phenomenology
As in this example, emotions are important from an epistemic sense, that is, for the information they convey. In this case, the fear alerted you of a potential danger: that the service could face latency issues, before your reasoning had fully identified the cause. It directed your attention to the potential danger and motivated you to investigate the anomaly. It made you feel that this work had more priority than answering a slack message or picking up a new task. It prompted you to inform your colleague (and perhaps your manager too) to avert the issue. It came with a certain intensity that made you feel the urgency of the situation.
Emotions alert us about features of the situation that matter to us. This includes situations that we encounter at work. They are triggered not only by actual events, but also by anticipations and gaps in what we experience.
Imagine reviewing your colleague’s plan on a CDN migration. As you read through the plan, you see a line that says “the platform team will migrate all production domains in a week” and you realise that the team was not consulted on the timeline. In this case the emotion helped you to detect a missing assumption in the plan. The team was not involved in the estimates and the work was oversimplified. The fear, in this scenario, made you feel that there was a gap, and motivated you to look into the gap to understand whether it could be fixed.
I have considered two fictional scenarios here, but these scenarios present features that can easily be experienced by engineers. The lesson here that software engineers should take is that emotions are epistemically significant. To understand the key information that emotions present to us, we need to know what evaluative properties emotions track. If we just focus on the basic emotions, they track the following:
| Emotion | Evaluative property |
|---|---|
| Fear | Danger |
| Joy | Progress towards the fulfillment of a goal |
| Disgust | Obnoxious |
| Anger | Unfairness or unjustified obstruction |
| Surprise | Unexpected event |
| Sadness | Loss |
Emotions should matter to us, software engineers, because they can make us better at our job. As we have seen, with the fear scenario, they can make us detect features, they can help us diagnose the problem faster, they can help us identify missing assumptions and understand risk not only conceptually but intuitively. They help us to prioritise under pressure and to communicate and feel urgency.
Of course, like any source of information, sometimes emotions can be misleading. They can exaggerate the risk, they can blind us, and can make us waste attentional resources. But understanding what each emotion tracks helps us to judge when the emotion we are considering represents something true, or not.
I am not trying to convince the reader that we should be trusting our emotions uncritically, but understand how they reveal values we may not yet have articulated, and how they influence attention and motivational tendencies. For software engineers, who often work under uncertainties, face trade-off decisions, awareness of emotions can make reasoning sharper, faster and more humane.