The Expressive Coder | Articles | Ant Smith

on creativity, cognition and code

I was just pegging out the washing and, as usual, I first made sure to arrange my pegs on the garden table by colour. Then I was able to choose which colour pegs I wanted to use for each garment at hand. That might sound bizarre (although to some I'm sure it doesn't) - but it isn't a compulsion, it's just how I decided to do the job. Pegging out takes some time. So while I’m mechanically doing the business — turning things the right way out, arranging them for folding — I distract my more conscious mind with the colour choices. I'm an artist, thinking about colour is a useful idle. It helps to elevate what is otherwise a little piece of life's mundanity.

Life ought not be mundane.

We should decorate it with immersive feelings, rather than simply mechanically acting to rational thought. We're not clockwork (sorry Descartes), neither are we production units (#sorrynotsorry Henry Ford). The truth is, we work better when we are wholly engaged in a task than when we are simply impelled to achieve.

I'm not actively trying to subvert the (needful) work, reduce or replace it; I'm just choosing to do it with intentful expression.

And this, really, is what I want from code.

Not just that it runs. But that it arranges itself with intent.

That it invites the reader to choose a peg, to notice the harmonies, the dissonance, the tension in the wind.

That we are not impelled merely to produce, but permitted — encouraged — to compose.

Execution alone is not expression. It is in our compositional intent that we become present.

It's common (although largely anecdotal) knowledge that back-in-the-day the likes of IBM had most success in recruiting programming roles with liberal arts graduates than those from STEM disciplines. Did we somehow forget that along the way?

There was a time when fluency in language, narrative, and structure was seen as a strength in programming — not a sideline. Music theorists, classicists, poets weren’t ‘unusual hires’… they were the backbone of early software teams.

And while we're back-in-the-day, let's reflect on the words of Knuth:

Let us change our traditional attitude to the construction of programs: Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do.

Knuth, Donald E. "Literate Programming." *The Computer Journal* 27, no. 2 (1984): 97–111.

Which is a solid starting point, although today, some 40 years later, I might say "...what we want a computer to achieve (for us)".

Knuth’s vision didn’t emerge in isolation. It built on earlier efforts to humanize programming — to treat it not merely as logic but as lived cognitive experience:

The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. [*my emphasis]

Gerald M. Weinberg, *The Psychology of Computer Programming*, 1971

Oh — and I will apologise for the ‘He’ pronoun there, it does subjugate the contribution of other gender identities to our discipline! (Thank you Ada Lovelace and Frances Allen, among many others…)

As programming matured into a discipline, others began to illuminate the cognitive terrain behind the keystrokes. Françoise Détienne, for example, made a compelling case for designing programming environments with cognitive ergonomics in mind — supporting how humans think, reason, and understand code, not just how machines execute it.

The results of these studies should contribute to the ergonomic specification of programming environments, in order to improve their compatibility with the cognitive characteristics of users.

Françoise Détienne, *Software Design: Cognitive Aspects* (2001), p. 117

In my previous article (feeling the shape of uncertainty) I touched very lightly on these concepts; highlighting in practical terms how code visualisation can respond to the cognitive imperative we see emerging through these references. It may seem beside the point — talking more about colour palettes than state machines — but perhaps that’s precisely the point. We’ve spent decades refining the machine’s perspective. It’s time we honoured the mind’s.

Whilst tooling (visualisation tools that support cognitive engagement) will be critical, we first need an overall approach that will serve us.

I feel (and feeling is allowed) we have missed a key step in the application of these concepts. I alluded to that above when I had the temerity to correct Knuth - we should not so much be telling the story of the code (a perspective that puts the code in pole-position) but rather the story of the code's architecture. Or more precisely, it is through story that we ought to architect the code, so that it and its exposition arises from cognitive intuition of narrative.

But is narrative itself that important? That foundational?

I think so, yes. Narrative "is deeply integrated into how we make sense of what happens and how we figure ourselves into it” (Brooke Miller, Narrativity in Cognition, 2023). Much of Détienne’s works are so grounded. Gerrig & Egidi (Cognitive Psychological Foundations of Narrative Experiences, 2003) explore how narrative comprehension draws on memory, inference, and simulation — core cognitive functions that are activated through narrative structure. Bouizegarene et al. (Narrative as Active Inference, 2024) argue that narrative helps individuals and groups generate useful models of the world, coordinate behaviour, and adapt over time.

In these perspectives, narrative is not decorative, it isn't an embellishment of cognition; it is one of its native forms. From predictive modelling to memory construction, narrative enables us to think, feel, and act with coherence.

What if the architecture of our software spoke to how we think, not just what we think about?

But then, the question arises, how do we harness such thinking in the real world?

Harnessing narrative

