DUBAI — Images. Video. Tables. Code. Callouts. Quotes. Lists. Redactions. Every format this newspaper can render, in one dispatch from the test bench.

DUBAI — The meeting was at 10am. The client arrived at 10:40. This is normal. In Dubai, the invitation time and the meeting time are related but not equivalent concepts, and anyone who has not learned this after six months of working here is going to have a bad time of it. The presentation was a facade redesign. Four options. We had spent three weeks on them. The options ranged from conservative to adventurous — a considered portfolio designed to allow the client to select from a spectrum while feeling like they had influenced the outcome. This is standard practice. Clients rarely choose the conservative option, rarely choose the adventurous one, and almost always choose something in the middle after suggesting modifications to both ends. The middle option is where the design team actually wants to land. This is also standard practice. The client looked at the four options for approximately forty-five seconds. He pointed at option two. “This one,” he said. “But make it pop.” On the Phrase “Make It Pop” I have been working in architecture for eight years. I have heard this phrase, or its close relatives — “give it more life,” “make it feel premium,” “add something special” — approximately one hundred and eighty times . I have learned to translate it, which is to say I have learned to ask the specific follow-up questions that turn a subjective aesthetic preference into actionable design criteria. The translation process goes like this: “Make it pop” — What is currently missing that would, if added, make this design feel more resolved? Is it a material change, a proportional adjustment, a feature element, a lighting consideration, a colour decision? The client’s answer (usually) — “I saw something in [location] that I liked. Similar to this but more… premium.” The follow-up question — Can you describe the thing you saw in [location]? Material? Scale? What specifically felt premium about it? This conversation, if done correctly, takes fifteen minutes and produces enough information to proceed. If done incorrectly — if you accept “make it pop” as a design brief and return three weeks later with your interpretation — you will have three more meetings before you understand what you should have asked in the first one. What “Pop” Actually Meant In this case, after the fifteen minutes: the client had recently visited a hotel in Riyadh. The hotel had a facade treatment involving backlit stone panels — thin-cut marble with LED backlighting creating a warm glow through the veining. He wanted something that did the same thing for the mixed-use development we were designing, but appropriately scaled for a mid-range commercial building rather than a luxury hotel . This is useful. This is designable. “Backlit stone facade feature, warm tone, mid-range budget constraint, reference: recent Riyadh hotel project” is a brief. “Make it pop” was a feeling. The fifteen minutes turned the feeling into a brief. We went away with clear direction. The revised facade has a feature bay with backlit glass-fibre reinforced concrete — GFRC, not marble, because the budget is a commercial building and not a Riyadh hotel — with a warm-toned LED system behind it. It reads as premium. It is within budget. It is probably what the client saw in Riyadh, transformed into something achievable. The client approved it in a meeting that lasted twenty minutes, which is a record. He said it looked great. He did not say it popped. I consider this a success.

DUBAI — The brief was simple: make the model health legible. The implementation was not. One hundred and twenty-nine Revit models across nineteen series, each with its own coordinate system, its own particular way of being wrong. A pyRevit script pings every loaded link, flags unloaded ones, fuzzy-matches filenames, reloads from the P: drive. Runs in forty seconds. Two weeks to write. The honest report: most coordination problems are not technical. They are human.

The idea behind markedwith.love is simple enough to fit on a napkin: a letter should cost something. The cost used to be stamps and ships. The letter from London to Calcutta in 1840 cost money, took months, and was written with the knowledge that it would take months. The letter was therefore written accordingly. You did not write a letter that you expected back in twenty minutes. You wrote a letter that was worth the journey. Email removed the cost. This was presented as progress, and by most measures it is. But the cost was doing something that nobody noticed until it was gone: it was creating intentionality. The sender had decided that this message was worth the cost of sending it. The recipient knew this. The knowledge changed how both parties related to the message. markedwith.love tries to put the cost back in, not as money but as time and distance. You write a letter. You address it to someone. The delivery time scales with the real geographic distance between you and them. A letter to someone in the same city arrives in hours. A letter to someone on the other side of the world takes days. The letter itself is unchanged. The waiting is the cost. What I have learned in building this: the waiting does something. People who have tested the early version report that they write differently when they know the letter will not arrive instantly. They take more care. They say things they would not have said in an email because an email is an arrow and a letter is a parcel — it carries more, and you are more aware of what you are putting in it. Whether this effect is real or whether testers are being polite is impossible to determine at this scale. It feels real. The technical problem I did not anticipate is timezone display. When you are in Dubai and you send a letter to someone in São Paulo, the delivery countdown is trivial to compute. What is not trivial is displaying it in a way that feels like distance and not like a countdown timer. A countdown timer is anxious. Distance should feel like distance — like a thing that is happening in the world, not a thing that is being waited for. The UI work is the hardest part of the project. The algorithm took a weekend. The feeling has taken three weeks and is not finished.

DUBAI — It is not the number. The number means nothing. You see 42°C on your phone and process it abstractly. The sensation arrives when you open the car door and the air inside is a different substance than air. When you walk from the car park to the building entrance and arrive already damp. When the shade stops being refreshing because the air in the shade is the same temperature as the air in the sun, just without the radiation. By May it will be worse. By June the city conducts most of its life at night or indoors. You get used to it in the way you get used to anything that has no alternative. The city has adapted structurally — every significant destination is connected by covered walkways or indoor routes, the commute is car-based by necessity, outdoor meetings are replaced with outdoor evenings between 7pm and midnight when something like comfort is available. The adaptation is complete and has a cost. The cost is the street. A city where outdoor movement is climatically impossible for six months is a city that cannot build street life. The ground floor is dead because the ground is hostile. The lobbies are sealed because the seal is the amenity. Everything interesting happens indoors. I have lived here long enough to stop finding this remarkable. It is remarkable. A city of three million people that effectively moves inside for half the year and builds its culture around interior spaces. The malls are not what they look like from outside. From inside, at 9pm in August, they are the street. The food court is the piazza. The atrium is the public square. It is not the street I would choose. It is the street that the climate chose. That is worth thinking about seriously, which I intend to do in a longer piece when it is not April and I am not distracted by the fact that it is 42°C and I have to walk to my car.

