The Emotional Programmer


by Chris Douce

Occasionally, if I am asked the essential question of 'why' I wrote a collection of functions a a particular I may not immediately have an answer. I have an instinct to reply, 'because it feels as if this the best approach', especially if some time has passed between discovering a design and the request for its justification.

When developing software, I seem have acquired a sense of code aestetics, of what good software should look like in terms of function construction and naming, its use of memory and processor resources, and how a problem has been decomposed. Here, we can return to the earlier concept of 'hacking and painting' that has been touched upon in a previous newsletter. The emotion inherent in successful programming is connected to the idea of refactoring where programmers can find evidence of less than satisfactory coding in terms of 'bad smells'. The refactoring idea introduces the programmer to the world of program aestetics through appropriate justification.

The use of 'feelings' within the discipline of computer programming or software engineering, a discipline that demands that programmers conform to the cold, hard, unforgiving logic of a machine seems to be a paradox. Perhaps the most fundamental question to ask is 'what is emotion for, and can it in any way help our quest to create truly great software?' Again, I have very few firm answers – only questions, and a number of interesting examples. My first example comes out from immediate experience:

Some days I wonder whether my chosen occupation is one that really makes me happy. I seem to chase a continual whirlwind of software releases, upgrades and security fixes (not to mention the coming and going of which might be software fashions). Somedays, rather than feeling happy, I seem to feel perpetually confused. But confusion is good. This 'feeling' of confusion is a metacognitive state. It means that you do not have a full comprehension of a situation or a system.

Emotion is a guiding force that complements our rational capabilities. We are made to feel uncomfortable if things are not understood. When sub-goals are acheived we may become happy. Eventually we may feel 'proud' at what we have acheived. Uncomfortable feelings can be motivators – they can be harnessed to produce positive results, providing, of course, they are recognised.

Memory researchers have known for a long time that emotions strengthen memory. When searching for a solution that 'feels right' (and does the job it supposed to), not only do we remember facts about programming language semantics and the functions within an API, we also recall situations that were successes and failures: code coloured by memories of past frustrations and successes. Expertise isn't only the possession of domain specific facts and knowledge, it is facts and knowledge that is retained alongside events that gave rise to particular feelings.

Emotion comes into the equation from another perspective. If a project you have been working on for two years is cancelled, those who invested time in developing solutions to problems are bound to be upset, bewildered and angry. Even though we may try to recall Weinberg's concept of the 'egoless programmer' I believe such notion is noble, although idealistic.

In egoless programming, the artefact and the programmer should be separate. You should not 'put yourself' into your program – it should not have your soul. I have to say that when I write a program I am somewhat guilty of 'putting myself into it'. The argument that allows me to make this justification is that it is my time that has allowed the program to be constructed. This said, it may be possible to get more out of a program than what I have put in, especially if my work is constructively critiqued – something that every programmer should welcome. (All coders have some daemons they might want to confront).

Working in programming pairs, we are duty bound to consider the sensibilities of our coding partners and have an appreciation of their knowledge, expertise and sense of code ownership. 'Is it alright to change this?' a member of a pair may ask, 'if you don't like it, we can change it back, I just want to show you something…', a dialog may go. I'm looking forward to finding out more about ethnographic studies in this area.

Let's now turn our attention to the emotional sounding job title of 'evangalist' Where can I get one of these jobs from? Being an evangalist sounds great fun – it sounds as if there is a lot of shouting to do, preferably in front of large numbers of people who are likely to be willing listeners. The word 'evangalist' causes other words to spring to mine. An evangalist must be an 'enthuser' and a 'persuader'.

Software companies know all about programmer emotions. One famous operating system vendor is particularly good at using all the tricks in the marketing book. You can see the joy on the faces of those programmers. Look at how happy they are as they discover how to work more efficiently! Look at how they love intellisense! Isn't it great!

Other vendors are not immune to displaying the smiles of the happy coder, but instead apply the youthful conception of 'cool' in an attempt to allocate a maximum amount of developer_happy_space.

An interesting contrast can be seen if we view one of the greatest open source development tools: Eclipse. Why is there such a marked difference in style? Perhaps the focus of emotion lies with collective success rather than individual happiness or achievement.

As well as attributing emotion to software organisations, emotion has a role to play when it comes to forming 'mid-level' judgements: choosing whether or not to use a library, package or language to solve a particular task. Micro-level emotional judgements could be construed to be judgements about groups of individual programming constructs, notation within drawing or design tools or textual explanations within documents, Macro-level level judgements are those relating to organisations, vendors and/or programming paradigms.

Our emotions play a key role when it comes to deciding who we trust. We trust people more if we have benevolent feelings towards them, and this is applicable just as much to groups as it is to individuals.

Trust is a particularly interesting issue due to the availability of source code and libraries on the net. Should we trust what the executive summary or comments at the top? Does the code do what it says it will? More importantly, what are other people saying about it? If we don't know someone or an institution, we make trust judgements based on reputation, what insitutional values we detect, and our sense of aestetics. Does it look right? Does it feel right?

There is another dimension of trust too. Just as we may take a leap in the dark and (almost) blindly trust the code of others (open or otherwise), we have tools at our disposal that increase our own levels of personal trust. No where is this more evident than with the explosion of unit-based testing frameworks. We have httpunit, junit and nunit to name but a few. It's your decision if you wish to use them, if you feel they are right for your particular project or organisation.

The cold hard of syntax and semanics is one thing. The feelings that emerge from the activity of programming is something else – but they are connected to each other.

Not so long ago, I stumbled upon a paper that was authored by Keith Oatley and Phillip Johnson-Laird. It's title: Towards a theory of emotions. It was published in a journal called 'Cognition and Emotion'. Imagine how excited I felt at this discovery!

Is thinking about the 'emotion of programming' a worthwhile endeavour? I have a feeling it might be.