I’ve Written 50 Articles on Software Architecture. Here’s Where to Start.
A full guide to the back catalogue, arranged by the problem in front of someone, not the date it went up.
I’ve Written 50 Articles on Software Architecture. Here’s Where to Start.
A full guide to the back catalogue, arranged by the problem in front of someone, not the date it went up.
This is a member-only story. If you’re not a Medium member, you can read it for free through the friend link.
A full guide to the back catalogue, arranged by the problem in front of someone, not the date it went up.
Every so often, someone tells me they found one of my articles, liked it, and then could not work out what to read next. I understand the problem completely. My own profile, sorted newest-first the way every profile is, opens on whatever I happened to publish last week, which is usually the slightest thing I have written all month. The piece that might actually change how a person works is buried somewhere underneath a season of smaller stuff, and nobody digs that far down on a first visit. The feed is a publishing artifact. It was never a reading order, and it does a genuine disservice to anyone arriving for the first time.
🚀 Your Job Search & Resume Builder in One App ✔ Find new job opportunities ✔ Create ATS-friendly CVs
So I want to do the thing the feed cannot, which is sit down and talk through the work the way I would if we were across a table, and the question came up: of everything here, where should I actually start? The honest answer is a personal one, because the writing is personal. None of it began as a curriculum or a plan. It came out of a working career, one preoccupation at a time, written mostly to figure out what I thought, and only much later did I notice that almost all of it was circling the same thing.
What follows walks through the five longer series and the shorter pieces underneath them, says what each one came out of and who I would hand it to, and tries to be honest about which ones are worth a real commitment and which can be sampled and put down. If the whole walk-through is more than the moment calls for, the one-line version is near the end. But the longer answer is the true one, and it is the one I would rather give.
What Fifty Articles Turned Out to Be About
If I am being straight about it, the thing that all of it circles is the part of the job that happens before any code gets written or any decision gets made. The part where the whole trick is seeing a system clearly instead of reacting to whatever it happens to be doing that week.
I did not set out to write about that. I set out to write about analytics because that was the work in front of me, and then about technical decisions because I kept making ones I regretted, and then about the systems I kept inheriting because that turned out to be most of what the job actually is. Somewhere in the middle of all of it, the real subject made itself known. The specific topics were never the point. They were surfaces, and underneath every one of them was the same quieter question: what is actually going on here, and what am I not seeing yet.
That is worth saying up front because it changes how this whole catalog should be read. These are not five unrelated bodies of work that happen to share an author. They are five angles on one preoccupation, which means it almost does not matter where a person starts, as long as it is not the top of the feed. The fastest way in is whichever surface is closest to the problem currently on the desk. The deepest way in is to read enough of them that the shape underneath starts to show through on its own. Either works. What follows is mostly about helping with the first.
The Systems I Did Not Build
Start with the systems I did not build, since that is the overwhelming majority of them. For almost my entire career, the work has not been starting something clean and watching it grow. It has been walking into something already running, already load-bearing, already holding up a business, with nobody left in the building who remembers why it was built the way it was. The green-field project everyone interviews for is the exception. The inherited system is the job.
It took me longer than I would like to admit to stop treating each of those arrivals as an emergency and start treating them as reading. Early on, an unfamiliar codebase felt like a threat, a thing to be subdued before it embarrassed me. Now, the first hour is not about fixing anything at all. It is about finding the error handling, locating the deploy script, learning where the thing actually breaks under load, and reading the structure of the code as a record, the way tree rings are a record, of what the people before me were worried about. The day that stopped feeling like rummaging through a stranger’s house and started feeling like archaeology was, more or less, the day I got better at this job.
That whole instinct is the spirit of ***The Systems You Inherit***. It runs five parts. It opens on those first forty-eight hours, the real version rather than the idealized one, and then turns to reading the decisions made before anyone arrived, treating the dependency choices and the naming conventions as evidence of what the original team was optimizing for and asking whether that context still holds. The middle of the series sits on the parts of a system that nobody owns, the code between teams and between services, and makes the case that quietly adopting one of those orphaned zones is often the highest-leverage work available to a senior engineer. The hardest part is the one about judgment: when to rewrite, when to refactor, and when to leave a working thing alone, which is a call I have gotten wrong in both directions more than once. And it ends somewhere I genuinely did not expect when I started writing it, on the slow turn from “someone else’s mess” to “my responsibility” to, finally, “my system,” made better without being torn down and rebuilt.
If the thing on the desk right now is something somebody else built and then walked away from, that is the series I would put in someone’s hands first.
The Choices That Calcify
A different and more uncomfortable feeling runs through the writing about decisions. Anyone who has done this for a while is carrying a few choices that were completely sensible at the time and have since calcified into the thing nobody can unwind. I have made my share, and the ones that stay with me were never the careless calls. They were the careful ones, the ones I would make again with the same information, that the world simply moved out from under.
What I slowly worked out, and what ***Architecture of Decisions*** tries to pass on across six parts, is that the most useful question in front of a decision is almost never whether it is correct. Correctness is usually knowable and usually agreed on. The questions that actually separate a good architect from a merely competent one are quieter. Can this be walked back, or does the door lock behind the team the moment it ships? How far does the damage travel if it turns out badly, and is that blast contained, or does it take everything down with it? How well does it hold up once the situation that justified it has changed, which it always does? And how much of the uncertainty around it is the kind that waiting will resolve, versus the kind that only deciding will.
The part of that series that still humbles me most is the one I called decision debt. A data model that fits the product perfectly on day one can become, with nothing whatsoever changed about it, the reason every new feature costs more than it should and every engineer who touches it leaves a little more frustrated. Nothing about the original choice was a mistake. The context underneath it shifted, and a right answer quietly became a wrong one. Learning to see that coming, and to build in a way that expects it, is most of what the series is trying to teach. The capstone turns that into something practical, a way of keeping a decision journal so an organization can actually learn from its own choices instead of relitigating them every two years.
It is the most foundational of everything here, and the one whose vocabulary I keep noticing leak into the rest of the writing. If decisions and their long aftermath are the thing keeping someone up at night, I would point them here, and I would tell them to read it in order, because the parts are built to stack.
The Walls I Could Not Name
One stretch of the work is narrower and more technical than the rest, and I will be upfront that it is not for everyone. For a few years, I built systems that used events to shuttle messages around while, underneath, I was still thinking entirely in terms of current state. They worked, technically. But I kept running into walls I could not name at the time, and almost all of them turned out to be the same wall: questions about history, about what had happened and in what order, that my designs simply could not answer once the moment had passed. I had thrown the history away as a matter of course, because I was only ever storing where things currently stood.
***Event-Driven Thinking* **is me working out, well after the fact, what I had been missing. The central reframing is that an event is a way to model what happened, not just a way for one service to tell another that something changed. The difference between asking what a thing is right now and asking what has happened to it is the difference between a snapshot and a story, and once a system keeps the story, a surprising amount becomes possible that was impossible before. The series separates commands from events, intent from fact, and works through why conflating the two creates problems that are expensive to untangle later. It spends real time on what changes when time itself becomes something the system records rather than overwrites. And it stays honest, in the parts I think matter most, about where event sourcing earns its considerable cost and where it is simply expensive and fashionable, because that is the assessment nobody seems to offer before a team commits to it.
This is the one series I would tell most people they do not need to read end to end. If the tradeoffs are live in the work right now, all five parts are worth it. If they are not, the first part carries the reframing on its own, and there is no shame in reading that and stopping.
The Oldest One, and the One I Am Proudest Of
The oldest series is the one I am quietly proudest of, and the one newer readers skip because the title makes it sound specialized in a way it is not. ***Building Systems That Think ***is seven parts about real-time analytics, but the actual subject, the one that turned out to underwrite everything I wrote afterward, is the idea that a system’s best qualities, its speed, its correctness, its ability to answer a genuinely hard question without falling over, come from how it was built and not from optimization sprinkled on at the end.
That sounds abstract until it bites. The instinct most engineers reach for when a system is too slow is to optimize the slow part, and sometimes that works. But the systems I have admired most were not fast because someone went in afterward and made them fast. They were fast because they had been shaped in a way that made slowness structurally hard, where the expensive question had already been answered by the time it got asked. Learning that distinction felt less like picking up a technique and more like a quiet correction to how I saw the whole problem, and it changed the kind of engineer I became. The series is the longest single argument I have made and the most technically demanding thing here, and it rewards reading in order more than the others, because the later parts lean on foundations the earlier ones lay down.
If the problem in front of someone is a data system that runs fine until, all at once, it does not, this is where I would send them. And honestly, even if it is not, this is the series where I first learned to think the way the rest of the writing quietly assumes its reader already does.
The Judgment Underneath the Rest
The writing that is barely technical at all is probably what I would point a complete stranger toward first, which surprised me when I noticed it. ***The Senior Engineer’s Toolkit*** is five parts about the judgment sitting underneath everything else, the things experienced engineers do without quite being able to explain how.
It opens on the single habit I lean on hardest, which is asking of any decision not whether it is right but what it makes easy going forward and what it makes hard, treating the choice as terrain rather than a puzzle with one correct answer. From there, it moves to tracing second-order effects, the consequence of the consequence that first-order thinking walks straight past, the cache that makes a page fast, and a cache-invalidation bug is inevitable. Then, to communication, and the argument that the best technical communicators explain less rather than more, because they have read the listener well enough to know what to leave out. Then to prioritization as judgment rather than project management, the genuinely senior move of deciding which problems are simply not worth solving at all.
And it closes on a piece I am genuinely fond of, an admission I did not see coming when I started the series: that the mental models I had spent four parts teaching were never tools I reach for at all. They had quietly turned into something else, a slow change in what I notice before I have done any deliberate thinking, which I only realized I believed once I had written my way to it. That last part stands on its own as a single taste of how my head works, and a lot of readers have started there. But the four before it are where the claim gets earned, and I would not skip them if the goal is to actually take the idea on rather than just nod at it.
The Ones That Are Not Series
Not everything here is a series, and not every visit calls for committing to one. A good slice of the catalogue is shorter, single observations of eight hundred to twelve hundred words, the kind of thing I write when one idea will not leave me alone and does not need a frame to hold it up.
They tend to fall into a few recognizable kinds, though I never set out to write them into categories. Some are diagnostic, about what I check first and what I notice when I am dropped into a new team or a new system. Some are observations of patterns I have watched repeat across more engineers and more teams than I can count. Some are arguments against a specific practice nearly everyone takes as settled, made carefully rather than as blanket contrarianism. And a few are just stories that cost me something real, the kind of career piece that is grounded in a particular failure rather than abstract reflection.
Two of them have quietly outrun everything else I have published, one about why I stopped refactoring to make code better, and one about a single thing almost every senior engineer I have worked beside turns out to do. Either is a genuinely low-stakes way in, an afternoon rather than a commitment, and both are linked just below this piece. If the question is whether this way of thinking is worth more of the time, one of those is where I would test it before spending an afternoon on a whole series.
Where I Would Point, If Pushed
If I had to crush all of that down to a single line of advice, it would be this:
Do not start at the top of the feed. Start with whatever is actually on the desk this week.
- Something undocumented landed, and nobody owns it: the inheritance series.
- An old decision is still doing quite a lot of damage: the decision series.
- A data system is buckling under the questions it used to handle: the analytics one.
- Curious about the judgment underneath all of it, and uninterested in the plumbing: the Toolkit.
Everything else will keep until its week comes around.
One Honest Thing Before This Gets Too Neat
I should be honest about one last thing, because the kind of tidiness I have just performed is exactly what I distrust in other people’s writing. A reading order is a story the author tells afterward, and it is always cleaner than the writing actually was. I did not plan any of this. It piled up the way most of what we make piles up, in no particular order and for no reason grander than whatever I happened to be stuck on that month. The five neat lanes I have just walked through are a pattern I noticed long after the fact, not a route I set out to follow.
Which might be the most useful thing I can offer before pointing anyone anywhere: the order is a convenience, not a curriculum, and every one of these was built to stand on its own. None of them needs the others. They only turn out, read side by side, to keep circling the same quiet idea, the one about seeing the system before reacting to it, the one I have apparently been writing about for fifty articles and still have not finished thinking about. Which is probably why there will be a fifty-first.
Thank you for being a part of the community
Before you go:
👉 Be sure to clap and follow the writer ️👏️️
👉 Follow us: **Linkedin| [Medium](https://medium.com/codetodeploy)**
👉 CodeToDeploy Tech Community is live on Discord — **Join now!**
Disclosure: This post includes affiliate and partnership links.
메타데이터
- post_id
- dfa65d6e4923
- slug
- ive-written-50-articles-on-software-architecture-here-s-where-to-start-dfa65d6e4923
- url
- https://medium.com/codetodeploy/ive-written-50-articles-on-software-architecture-here-s-where-to-start-dfa65d6e4923
- canonical_url
- https://medium.com/codetodeploy/ive-written-50-articles-on-software-architecture-here-s-where-to-start-dfa65d6e4923
- author_url
- https://medium.com/@saeedhbi
- status
- ok
- fetched_at
- 2026-06-27 18:20:27