AMMAN — The first thing you notice is the hills. Amman is not a flat city — it is built across seven hills and the drama of the topography is inescapable. Every street ends in a view or a drop. The city unfolds in layers: the older parts in the valleys and lower slopes, the newer parts climbing the ridges, the whole thing made coherent by the pervasive limestone. Every building is the same pale cream-gold. In evening light the effect is extraordinary. I had forty-eight hours. I used most of them badly, which is to say I used them exactly right for a city I’d never visited: walking without a plan, eating at the wrong times, getting lost between Jabal Amman and Jabal Al-Weibdeh and discovering in that lostness that the city rewards exactly this kind of movement. The Food Question People will tell you that Amman has the best mansaf outside a Jordanian home. This is probably true, though the mansaf I had at a restaurant whose name I did not write down and cannot now locate was the kind of meal that creates a reference point: everything subsequent is measured against it. Lamb slow-cooked in jameed — fermented dried yoghurt — with rice and pine nuts and a sauce poured over at the table. It is the kind of food that tastes like somewhere. You couldn’t eat this in Dubai and have it mean the same thing. The context is part of the flavour . The coffee culture is worth its own paragraph. The traditional Jordanian coffee — qahwa — is cardamom-forward and served in small cups without handles, refilled until you tilt the cup to signal you’ve had enough. The specialty coffee scene in Jabal Al-Weibdeh is also very good, which creates a pleasant city where you can drink excellent espresso in the morning and qahwa in the afternoon and feel neither like a tourist chasing authenticity nor like a tourist hiding from it. What the Architecture Does Amman’s architecture is not a carefully preserved historic centre — the city is largely twentieth century, built fast across the hills as the population grew — but it has an accidental coherence that many cities with actual historic centres lack. The limestone building regulations mean that even the most ordinary apartment block has a material dignity. The material is expensive and heavy and requires real craftspeople to work properly. This regulates the city in ways that planning documents often fail to. The Roman Theatre is the obvious landmark — 6,000 capacity, second century, in near-perfect condition in the centre of downtown. What is less discussed is the way the theatre sits in the city: not isolated as a monument but embedded in the urban fabric, surrounded by markets and restaurants, used and alive. The shops underneath the theatre’s supporting arches sell coffee and falafel. This seems right. Buildings that are used last longer than buildings that are preserved. The Citadel, up on the highest of the seven hills, has the Umayyad Palace and enough archaeological layering — Bronze Age, Iron Age, Roman, Byzantine, Islamic — to make most other cities feel thin. I spent two hours up there and left with the particular feeling of being very small against a very long timeline. The Driving I have driven in Dubai, Riyadh, Cairo, and Istanbul. Amman’s driving is not comparable to any of these. It is a fifth category. The lane markings appear to be advisory. The horn is used constantly but without malice — it is a communication device, not an expression of anger. The roundabouts operate by a social contract I was unable to fully decode in forty-eight hours. My driver navigated all of this with a serenity that suggested either deep faith or a complete suspension of concern for outcomes. Possibly both. What Forty-Eight Hours Actually Teaches You It teaches you that a city is worth returning to. That is the most useful thing a short visit can do — not give you the city, which is not possible in forty-eight hours, but give you enough to know whether the full version is worth the longer trip. Amman is worth the longer trip. The hills, the food, the limestone, the people, the coffee, the Citadel at dusk — these are the notes of a city with more depth than a weekend can reach. I left with a list of things I didn’t do, which is the correct souvenir from any city worth visiting.

I learned to program twice. The first time was in architecture school, using Grasshopper for Rhino. The second time was recently, learning JavaScript properly. Between the two I wrote five years of pyRevit scripts and a lot of Python that worked without me fully understanding why. What I understand now, looking back: Grasshopper was teaching me graph-based functional programming from the very first component I dragged onto the canvas. I didn’t have the vocabulary for it. No one in the studio did. We called it “parametric design” and talked about it as a modelling technique. It was actually a programming environment with a visual syntax. The Graph Is the Program In Grasshopper, a definition is a directed graph. Nodes are functions. Edges are data flows. The left side of each component takes inputs; the right side produces outputs. There are no side effects in a correctly-written definition — each component takes data in, transforms it, returns data out. The order of execution is determined by the graph topology, not by the order you placed components. This is functional programming. Not because it looks like Haskell or because someone made an architectural decision to make it functional — it is functional because the visual metaphor of wires carrying data between components maps directly onto function composition. You cannot modify state in a Grasshopper component. You can only transform data. This means everything you build is referentially transparent: given the same inputs, you always get the same outputs. # This is what a Grasshopper tree operation looks like in Python import Rhino.Geometry as rg def offset_curves(curves, distances): """What Grasshopper's Offset Curve component does implicitly.""" results = [] for crv, dist in zip(curves, distances): offset = crv.Offset( rg.Plane.WorldXY, dist, 0.001, rg.CurveOffsetCornerStyle.Sharp ) results.extend(offset) return results I wrote hundreds of Grasshopper definitions before I knew what a list was. I knew what Grasshopper called a “list” and what it called a “tree” — which is a nested list, a list of lists — but I understood these as modelling concepts, not programming concepts. The moment I started learning Python properly and encountered lists and nested lists, I had this strange experience of recognising something I already knew from a different angle. The knowledge was already there. The vocabulary was new. What Grasshopper Gets Right That Textual Code Gets Wrong The visual representation of data flow is, for spatial reasoning people, vastly better than textual code. You can see where data comes from and where it goes. You can see which components are connected. You can see, at a glance, whether your definition has parallel branches or sequential dependencies. What you can’t easily see: what happens inside a component. The components in Grasshopper are black boxes. You know the interface — inputs, outputs, data types — but not the implementation. For a long time I thought this was fine, because the implementations were written by McNeel engineers and were presumably correct. The problem is that you cannot debug a black box. When a definition produces wrong results, you can trace the data flow, but you cannot step into a component and see what it’s doing. This is where textual code is better. You can read the implementation. You can step through it line by line. You can insert print statements. The debugging affordance of textual code is, for any non-trivial problem, superior to the visual debugging of a graph. The ideal tool probably sits between these two: visual for the graph structure, readable for the component implementations. This is roughly what pyRevit’s panel system does, and roughly what Speckle is attempting at a larger scale. Nobody has solved it cleanly yet . The Transfer When I started writing Python properly — not pyRevit scripts, but Python with tests and a proper understanding of what I was doing — I found that the hard concepts came easily. Functions as first-class objects: I already understood this from Grasshopper’s component model. Recursion: harder, and Grasshopper didn’t help with this. List comprehensions: immediately legible once I understood that they were a terse version of the loop-and-accumulate pattern I had been doing in Grasshopper trees for years. What didn’t transfer: the mental model of imperative code. Grasshopper has no loops, no conditions evaluated sequentially, no mutation. Python has all of these, and learning to think imperatively after years of purely functional visual programming was genuinely uncomfortable. I kept wanting to express things as data transformations when the correct expression was a loop with an accumulator. The discomfort resolved after about two months. I now think in both modes depending on the problem. Some things are naturally functional — transformation pipelines, data cleaning, mapping. Some things are naturally imperative — state machines, UI event handling, anything with side effects. Knowing which mode to apply when is a skill that Grasshopper partly taught me, without either of us knowing that’s what was happening. Architecture school is better at teaching programming than it knows it is . It just doesn’t call it that.