Without doubt, aspects of cognitive research touched upon above have filtered down into the real-world of writing code — most clearly within the various agile-style methodologies that abound. That said, evidence of the efficacy of such is pretty scant as things stand. A key impediment to agile lies in the difference between how people think and how organisations behave. The principles of collaboration encouraged in agile teams being at odds with the inevitable concepts of hierarchy and authority found within organisations motivated by 'performance' (profit, KPIs) and regulation.

The difficulties apparent in software development are at least partially external, and relate to the irrationalities inherent in exploitation and the pursuit of profit. I don't intend directly to try and address that. We just have to accept the reality that in a broken world it is only broken systems that make any real sense.

In a Forbes article (Is Agile Really Worth It? Tracy Brower, PhD) I read that just over half of respondents claimed 'improved' satisfaction with deliverables; without citing what 'improved' actually means. So things might go a bit better, half the time, with agile... doesn't sound promising to me. But Brower references a further study (albeit with a broken link) that claims 88% of people find agile working 'improves the quality of life' - which alone makes Agile worth pursuing. If nothing else, it hints at the power of shared cognitive models within a team context.

Note that coding is always executed in a team context - even if that team only consists of yourself and your future self.

What I mean is, there are no silver bullets and the approach outlined here doesn't purport to be one! You'll have to decide for yourself if there may be any perceived value in what I say as to how you want (or are allowed) to work.

And I propose we do so through a Narratival-Exposition Paradigm

Note that I see the approach as being a paradigm, not some kind of implementation model. I.e. a pattern of thinking, a perspective, from which the models we need emerge. So, a way of thinking, a lens through which we explore and develop architecture, code and documentation.

As a simple example. Consider a basic set of mutually-exclusive buttons in a group - only one can be pressed-in at a time. Depressing a further button causes the former to 'pop out', like we found on old stereograms (or like a 'radio button group' in a UI implementation). In a classic UI application, we may create a number of 'button widgets' and somehow attach those to a background 'manager' of the mutex behaviour. Simple, rational, clean. Boring, flat, grey! Perfectly workable in this simple case, but as you build the software up all those layers of grey leave us within a dense fog.

What if instead of thinking about widgets and a manager, we cast the problem into a world of story. Let's say we have a group of Groovers (the button widgets), each with their own distinct but banging beats. Existing in the same SITUATION as they do (the same venue) the appearance of more than one creates a TENSION - that of 'avoiding cacophony'. They each want to play their beat, that is their nature, it is what they do. But when there's two, or more of them, they suddenly acquire tension: I want to play but I want to be heard so I don't want to play when someone else is playing. I probably don't want to play for too long either, thinking about it. And it is that shared tension that lets us realise we need another CHARACTER in the CAST, perhaps a DJ who queues the individual Groovers?

This is story, this is memorable. But more than that. By exposing the mutex behaviour not as a mechanical concern but as a tension that arises when characters co-exist, we attain a much deeper understanding of what this mutex means - we expose not just exclusivity but also a sense of collaboration and synchronisation between the players. Which in a larger, more complex, world (perhaps a world that supports duets as well?) starts to bear real fruit.

In implementation, the logic arising may be highly equivalent regardless the approach. In the narrative-driven case though we will end up with enrichment of the nouns and verbs that appear in that code, which resonate with the originating exposition. We no longer need to think "huh, another manager, what kind of manager, what does THIS one do?", instead we learn the nature of the DJ, as a character, as an entity with which we can develop a relationship. The DJ becomes more than a mutex controller. They’re a character with agency, timing, and presence. Not just resolving conflict, but cultivating synchrony.

Starting with an exposition of narrative gifts us a full-colour picture, that we see and feel.

A grammar of narrative

Narrative is not an invention — it is an inheritance. We have exposed it through story for millennia, across tongues, media, and purpose. We already have lots of clear definitions, examples, of exactly what narrative contains. I've hinted at some potential components above: Characters, Casts, Situations and Tensions; and I'll expand on that here.

But narrative is about so much more than 'plot'. Clearly it also concerns character and situation, but not just these things. It concerns the unique abilities of characters, the metaphysical laws of the world setting, motivations and impediments, lost holy grails, improvisations, interludes and mouse traps.

Plot, in this view, is perhaps our least concern — it is an emergent consequence, a pattern we discover at run-time. It exists in logs, in behaviours, in the traces of execution. What matters more is the architecture from which that plot arises: a lattice of tensions, motivations, and interdependencies that render the system not just operative, but expressive.

There is no definitive and complete statement of what Narrative is, but from the various models available we can construct something of utility. Something that helps us understand the influence and inference that arises between entities.

Here's an initial stab at what a narrative framework may comprise. The following formalisation is not a prescription — it’s a grammar of possibility. A narratival-expositional substrate that might underpin the expressive architecture we wish to compose.

