For the longest time, I thought architecture was something other people did. Not I. Design patterns? MVC? I thought it was MVP??
Senior engineers. Whiteboards. Diagrams with boxes and arrows drawn before anyone touched a keyboard. A Big Design Up Front you'd follow like a blueprint.
I didn't do any of that at first, I just built things. Usually to fix something annoying in my own life. And somewhere in the middle of building them, architecture showed up anyway — uninvited, lurking there like a menacing entity in the corner of my eye.
I thought "clean code" and "architecture" were the same thing.
HA
They're not, and it took me embarrassingly long to figure that out.
Clean code is: can a human read this function without wanting to lie down.
Architecture is: when two features touch each other, who wins? When an assumption breaks, what happens? When this thing is running and that thing also wants to run, who's actually in charge?
You can write beautifully clean functions that still produce total chaos the moment two of them run at the same time and disagree about what's true. I know, because I did exactly that. Multiple times.
the bug that actually taught me something
It always starts small. One feature works fine in isolation. A second feature, also fine in isolation. Then you turn them both on at once and something starts behaving like it's possessed.
A timer fires late and overwrites state that's no longer relevant. Two processes both think they own the same resource. A "temporary" condition turns out to outlive the thing that set it.
None of that shows up in a tutorial. Tutorials show you the happy path, this input, that output, done. Nobody shows you the moment where two reasonable pieces of logic collide and you have to decide, on the spot, who's allowed to win.
That collision is architecture. The decision about who's in charge when things overlap.
the question I wish someone had given me earlier
I didn't learn this from a book. (Actually that's a lie, I got this whole article idea from a book but shh)
I learned it from getting the same category of bug over and over until I got sick of it and finally asked the right question instead of patching the symptom again.
The question was embarrassingly simple:
"What owns this, and what happens the moment the assumption underneath it breaks?"
Not "how do I make this feature work." That part is usually easy. The real work is figuring out what happens when the thing you were quietly assuming — the network's up, the file exists, the user does things in order, nothing else is touching this at the same time — turns out to be false.
Once I started asking that question on purpose, instead of discovering it via 11pm bug, entire categories of bugs just... stopped happening.
you don't need the theory first. you need the scar tissue first.
These days I do sit down and sketch some of it out before I build — but that habit came after the scar tissue, not before it. I don't think that's actually where architecture comes from, for someone learning the way I am.
My rule is closer to: build the small, useful version first. Let the real architecture get earned by an actual need, not invented in advance because it sounded impressive on a resume. Most side projects don't die from too little architecture. They die from someone over-engineering a v1 that didn't need it yet.
But there's one exception I've learned to make: before I ship anything, I ask that one question once. What owns this. What happens when the assumption breaks. That single sentence has saved me more debugging time than any diagram I've ever drawn — because it's not a plan, it's a boundary. And boundaries are the only part of "architecture" that actually holds up once real usage starts hitting it.
Nobody teaches you this part. You just have to break something enough times to notice the pattern underneath the breakage.
Which, honestly, might be the only way it actually sticks.
Top comments (1)
Insightful xD