The survey data was comprehensive. Point cloud. Drone photogrammetry. Topographic survey to five decimal places. Every existing utility marked and cross-referenced. The site model was accurate to within 20mm across its entire extent. This is genuinely impressive. None of it told us about the smell from the service road at 8am, the way the sun sits on the north facade at 3pm in October, or the fact that the adjacent site’s loading bay generates a queue of trucks that blocks the proposed main entrance for forty minutes twice a day. The site visit takes two hours. The survey data took three weeks to collect and process. Both are necessary. The survey gives you numbers. The site visit gives you the things numbers cannot carry. The difference is not mystical — it is information-theoretic. A point cloud captures geometry. It does not capture acoustic environment, thermal sensation, visual character, movement patterns of the people who are already there, or the micro-scale human behaviours that determine whether a space will be used or avoided. These are knowable. They are not knowable from a model. What I look for on a site visit: where people actually walk versus where the paths are. How the light changes at different times of day. What the view is at eye level rather than at drone altitude. How close the neighbouring buildings actually feel when you are standing on the ground versus when you are looking at a site plan. These are consistently surprising. Site plans flatten everything — not just topography but experience. The building on the adjacent plot that appears manageable in plan feels overwhelming when you stand at the boundary and look up at it. The most productive site visits happen twice: once before design begins, with open eyes and a blank notebook, and once after the concept is established, with a specific set of questions the design has generated. The first visit is about learning what the site is. The second is about testing whether the design has understood what you learned on the first. Most projects do one or the other. The ones that do both make better buildings. The truck queue was a real problem. It required moving the entrance 12 metres south. This decision was made on site, standing at the proposed entrance location at 8:15am, watching the queue form. It would not have been visible in the data. The data had the loading bay. It did not have the time.

There is a particular kind of work that requires you to not think too hard about whether it will be received. You build the thing, and the building is the point, and whether anyone arrives at the other end is a question for later, or possibly never. markedwith.love is that kind of project. A letter app. You write, and the letter travels at a speed proportional to the real distance between you and the person you are writing to. A letter across the city: minutes. A letter across the world: weeks. A letter should cost something. The cost used to be stamps and ships. Now it is nothing, and so letters are nothing, which is the saddest sentence I have written about the internet . This project is trying to restore the weight.

HIRIKETIYA, March 2026 — We arrived on different flights. Intentional. The small pride of navigating Colombo traffic alone before finding each other at the guesthouse, which is different from a hotel and better. Kitulgala first. The river in the water by 7am, before the heat, before the tour groups. Hiriketiya last. A bay shaped like a bowl. The surf was slow. We stayed four days when we’d planned two. Nobody complained. I have been on trips that were better organised. I have not been on one that felt more like what a trip is supposed to feel like.

