I'm now in Belgrade, Serbia for three months, and, in the spirit of the Warsaw Winter Theatre Company, I've decided to do something slightly different this time: to document the city as if it were software.
Not metaphorically software. Actually software. Complete with technical documentation, system requirements, error messages, and troubleshooting guides. Except the documentation is poetry, and the software is culture, and the whole thing exists in that peculiar space where postmodern theory meets actual lived experience meets code.
I should probably explain. But before I do here's what one of my faithful AI companions makes of the idea:
© Reticulate
The Problem With Travel Documentation
Most travel writing inevitably follows predictable patterns: arrive somewhere exotic, have meaningful encounters with locals, gain profound insights about yourself and the human condition, return home transformed. It's a genre so rehearsed that the performance has become indistinguishable from genuine experience.
The Warsaw Winter Theatre Company - the analytical framework I developed during my time in Poland - investigates exactly this kind of cultural performance. Cities don't just exist; they perform themselves for temporary residents who arrive seeking "authentic" experience. The mechanisms are sophisticated: seasonal costume requirements, historical set designs, social scripts that transform genuine encounters into predetermined cultural exchanges.
Belgrade, though, presents an interesting case. It's a city that appears to operate on fundamentally different cultural software than anywhere else I've personally encountered. The trams run on mysterious schedules known only to themselves. The informal economy functions according to invisible protocols. Social interactions follow rules that make perfect sense to locals but remain opaque to outsiders.
Rather than trying to decode Belgrade through traditional writing, I decided to document it the way you'd document any complex system: write the manual.
Enter OS:B
OS:B - Belgrade Operating System - is a WWTC poetry project that treats Belgrade as software requiring technical documentation. Each poem functions as a piece of system documentation: installation guides, protocol specifications, troubleshooting sections, error logs, version histories.
The format isn't just an aesthetic choice. I'm actually using Mintlify, real documentation software used by tech companies, to create the project. The same platform that hosts API references and developer guides will now host poetry about Belgrade's culture, tram navigation protocols and more besides.
Here's where it gets interesting: the poems themselves are written as pseudo-valid Python code. Not code that happens to look poetic, but actual executable programs where the poetry exists within proper code structure. Class definitions, methods, list arrays, doc strings - all functioning Python that renders beautifully on screen with syntax highlighting while simultaneously operating as free verse cultural observation.
Hence:
#!/usr/bin/env python3
"""
Tram Protocol 7A - Navigation Documentation
"""
class BelgradeTram:
def __init__(self):
self.schedule = "theoretical"
self.observations = []
self._document()
def _document(self):
"""Field notes from the 7A line"""
waiting = [
"The digital sign flickers",
"seven minutes, it says",
"but the old woman beside me laughs",
"without looking up from her phone",
"",
"She knows something about time here",
"that the LED display doesn't."
]
You see what's happening here?
The code structure provides intellectual distance and organisational framework, while the verse content stays immediate and sensory. The technical format isn't decoration - it's intrinsic to how the work functions.
The Unread Manual Paradox
There's a beautiful postmodern twist here: most people don't read documentation. They arrive in new environments and immediately start clicking around, trying to make things work through trial and error, ignoring the carefully written manuals that would actually help them.
OS:B embraces this irony. I'm creating gorgeous, thoughtful documentation for Belgrade's cultural operating system that users will inevitably ignore while stumbling through their own trial-and-error integration. The poetry becomes this artefact of systematic cultural analysis that nobody reads - exactly like actual software documentation.
The project itself acknowledges that the manual is both essential and useless, both comprehensive guide and futile gesture. It's documentation for a system that can only be learned through direct experience, written for users who won't consult it until after they've already figured things out themselves.
Structure Without Constraint
Unlike my previous project "The Undoing" - which documented my journey to Belgrade through daily entries - OS:B uses thematic rather than chronological structure. No obligation to produce daily output, no pressure to force experiences into predetermined time slots.
Instead, the project organises around technical documentation categories:
Core Functions: Poems examining essential Belgrade processes - memory management (how the city handles historical trauma), social networking protocols (kafana culture, street hierarchies), resource allocation (informal economy mechanics).
User Interface Studies: Poems about learning Belgrade's interface - navigation protocols, input methods (gestural language, market negotiations), display settings (visual symbols of belonging/exclusion).
Background Processes: Poems investigating invisible operations - generational data transfers, corruption protocols, cultural inheritance systems, legacy code influencing contemporary behaviour.
System Errors and Patches: Poems capturing moments when Belgrade's OS glitches - performance breakdowns revealing underlying mechanisms, error states exposing cultural programming.
Version History: Poems examining how OS:B has evolved - comparing current protocols with historical versions, legacy systems still running in background.
Any Belgrade encounter thus becomes potential documentation material. Confusing tram experiences become "Navigation Protocol Documentation." Kafana afternoons become "Social Networking API Reference." Bureaucratic puzzles become "Legacy System Troubleshooting Guides." And so on.
Free Verse as Code
The poetry itself uses free verse - no rhyme schemes, no regular meter, no predetermined structures. Just natural speech rhythms, line breaks for emphasis and breath, concrete sensory observations captured in the moment.
But here's the constraint: all lines must stay within roughly 60-70 characters to avoid horizontal scrollbars in rendered code blocks. This limitation actually improves the verse - it forces intentional line breaks, creates better rhythm and prevents rambling. In this case, the technical requirement becomes an aesthetic advantage. Especially for me, someone who has never knowingly written any poetry.
Each poem will follow a standard template: Python class structure, fragments organised as list arrays, execute/output methods for display, technical comments that enhance the documentation feel. The format does the heavy lifting while I can focus on actual cultural observation.
Why This Matters
We live in an era where cultural differences have been flattened into lifestyle choices and authentic travel experience has become another consumer product. OS:B addresses this by abandoning the search for authenticity beneath simulation and instead examines how simulation itself operates.
But it's doing this through poetry. Through code. Through technical documentation that's simultaneously functional system analysis and creative artefact. The project exists at the intersection of multiple disciplines - poetry, cultural theory, software development, visual design - refusing to be contained by any single category.
The visual design potential alone is exciting: imagine a technical manual beautiful enough to sit alongside actual software documentation, complete with system requirements, error messages as titles, flowcharts mapping cultural processes, QR codes linking to audio versions. Open it expecting API reference; discover poetry about displacement and belonging.
The Performance Continues
OS:B becomes the Belgrade Chapter of the Warsaw Winter Theatre Company's traveling investigation methodology. Just as Warsaw required its own analytical framework (theatre company, performance, cultural simulation), Belgrade demands different conceptual tools - software, operating systems, technical protocols.
This mobility prevents any single framework from becoming too settled. Just as we begin understanding how cultural performance works in one context, we shift to another requiring completely different analysis. Each city reveals the limitations of previous approaches while suggesting new ones.
The project is live as of today at osbelgrade.mintlify.app - still being built, still learning the system, still documenting the cultural software as I discover it. In the tech community they call it "Build In Public". Go figure.
OS:B documents Belgrade as software requiring technical specifications. Poetry written as Python code functions as protocol documentation, troubleshooting guides, and system analysis. A cultural investigation hosted on developer infrastructure, treating displacement as debugging and integration as installation.
I hope this is what happens when you bring postmodern theory, poetry practice, and developer tools to a city that refuses to be easily categorised. This is intellectual disruption disguised as technical documentation, cultural analysis that insists on being created rather than passively consumed.
The installation process has begun. User adaptation: ongoing. Integration timeline: unknown.
Welcome to OS:B.
For more on the Warsaw Winter Theatre Company methodology, see Introducing the Warsaw Winter Theatre Company and Travels in Hyperreality: An Experimental Chronicle.