TYPOGRAPHIC INDICATORS

(click or tap any table row to enlarge)

LEXICON

GRAMMAR

I'm not yet certain that I have the right level of abstraction between code and narrative. I’m a little uncomfortable about the appearance of references to logic, and logic type (synchronous vs asynchronous); similarly, the need to provide for selections (indices) of anonymous group entries... these may yet turn out to be impurities in the paradigm that eventually fall-out. Or they may be key in maintaining the clarity of the code/exposition relationships. Time will tell, but then the whole detail remains open to iteration (of course).

It is hopefully apparent how this grammar can be used to generate story, and perhaps how the concepts directly map to code concerns. The two most critical aspects are the FIGURATIONs and the THEMATIC CONSTELLATION. I don't want to expand upon the entire grammar at this point, as that's probably TMI in the first instance... but here's a closer look at those two concerns:

FIGURATION

A Figuration is not what it does, but how it comports itself in relation to others.

Figurations affiliate through CAST Membership within given SITUATIONS, attuned by chords of TENSION

Their perspective is always aligned to a system-wide THROUGHLINE — a temperament or operational stance.

This is not object-oriented. It is narrative-oriented. The figuration isn’t instantiated — it arrives, it responds, it holds space.

THEMATIC CONSTELLATION

Constellations don’t constrain — they suggest orbits. They pull figures into relationship, into angle, into theme.

Each .SITUATION defines a CAST (who is present) and an AXIS (the impulses that the CAST members have).

AXES are made of IMPULSE CHORDS — tensions built from shared impediments or resonant drives.

Across SITUATIONS, thematic drift or modulation can occur. Characters take their figuration with them, but reconfigure their PERSPECTIVE and DISPOSITION to attune to the local axis.

.CAST defines the dramatis personae of tension.

.AXIS defines the orientation of forces that govern figural response.

~impediment is not just a block, but a shared condition that makes action meaningful.

Constellations are not configured they are composed, like chamber music—balancing tone, tension, and thematic recurrence.

A situation may invoke a collision of imperatives, or a resonance of intent.

Both are architecturally meaningful. Both are narratively potent.

Narratival-exposition

The Narratival-Exposition Paradigm: A cognitive-patterned, metaphor-respecting way of architecting and reasoning about code — where structure arises from story, and implementation sings with intention.

The grammar stated above is not meant as a fixed architectural structure, I feel I can't say that too many times! We are (or at least I am) highly conditioned to look at any kind of structure in terms of containership (descendant hierarchies) and interfaces; with a forward flow of ever decreasing abstraction until will land upon codable nuggets. Which is classic 'left-brain' decompositional thinking. In this paradigm though, we don't intend to replace that approach, but rather to provide a substrate - a second perspective - to help frame and guide emergent architecture. Because understanding is different to knowing. And because fundamental narratival cognition adds the means by which we don't just 'know' a thing, but rather we can experience the knowledge of a thing.

The narrative is a means to shape (or share) the knowledge of a complex system as a cognitive experience. It may, or may not, express as resulting OOPs encapsulations etc... but that is somewhat by-the-way. We saw earlier how a narratival exposition enriches meaning and helps us to discover interesting details: that the mutex is less about exclusivity and more about collaboration and synchronisation. We may still end-up expressing it as a simple threading lock in the code, or perhaps we don't — because the system revealed a complexity our decompositional instincts couldn’t foresee.

These two perspectives (analytical decomposition and narratival exposition) are to co-exist as distinct views of the same thing. Connected through a common language, the language of the grammar; nouns and verbs arising from the cognitive experience of the domain.

This is why I call the grammar 'a substrate'. Like any grammar, it is scaffolding—not scripture. It frames expression but does not dictate what must be said. We do that through layered metaphor.

Certainly, it is more useful to think in terms of Groovers and DJs than of FIGURATIONS; or on and off-stage as proscenium division than 2 AXIS of a SITUATION. The grammar gives us hints as to what things we ought to discuss and how we should be thinking about them - but it doesn't tell us what those things are to be. We get that from layered metaphor.

Which is why I allow for the synonymic operator ('a' as 'b') in the grammar. Super simple in its conceit, yet foundational to the paradigm. We may use it thus:

Etc, etc, etc...

We can already see how code might reflect these stories. Perhaps we instantiate FlavorFlav as an instance of a GrooveMaker class, certainly we will find sing and mute methods somewhere, and we might expect there will be some kind of status interface with 'performing' as one of the statii. We can wholly avoid generic language like 'status' (readiness) or 'manager' (DJ) - with the code becoming naturally rich in metaphor.