DUBAI — The column was in the wrong place. Not dramatically wrong — not the kind of wrong that causes structural failure or triggers emergency site meetings. It was 47 millimetres off its modelled position, in a direction that placed it partly inside the corridor clearance zone. In isolation, 47 millimetres is nothing. In a coordination model where every MEP service, every partition, every door swing is modelled to millimetre precision, 47 millimetres is a category error. The question the site foreman asked me, and which I have been thinking about since: which one is wrong? The model or the building? The Assumption Embedded in the Question The framing of “which is wrong” assumes that one of the two — the digital model or the physical structure — represents ground truth and the other is a deviation. In the pre-BIM era, the building was always the authority. The drawings were intentions; the building was fact. You measured the building. You annotated the as-built drawings. The building was the record. BIM has quietly inverted this. The model is now treated in many workflows as the primary record, and deviations in the building from the model are recorded as defects rather than as corrections to an imperfect intent. This is not entirely wrong. The model often represents design intent more accurately than the constructed reality. But it is also not entirely right. The 47mm column is a real building that real people will occupy . The corridor clearance matters. If the model says the clearance is acceptable and the building says it isn’t, the model is wrong in the only sense that matters: the sense that affects people. What Point Clouds Actually Show You I ran a point cloud scan of the relevant section of the floor. The scanner produced 340 million points in eighteen minutes. The registration took another forty. The resulting cloud showed the column in its actual position, the walls in their actual positions, the MEP services in their actual routed positions — a complete, objective record of what was built. Overlaid against the coordination model, the divergences mapped to a pattern: everything in the shell and core was slightly out — between 30 and 60mm across the floor — and everything installed by trades working off the as-built shell was correctly positioned relative to the shell. The coordination model, which everyone had been using as the reference for seven months, had never been updated after the shell structure deviated during pour . This is a documentation failure, not a construction failure. The building was built correctly from the information available to the people building it. The model was not updated with the information that would have made it correct. The gap between model and building accumulated silently for seven months. What This Costs The resolution of a 47mm column position deviation is not technically complex. The column stays where it is. The affected corridor partition shifts. The MEP services reroute around the shifted partition. The door swing gets re-checked. The cost: half a day of coordination meetings, three days of revised shop drawings, and a week’s delay in that section of fit-out. On a project of this scale, the cost is absorbed. On a project with tighter margins, it isn’t. Multiply this by the number of similar deviations that accumulate on any project where the model isn’t updated against as-built reality, and the pattern becomes a line in the budget marked “coordination contingency.” It is a cost that is accepted as normal. It should be treated as a documentation failure with a known remedy. The remedy is weekly point cloud scans during construction, model updates against scan data, and a coordination model that reflects what is built rather than what was designed. This exists as a workflow. It is not used as consistently as it should be, because it adds time and cost in the short term and saves larger amounts of both in the medium term. The short term is visible. The medium term is theoretical. Projects optimise for the visible. The column is 47mm off. The model will be updated today. The building will be recorded as it is. Next time, perhaps, the model will be updated in the week after the pour, not seven months later. Perhaps. The incentives don’t particularly reward it.

VIENNA — Airlines have made the world smaller. Trains have kept it honest. A long read on why the journey still matters — and what we surrender when we choose the fastest route.

I have been writing CSS for three years. I have been learning CSS for six weeks. These are different activities. Writing CSS is navigating by feel — you know roughly where things are, you know which properties tend to produce which effects, you know when to Google and you know what to search for. Learning CSS is understanding why the box model works the way it works, why floats cleared the way they cleared, why flexbox solved the problems it solved and what problems it left to grid. The first is a skill. The second is a foundation. The Odin Project teaches the second. It does this by making you build everything from scratch — no framework, no library, no shortcut. You implement the card layout yourself. You implement the navigation yourself. You discover personally, not through documentation, that inline-block elements create whitespace from the line breaks in your HTML. You discover that width: 100% on a flex child does not behave the same as flex: 1 . You discover that stacking contexts are real and z-index only works within them, which explains a family of bugs I have been working around for two years without understanding. The gap between knowing CSS and understanding it is exactly the size of all the things I was confidently wrong about. I knew that position: relative was the parent you needed to position a child absolutely. I did not know that it also creates a stacking context, or that transform creates one, or that will-change: transform creates one speculatively. This newspaper’s archive popup was broken because of a stacking context created by a CSS transform, and I fixed it by moving the popup outside the transformed element, which is the correct fix — but I reached it by intuition and trial, not by understanding. Now I understand it. What I would tell a designer considering the same path: the investment is real and the payoff is real. The investment is approximately sixty hours to complete the relevant sections of the curriculum, assuming you work at it seriously. The payoff is that the code you write after does what you intend it to do, and when it doesn’t, you understand why, which means the debugging process is thirty minutes instead of a day. The compounding value of understanding over knowing is high in any technical domain. In CSS it is particularly high because CSS is one of those disciplines where you can produce acceptable results with minimal understanding for a long time, which means the gap between the floor and the ceiling is vast and the gap remains invisible until the day it isn’t. The newspaper is partly the result of this. I built it while learning. The parts I understood I built correctly. The parts I didn’t I built by feel, and some of them are quietly wrong in ways I will fix when I understand them well enough to see the wrongness. This is the accurate description of most software written by most people, and being honest about it is more useful than pretending otherwise.

