I did design and rendering before I did infrastructure. The two are usually described as unrelated, and I think they are the same activity with one variable changed: what a single iteration costs.
Two things follow from that number, and the second is the one that decided my career. The first is that everything people file under “different cultures” is arithmetic rather than temperament. The second is that iteration cost sets how many attempts you get in a working life — not per project, per lifetime — and a discipline that charges thousands of dollars per attempt hands you a much shorter list of things you will ever get to try.
What the two jobs have in common
Strip the vocabulary and both jobs are: describe a system precisely enough that something else can execute it, under constraints you do not control, where the description is judged by what happens when it runs.
- Both are geometry under constraint. A facade resolves against structure, cost, orientation and code. A system resolves against latency, cost, failure modes and compliance. Both are a search for a shape that satisfies more requirements than any one of them wants to allow.
- Both hand execution to someone else. A drawing is executed by a crew. A manifest is executed by a scheduler. In neither case do you get to stand there and clarify what you meant, which is why both disciplines are obsessive about notation.
- Both are judged on the thing that gets built, never on the elegance of the description. A beautiful detail that cannot be poured is a failed detail.
- Both live or die on iteration count. The quality of the output is mostly a function of how many alternatives were genuinely evaluated, in design exactly as much as in engineering.
That last one is where they part company, because the two disciplines pay wildly different prices for an alternative.
The price of being wrong
| 3D design and construction | Infrastructure and code | |
|---|---|---|
| One iteration | Machine hours, or a materials order and a crew | A pipeline run |
| Being wrong | Rework, or demolition | A revert |
| Who pays | The client, in money | You, in time |
| Reversibility | Mostly one-way | Mostly two-way |
| Rational strategy | Be right before you commit | Find out fast, cheaply, often |
A change to a rendered scene costs render time on hardware you own. A change to something already built costs materials, labour and schedule, and every line on a construction drawing is a commitment to spend. That is why the profession has drawing conventions, review sets, sign-off stages and a culture of checking: when a mistake costs thousands of dollars and cannot be undone, front-loading judgment is the only strategy that survives contact with a budget.
Deployment inverts it. A bad deploy costs a revert. So the rational investment moves from being right in advance to finding out quickly: tests, staging, canaries, feature flags, rollback. The engineer has noticed that when iteration is cheap, the fastest route to a correct answer is to be wrong several times in a row at low cost, and the whole tooling stack is built to make that true.
Both responses are correct. Each would be ruinous in the other’s cost structure. An architect who deployed to production would produce buildings that fall down; an engineer who spent six weeks on a review set before shipping a config change would be replaced by someone who shipped it in an hour and reverted it twice.
Where software has DWG lines
Here is the part that took me longer to see, and the part that is actually useful.
Software is not uniformly cheap to iterate on. It has its own construction drawings — the changes where being wrong costs real money and cannot be reverted — and they are not labelled. Recognising them is most of the job.
- Destructive migrations. Dropping a column is a demolition. The rollback restores the schema and not the data.
- Anything customers have already received. A sent email, a charged card, a published API that someone has now built against. Distribution is one-way.
- DNS, domains and certificates, where the mistake propagates to caches you do not own and the fix waits behind somebody else’s expiry.
- Data you did not back up before touching, which is the same class of mistake as pouring concrete over a service you needed access to later.
- Interfaces other teams build against. Cheap to write, expensive to change, and the cost lands on people who never saw the decision.
For those, the architect’s discipline is the correct one, and it is not the default posture of the discipline they sit in. Slow down. Draw it. Have someone check the drawing. Assume you get one attempt, because you do.
This is precisely the reasoning behind ranking work by what cannot be undone rather than by effort. Impact-effort scoring treats all tasks as equally reversible, and the irreversible ones deserve a different process rather than a higher priority.
What transfers, in both directions
Coming from the expensive discipline into the cheap one leaves you with a habit that is genuinely scarce there: the instinct to be right before committing, and to know which decisions deserve that instinct. Construction charges thousands of dollars per lesson, so you learn it fast. It shows up as reading the migration twice, and as noticing that a change is one-way before rather than after.
The traffic runs the other way too, and it is the more surprising direction. Production discipline turns out to improve building design: reduce the number of components that can fail, make dangerous states unreachable, contain the blast radius, design for the load you will have later. That is what I actually used when designing my own house, and the architecture education was the smaller contributor. Neither discipline’s core skill is domain-specific; reasoning about constraints and knowing what “finished” means are the same skills wearing different clothes.
The number worth asking about
Any team, in any discipline, is answerable to one number: what it costs to find out you were wrong, and how long that takes.
That single number predicts the rest. Where it is high, the team’s energy correctly goes into judgment, review and getting it right first. Where it is low, energy goes into shortening the loop further, and a team that spends its effort on ceremony instead is paying construction prices for software work. Careful process on cheap, reversible work is waste dressed as diligence. Fast iteration on irreversible work is how buildings and databases get destroyed.
Why this is a career question and not only a process one
The same number applies to a person, and there it stops being a matter of process.
If one attempt costs materials, permission and a client willing to fund it, you will make a small number of attempts in a lifetime and most of them will be somebody else’s idea. If one attempt costs a weekend, the count is effectively unbounded and the ideas can be yours. Same person, same judgment, two completely different bodies of work at the end, decided by a variable that has nothing to do with talent.
That is the whole reason I tore down the expensive discipline rather than optimising inside it. Not because the work was worse; it was not. Because the number of times I would get to be wrong was the real limit on anything I would ever build, and it was set by the vehicle rather than by me. Choosing the domain is choosing that number, and it deserves to be chosen deliberately rather than inherited from whatever you happened to study.