Current agile methodologies encourage the development of user stories and user journeys, quite rightly casting the end user as an actor in the ecosystem. But here we go further than that, characterising all active agents in order to generate a shared metaphorical language for the code, the documentation and the architecture. The richness of the metaphor is crucial. That moment when you stop and think 'but WHY FlavorFlav? is the experiential touch-point that engages us cognitively; whether we love, hate, or suddenly learn about the works of Public Enemy. The metaphor should be engaging, fun, and collaborative. The aim isn't descriptive modelling — it’s cognitive ignition. A good metaphor doesn't just clarify; it magnetizes attention, provokes conversation, sticks in memory. Why not spend a session working out, as a team, which classic beat combo we want to enjoy elaborating in our stories? That might not be immediately 'productive', but it can add strength to the shared mental models we use.

The metaphor ought to be rich, but not stretched. This means limiting the story's WORLD SETTING so that coherent stories can be told. Make use of INTERLUDES to tell sub-stories, potentially with their own, distinct, metaphorical voice. Accept/expect that exterior agents (from THE CONTINUUM or from the WORLD SETTING AXIOMATICS) will come with their own metaphors. In my (developing) example of GrooveMakers and DJs the PerfomanceSpace as WORLD SETTING provides the AXIOMATIC {Scribe}. Axiomatics live in their own worlds, yet provide 'black box' functionality to this world. The Scribe has nothing to do with music making, it just records and announces stuff (it's my logging solution). Its presence creates no tension in the central story (although it has its own story with its own tensions), and so can happily live in its own world, with its own distinct voice.

Telling the tale

Grammar is not a part of language, something we use to structure and frame words before we speak. It's a descriptor, an afterthought, not a prescription of how we will speak; but rather a description of how we may (be expected to) speak. This relationship is key to how languages live, are allowed to evolve. Speak first, structure second. The same is true of the Narratival-Exposition Paradigm. If we commence by layering metaphor over grammatic structure we give too much attention to 'the rational' causing the whole paradigm to devolve into just another exercise in structuring; and leading to hollow, over-stretched, metaphor.

We are, all of us, native speakers of the narrative language - that's kind of the point. Narrative as a foundational component of cognition.

So, it is always best to lead with a natural language exposition of some part-of-story. Only thereafter inspecting the precision of the grammatical adherence. The latter is important if the metaphor has any chance of intersecting with our analytical framework, but must be secondary to creating the cognitive experience of story.

As an example, here's a story fragment:

This is only a fragment because clearly there's no underlying intent here - I have no target implementation in mind for which this metaphor can stand. But it demonstrates how we move from a natural language exposition to a formalised grammatic structure that supports intersection with analytical structure, providing a rich shared mental model.

Although I present a clear separation between the story prose and the formal grammar, the reality is that one leads into the other - particularly in the WORLD SETTING where the declaratives (of scope, limits and preconditions) are stated in the story voice. As the story develops it might also be useful, at times, to deploy the grammatic structure - e.g. referring to seed-bed.weeding if the story starts to grow.

Also, I feel that 'classification as !DISPOSITION' isn't quite right here as these are characteristics that differentiate rather than dispositions that change. I think this kind of issue will clear up in a more realistic story telling frame, or as and when the grammar is refined. The point right now is to see if this thinking sparks discussion, so I have deliberately not weeded it as yet!

In Closing

I ought to be clear. The software I'm currently crafting while crystallizing these ideas is concerned with synthesising musical structures and sounds from moving image frame data - so metaphors rich with musical references work for me in this case. I guess (recommend) metaphor should reflect purpose, so that it doesn't feel too whimsical (which I think would work against the need for cognitive ignition).

Exposition of narrative is intended to help discovery of latent concerns, so we don't have to think of everything up-front, all at once through rational inspection — nor fear that we couldn't think of everything. It helps to avoid paralysis by analysis, by giving us an 'in' when we know nothing, or very little. This is because we don't need to worry about relevance - we just need to describe the given parts-of-story to see what emerges. Once we are familiar with our characterisations and situations, their tensions arise seemingly naturally. The existance of tensions helps to bring unique abilities and critical flaws of our characters to the fore. In fact, it can seem that the best stories almost write themselves - because we are all native speakers of the narrative tongue.

And its not just a matter of aiding discovery, a strong narrative metaphor also aids comprehension by others. Perhaps not of precise implementation detail, which aligns more naturally with a (de)compositional analysis - but comprehension of intent and meaning. Narrative is partner to, not replacement of, our classic tools and approaches.

So it seems like it comes at a cost, what with there being a whole other dimension to craft in the building of software. Perhaps that cost will be offset by the improved cognition within teams? Or perhaps it will prove to be a more fluent interface to emerging code-generation tools, i.e when working in partnership with LLM (AI) code generators such as Vibe?