Adolf Loos declared ornament a crime in 1910. He was wrong, and architecture spent most of the twentieth century demonstrating his wrongness in the most conclusive possible way: by building a hundred million square metres of unornamented surfaces and proving that the absence of ornament is not the presence of purity. It is just the absence of ornament. This should have settled the question. It didn’t. The post-modern turn in the 1980s added ornament back — ironically, historically, in quotes — and managed to be worse than the thing it was reacting against. Stripped classicism applied without understanding. Pediments on shopping centres. Cornices as corporate identity. The problem was not the ornament. The problem was that the ornament meant nothing. What Ornament Actually Does Ornament at its best is a record of craft, time, and care. The carved capitals in a Gothic cathedral were not decorative in the sense of being optional surface treatment. They were structural demonstrations: evidence that the building was built by people who cared enough to spend weeks on a stone that would be forty feet above the floor and readable only from a distance. The signal was not aesthetic. It was ethical. The building was made with this much care. This is what it cost. This is what you get. The modernist critique of ornament was partly a critique of this signal when the signal became false — when factories producing pressed tin ornament allowed buildings to imply a level of craft they hadn’t received. Loos was arguing against dishonesty as much as against decoration. This is a reasonable argument that got turned, by his successors, into a categorical prohibition against surface treatment. Which is a different and much weaker argument. What Dubai’s Ornamented Buildings Get Wrong Dubai builds a great deal of ornamented architecture. Most of it is bad ornamentation. The specific failure is not exuberance — I am not opposed to exuberance — but incoherence. The ornament is applied without reference to structure, program, or culture. The arabesque patterning on the car park podium. The mashrabiya screens that don’t shade anything. The gold-tinted glass applied to every building regardless of orientation, so that the facade facing north gets the same solar treatment as the facade facing south. This is ornament as branding, not ornament as meaning. It signals luxury without containing it. The distinction matters because buildings that signal luxury without containing it are lying , and buildings that lie to their occupants are, in Loos’s actual terms, criminal — not for having ornament, but for using it dishonestly. The better recent buildings in Dubai — and there are some — use ornament to solve actual problems. The mashrabiya on buildings that genuinely shade occupied space. The perforated metal screens that modulate light on west-facing facades. The textured concrete that signals weight and permanence because the building is meant to last and the texture is a commitment to that lasting. These details work because they are doing something beyond signalling. They are carrying meaning because they are earning it. The Correct Lesson Ornament is a design problem, not a design crime. The question to ask of any ornamental gesture: what does it mean, and is the meaning earned? A carved stone that records weeks of skilled work: earned. A pressed aluminium cladding panel stamped to look like carved stone: not earned, not because it’s cheaper, but because it is pretending to be something it isn’t. A screen that actually shades: earned. A screen that looks like it shades but doesn’t, applied for visual interest: not earned. The buildings I find most satisfying — Zumthor’s Vals Thermal Baths, the Chapel of St. Ignatius in Seattle, any of a dozen projects by Kengo Kuma — are not ornamented in the conventional sense. But they are deeply specific in their material treatment, in the way surfaces are handled, in the textures and joints and edges. This specificity is the modern equivalent of ornament: evidence that someone cared, and that the caring was justified. Loos was right about the lie. He was wrong about the remedy. The remedy for dishonest ornament is not no ornament. It is honest ornament. Which is to say: ornament that means something, and means it for reasons the building can actually support.

At some point you accumulate enough code that you stop knowing what you have. The scripts folder was 2.3GB. The count was thirty-one files. The last time I had looked at some of them was eighteen months ago, which means I had been relying on them without understanding them , which is a specific category of technical debt. I spent a week auditing them. Not refactoring — just reading and classifying. The results were educational. The Categories Still running and still correct (11 scripts): These are the workhorses. The room numbering propagator. The shared parameter exporter. The door mark validator. The clash detection pre-filter. The view template applicator. These work because they were written to solve stable problems — problems whose requirements did not change when the project changed. # The door mark validator — written March 2024, still running # Checks that every door has a unique mark within its level def validate_door_marks(doc): doors = FilteredElementCollector(doc)\ .OfCategory(BuiltInCategory.OST_Doors)\ .WhereElementIsNotElementType()\ .ToElements() by_level = defaultdict(list) for door in doors: level_id = door.LevelId mark = door.get_Parameter(BuiltInParameter.ALL_MODEL_MARK).AsString() by_level[level_id].append((door.Id, mark)) errors = [] for level_id, entries in by_level.items(): marks = [e[1] for e in entries] duplicates = [m for m in marks if marks.count(m) > 1] if duplicates: errors.append(f"Level {level_id}: duplicate marks {set(duplicates)}") return errors This script has run on four projects. It has found 847 mark errors across those projects, every one of which would have caused coordination issues downstream. It was worth writing. Replaced by better scripts (7 scripts): The early ones. These worked but were written with a poor understanding of the Revit API. The element filtering used ToList() where ToElements() is appropriate — a small performance issue that compounds on large models. The error handling was catch-all try/except blocks that swallowed API errors silently. The data structures were lists of tuples instead of dataclasses, which made the logic hard to follow. I rewrote these properly. The replacements are about 40% shorter and handle edge cases the originals didn’t. The investment was worth it for the five scripts that run frequently. The other two I probably should have deleted instead. Written for problems that no longer exist (6 scripts): These are the interesting ones. There was a script for migrating from one shared parameter file format to another — a migration that happened in 2024 and is now complete. There was a script for checking compliance with a client’s specific BIM execution plan — a client who moved to a different firm and took their BEP with them. There was a script for exporting to a specific software format that the project team stopped using. I deleted all six. Keeping code that solves problems you no longer have is a form of hoarding . It looks like resource accumulation but it’s actually just weight. The code might be reusable in some future project. It probably won’t be. The 40 hours it represents are not recoverable by keeping the files. Premature optimisation (7 scripts): These are the monument I mentioned. Seven scripts written for problems that were real but small, and written with an architecture designed for problems ten times larger. A script for batch-renaming views — correctly, a five-line script — written with a plugin architecture, a configuration file, a logging system, and a progress bar. The progress bar was for a script that runs in 0.4 seconds. I rewrote four of these as the five-line scripts they should have been. The other three I left, because the over-engineering happened to make them easy to adapt when requirements changed, and the adaptation has happened twice. Premature optimisation isn’t always wrong . It’s just wrong more often than it seems when you’re in the middle of it. What the Audit Taught Me The stable scripts — the ones still running and still correct — share a pattern: they solve problems at the domain level, not at the implementation level. The door mark validator doesn’t know anything about my specific project structure. It knows what a door is, what a mark is, and what a duplicate is. This domain-level thinking means the script transfers between projects without modification. The unstable scripts solved problems at the project level — specific to a client, a phase, a workflow decision that subsequently changed. These were correctly replaced or deleted. The lesson I draw from this: before writing any automation script, ask whether the problem being solved is structural or situational. Structural problems — anything arising from the nature of Revit models, coordination requirements, or BIM standard compliance — are worth building robust solutions for. Situational problems — anything specific to a current project, client, or workflow — are worth solving with the simplest possible script and no architecture at all. I wrote six scripts in the last year. Five were structural. One was situational. I spent the right amount of time on each. This is an improvement on the first two years.

The script does one thing: walks the model, checks every element against a parameter schedule, writes a report. Two seconds. A person doing it manually: forty minutes. Two weeks to write it. The break-even is in about five months. After that it is pure gain. This is the honest arithmetic of automation, and it is why the decision to automate is always a bet on the future. The two weeks were not two weeks of writing code. They were two weeks of understanding the problem well enough to write code. The first three days produced a script that walked the model and wrote a report. The report was wrong. It was wrong in the way that automated reports are wrong: confidently, consistently, in a way that took four more days to identify because the error was not in the logic but in the assumption the logic was built on. The assumption: that every element in a family category has the shared parameter in question. It does not. Some families were loaded from a library created before the parameter schema was defined. Some were loaded by a consultant who did not receive the memo about the parameter schema. Some were loaded correctly but from the wrong version of the family, which has the parameter but with a different GUID. None of this is in the documentation because the documentation was written by the person who set up the schema, who knew all of this and therefore did not think to write it down. The script now handles all three cases. It took another five days. The report is correct. It runs in two seconds. The forty-minute manual check has not been done since January. Five months until break-even. I believe this is worth it. The belief is a bet on the future — specifically, that the project will still be running in five months, that the team will still be using the parameter schema, and that the problem the script solves will still be the same problem. These are reasonable bets. They are still bets.

Brutalism was honest. The building told you what it was made of and where it was going. We stopped making buildings like that. The buildings that last — still interesting fifty years on — are the ones that didn’t try to flatter. They argued with their site, with the sun, with the programme they were given and the money they were given to realise it. They won some arguments. They lost others visibly. That visible loss is what makes them worth looking at. The alternative — buildings that try to flatter, that resolve every tension smoothly, that have no visible argument with anything — age poorly. They looked right when they were built and now they look like they were built when they were built. The flattery reveals its period. The argument does not, because arguments don’t have periods. There is a building on Sheikh Zayed Road that was finished in 2007 and looks exactly like 2007. The cladding was the most expensive available that year. The lobby was featured in three magazines. Nobody has photographed it since except accidentally. There is a building in Deira that went up in 1976, poured in place, unfinished concrete on the outside, that I find myself thinking about regularly. The argument it was having with the sun — the deep fins, the heavy overhangs, the deliberate shadow — is the same argument and the sun has not changed. I am not arguing for a return to Brutalism. I am arguing for honesty about what a building is made of and what it is trying to do. The materials do not matter. The argument does.

The conversation goes: you should be further along by now. Followed by: further along than what? Followed by: further along than where you thought you would be. Followed by: you were twenty-three when you thought that. The correct response is to compare current position to last year’s position, not to a projection made by someone who didn’t know enough to make reliable projections. This is the advice I would give to anyone. It is much harder to apply to yourself because the projection is still somewhere in memory, doing its quiet work. Last year at this time I was not building markedwith.love. I was not writing this newspaper. I was not running a BIM intelligence engine across a hundred and twenty-nine models or thinking seriously about what automation actually means in a practice context. By last year’s position, progress is clear. By the projection made at twenty-three, I am behind on three things that no longer matter and ahead on four things I hadn’t invented yet. The projection made at twenty-three was not wrong exactly. It was made without information. All projections are made without information. The question is whether you hold them as targets or as evidence about the person who made them. I am trying to hold them as the latter. The conversation still starts. It is just shorter now.

View templates should work like stylesheets. One source of truth, cascading logic, inheritance where sensible. A change to the master propagates down. Overrides are explicit and documented. This is not a radical idea — it is how CSS has worked since 1996. They do not work like this. They work like a bureaucracy that accumulated rules over fifteen years without anyone auditing whether the rules still made sense. Each template is a self-contained island. Changes do not cascade. Overrides are silent. The relationship between a template and a view is a one-way push with no memory. The project lost four hours last week to a view template override nobody remembered setting. The override was on crop region visibility, set to “Show crop region” on a view that had subsequently been templated with “Hide crop region,” but the override survived the template application because Revit treats certain properties as view-owned rather than template-owned — and the documentation on which properties fall into which category is incomplete. I am told this is normal. It is normal. That is the problem. The solution I want: a view template system that works the way a design system works. A token hierarchy. A component has a default. The default can be overridden. The override is visible in the UI. The lineage is traceable. You can ask any view: where is this setting coming from? And get a clear answer. The solution that exists: export to Excel, audit manually, import back, cross your fingers. We run this audit quarterly now. It takes a day. It should take a query.

Every city of a certain ambition wants its opera house. Not an opera house specifically — the category has expanded to include contemporary art museums, performing arts centres, cultural districts, and, in the Gulf, entire arts enclaves built at the edge of development zones with the expectation that the culture will arrive to fill them. The opera house is a symbol of arrival: the city is saying that it has graduated from purely economic ambition into something more durable. The opera house says: we intend to still be here in two hundred years. The Sydney Opera House is the ur-example, partly because it is genuinely extraordinary and partly because it nearly wasn’t built. The cost overruns were spectacular, the construction timeline was fiction, and the client eventually sacked the architect before completion. The building that resulted from this catastrophe is one of the most recognisable structures on earth and generates more tourism revenue annually than it has cost in its entire lifetime. The lesson that cities draw from this is: build the extraordinary thing, the numbers will work out. The lesson they should draw is: the numbers worked out in this specific case because of factors that cannot be replicated by intention. The Guggenheim Bilbao is the second reference. Frank Gehry, titanium, 1997, instant transformation of an industrial city into a destination. The “Bilbao effect” became a planning concept, deployed by city consultants with spreadsheets projecting the tourism multiplier for a landmark cultural building. The problem with the Bilbao effect is that it happened once, in Bilbao, because of a specific combination of building, location, timing, and cultural moment that happened to align. Most cities that tried to replicate it got expensive buildings with empty car parks. What the opera house actually does — when it works — is not what it promises to do. It does not attract the creative class. It does not transform adjacent real estate overnight. It does not by itself create the cultural life a city wants. What it does is give the city a place to have arguments about culture: what to programme, who can afford tickets, whether the architecture reflects local identity or imported prestige. These arguments are worth having. A city that has them is more alive than a city that doesn’t. The building is not the culture. The building is the occasion for the conversation. In Dubai the argument is different. The cultural institutions here are new enough that the conversation is still about what they’re for rather than who they serve. The Dubai Opera has been open since 2016. It is a good building. The programming has improved markedly year on year. Whether it is becoming a genuine cultural institution or remaining a premium event venue with cultural programming is a question the city is still in the process of answering. That it is asking the question at all is, I think, the right outcome. The opera house worked.

DUBAI — Dubai builds relentlessly upward. The problem is at ground level.

The flight was missed by eleven minutes. The next one was six hours later. The Hamad International Airport has a large bear sculpture and very good coffee at 3am, which is either a service amenity or evidence that the airport was designed by someone who understood the traveller’s actual psychological state better than most airports do. Six hours is long enough to read one hundred and twenty pages of a book you were meaning to read. It is not quite long enough to stop being annoyed about the eleven minutes. At about the four-hour mark the annoyance converts into something more useful: a detailed post-mortem of the sequence of decisions that produced the eleven-minute gap. Most of them were made in the forty-five minutes before departure at the previous airport, where I made three small judgements, each individually defensible, that compounded into a margin too thin for the queue at security. The lesson every missed flight teaches is the same one: the margin you need is not the margin you think you need. The queue was longer than expected. The terminal was further than the map suggested. The boarding pass was on a phone with 12% battery and the charger was in the checked bag. Each of these was knowable in advance. None of them was known. Hamad International is, despite everything, a good airport. The bear is disquieting. The coffee is genuinely excellent. The lounge I was eventually admitted to had decent food and a shower, which reordered the experience from disaster into merely inconvenient. The book was good. I would recommend the book. I arrived home six hours later than planned. Nobody noticed except me, which is the correct outcome for most travel inconveniences. The eleven minutes have been factored into all subsequent planning at that airport. I assume they will be factored out again by the time I next pass through.

Every BIM project of sufficient complexity eventually develops a parameter problem. The parameter problem manifests as: nobody can agree what a thing is called, and therefore nobody can query it reliably, and therefore the data in the model means nothing to the person trying to use the data. The parameter problem is presented as a technical problem. It is a social problem with a technical surface. The technical surface is real. Shared parameters, project parameters, family parameters — three types, each with distinct behaviour, each with their own scope of applicability and their own inheritance rules. A shared parameter GUID is globally unique but the GUID is invisible in the UI. A project parameter lives in the project and cannot be shared across projects without migration. A family parameter lives in the family and cannot be reported in a schedule without promotion. Understanding these distinctions takes about a week of serious study, and most people never take that week because they are already on the project. The social problem is worse. The parameter schema is designed by one person or one team, typically during project setup, when every decision that needs to be made is being made at the same time and nobody has the bandwidth to think carefully about parameter naming conventions. The schema is then inherited by everyone who joins the project subsequently. The people who join subsequently have opinions about naming, opinions formed on previous projects that had different conventions, and no compelling reason to abandon their opinions in favour of the schema because the schema was never explained to them and nobody is enforcing it. What happens over eighteen months is: the schema has twenty agreed parameters and sixty that were added by whoever needed something and could not find the right agreed parameter to use. The sixty ad-hoc parameters are not documented. They are not included in the schedule templates. They are not consistent across families. They contain some of the most important data on the project, entered by people who were trying to solve a problem and did what worked, and the data is now structurally inaccessible. The only fix is people: a standards owner with the authority to enforce the schema, a process for requesting new parameters that doesn’t default to just adding them, and a quarterly audit that has real consequences for non-compliance. The technical tooling to support this exists. The organisational will to implement it exists less reliably. The projects that solve the parameter problem are the ones where someone decided that solving it was worth the friction it would cause. Most projects decide it is not worth the friction. Most projects regret this.

It does: add to the skyline. Contribute to gross floor area. Activate a previously underused parcel. Provide 847 residential units the market apparently requires. Generate photographs that will be used in presentations about the dynamism of Dubai for the next six years. It doesn’t: solve the street. Address the pedestrian. Know what to do at ground level. Remember that buildings are experienced from the ground up, not the top down. Create a single reason to be at that location rather than any of the forty-three other locations offering identical amenities within a 3km radius. The ground floor is a lobby. The lobby is secured. There is no retail, no café, no public programme of any kind, because the developer’s model shows that mixed-use ground floors in this location have a 34% higher vacancy rate than residential lobbies and the bank financing the project does not accept 34% higher vacancy rates in its risk model. The bank is right by the logic of the bank. The city is wrong by the logic of the city. This is not a criticism of the developer. The developer built what the system incentivises. The system incentivises towers with sealed lobbies and managed footprints because that is what finances cleanly and sells quickly and causes the fewest arguments between the twenty-three parties who need to agree on every decision above a certain cost threshold. The building is fine. The building is one of several hundred fine buildings. The street between them is the problem nobody owns.

The parametric model can give you ten thousand options in the time it would take to sketch three. This is presented as an advantage. It is an advantage only if your problem is “not enough options.” The problem is rarely not enough options. The problem is usually “we cannot agree on which of three options is correct and have been in this meeting for two hours.” The limit of computation in design is not computational. It is the limit of the question you are asking the computation to answer. A parametric model can optimise a facade for solar gain, structural efficiency, and net lettable area simultaneously, and return a Pareto front of solutions across those three variables. This is genuinely useful. The model cannot tell you which point on the Pareto front is the right building for this client on this site in this city. That judgment belongs to the architect, and the fact that the model produced the options does not make the judgment easier. It makes it harder, because now there are ten thousand of them. The most honest thing computational design education could teach — and does not — is that computation amplifies the quality of your thinking. A well-formed question gets a genuinely illuminating answer. A poorly-formed question gets ten thousand variations on the same confused premise. The students who struggle with Grasshopper are not struggling with nodes and data trees. They are struggling with not having a clear enough sense of what they want and why they want it, which is a design problem, not a software problem. I have run parametric studies that changed the outcome of a building. I have also run parametric studies that took two weeks and confirmed what three experienced architects had said in the first meeting. The studies that changed things were the ones where the parameters were legible — where the variables corresponded to real design decisions with real consequences, not to every conceivable parameter simultaneously. The others were computation as performance. The room full of opinions is still a room full of opinions after the model runs. The computation changes the texture of the argument, sometimes for the better — “the data says the southwest corner is 40% more efficient” is a different kind of claim than “I think the southwest corner works better” — but it does not resolve the argument. Nothing resolves the argument except someone in the room having the authority and the judgment to make a decision. Computation cannot supply either.

The model collapsed at 4pm on a Thursday. Not a gradual failure — one moment it was open, the next it was not, replaced by the specific Revit error message that architects of a certain vintage have memorised the way others memorise poetry. The journal file was red. The backup was from 10am. Six hours of work, four people, one catastrophic sync. The recovery protocol for a corrupted Revit central model is well documented and mostly useless. You follow it anyway because there is nothing else to do. You open the backup. You audit the journal. You try the recovery wizard. The recovery wizard produces a model that opens but has lost the structural coordination layer, which is the layer that three engineers spent the morning updating. You note this and keep going because there is still a deadline. What the Thursday afternoon taught me, again, is that the backup interval the project team agreed on at project start — a number chosen because it sounded reasonable, not because anyone had done the arithmetic on what six hours of four people’s work actually costs — is wrong. The number is wrong on every project it is agreed upon, because it is always agreed upon before anyone has experienced losing that many hours of work, and people are systematically bad at estimating the value of time they have not yet lost. The project moved the backup interval to two hours the following Monday. There was a brief discussion about whether this would cause performance issues. It does not cause performance issues that are noticeable relative to the performance issues already present in a model of this scale. The discussion happened anyway because the new interval needed to be justified to people who had not been in the building at 4pm on Thursday. We recovered most of it. The structural coordination layer was reconstructed from exported IFC backups the engineers had maintained independently, which is a workflow nobody had formally agreed on and which turned out to be the thing that saved the day. It saved the day not because anyone planned for it but because the engineers had been burned before and had quietly implemented their own backup discipline without asking whether the project required it. This is the correct response to working in a field where the official backup protocol is insufficient.

The mistake most architects make when they encounter Grasshopper for the first time is that they treat it like software to be learned. It is not. It is a way of thinking made visible, and if you have not already internalized the thinking, the software teaches you nothing. You can watch tutorials for forty hours and still produce spaghetti that does one thing and breaks when you ask it to do something adjacent. The thinking that Grasshopper encodes is: what are the inputs, what are the transformations, and what is the output? This is also the thinking behind every script ever written, every spreadsheet formula, every function in every programming language. Grasshopper just puts the wires on screen so you can see the data flowing. This is useful if the wires help you understand the logic. It is actively misleading if you use the wires as a substitute for understanding the logic. The useful Grasshopper definition looks like a directed acyclic graph with clear lanes: geometry comes in, geometry is transformed, output goes to Rhino or into the next transformation. The useless Grasshopper definition looks like a plate of noodles. Both can produce the same output. The noodle definition will break when you need to change anything. What I want from a designer using Grasshopper is the same thing I want from a designer writing Python: a clear mental model of what the problem actually is. The surface area of the problem has to be understood before you start connecting nodes or writing functions. In Grasshopper the temptation is to just start connecting things and see what happens. Sometimes this works. More often it produces something that works in one case and you do not know why it works, which means you cannot extend it or fix it when it doesn’t. Grasshopper is a good tool for the right problems: geometry that follows rules, geometry that needs to vary with parameters, geometry that you need to understand in terms of its underlying logic rather than its appearance. It is a bad tool for one-off shapes, for things that are fundamentally about judgment rather than rules, and for anything you will need another person to maintain. On a project where the algorithm will be handed off, I would rather have three hundred lines of annotated Python than a well-organised Grasshopper definition, because Python can be read, versioned, reviewed, and tested. Grasshopper definitions are black boxes that happen to be transparent.

A fictional hospital in Cairo, built entirely in Rhino 3D across fifteen layers and three hundred and twenty-eight objects. They will never be built. This was always the point. Building something in full detail without a client, a site, or a brief teaches you what the tools can do when not compromised by what anyone will pay for. The hospital occupies a hypothetical site in Heliopolis — a neighbourhood I chose because the photographs showed a particular quality of light and a street grid dense enough to make an interesting programme. The brief I wrote for myself: a 280-bed surgical hospital, public-facing pharmacy at ground level, staff accommodation in a separate wing, central courtyard that could function as a shaded outdoor recovery space from October through April. The structural approach was the interesting part. Ribbed concrete — a system largely abandoned in the 1980s in favour of flat plate, because flat plate is cheaper to form and faster to build. Ribbed concrete is more material-efficient, structurally expressive, and significantly more difficult to document. I wanted to understand why it disappeared from practice. You understand why things disappear from practice by trying to use them. Three months to get the geometry right. Two weeks realising the geometry was right but the programme was wrong — the surgical suites needed 4.2m floor-to-floor to accommodate mechanical and I had specified 3.8m in the original scheme. The revision cascaded through eleven floors of structure. This is what clients pay for: someone else to have this problem before the concrete is poured. The building will never be built and is, for that reason, perfect. Everything I chose, I chose for the right reason. There are no compromises in it except the ones I made with myself, which are the only honest kind.