The Smart Dumb Programmer. Why your best architectural instincts… | by Fayner Brack | May, 2026 | MediumSitemapOpen in appSign up<br>Sign in

Medium Logo

Get app<br>Write

Search

Sign up<br>Sign in

The Smart Dumb Programmer

Why your best architectural instincts are slowing you down

Fayner Brack

4 min read·<br>May 21, 2026

Listen

Share

A simple drafting table with a pencil sketch of a cube, set against a wall of dense, overcomplicated architectural blueprints.

Want to come back later? Save this to readplace.com.<br>The Smart Dumb Programmer

This is aimed at YOU. The expert engineer. The one that has been through every single possible outage and business problem in a multi-BILLION dollar company.<br>Let's be honest.<br>Experience is supposed to make you faster. You ship one system, learn what broke, and carry those lessons into the next one. After a few rounds, you can see the problems before they arrive.<br>That is the trap.<br>Your first project teaches you real things. You hit actual walls. You discover that a monolith doesn’t split cleanly. You learn that shared state between services creates bugs that take days to trace. You watch a sync call chain collapse under load. These lessons are real. They cost you time and sleep.<br>So when your second project starts, you bring all of it. You reach for event-driven architecture and even-sourcing on day one. You split services before you understand the domain. You add a message bus because you know you’ll need one eventually.<br>You are solving the problems of your last project.<br>The domain is different. The users are different. The scale is different. But you are building for the experience you already survived, not the one you are about to discover.<br>What I do is to start with the dumbest implementation. Every. Single. Time.

Not because I don’t know any better (other experienced peers can build that opinion from day one), but because starting dumb is how I learn what this project actually needs beyond my own biases. A prototype does not need an event bus. It needs to work. It needs to ship. It needs to show you where the real pressure points are, not the ones you remember from two years ago or from the last company with 5 thousand engineers.<br>Here is what that looks like in practice:<br>Get Fayner Brack’s stories in your inbox

Join Medium for free to get updates from this writer.

Subscribe

Subscribe

Remember me for faster sign in

You are building a new service. You know from experience that event-driven design handles scale well. You have seen RPC chains buckle under traffic. So the smart move is to start with events and queues from the beginning.<br>Don’t.<br>Start with plain RPC calls. Direct request, direct response. The simplest thing that works. Pure server-side HTML if you must, no libraries or frameworks.<br>Ship features on top of it. Talk to users. Watch where the bottleneck actually forms. Maybe it’s the same place it was last time. Maybe it’s somewhere you didn’t expect. You won’t know until real usage hits real code.<br>As traffic grows, you’ll see which parts of the domain need to decouple. Not all of them. A subset. Separate that subset. Move those specific calls to async messaging, use SPA on them. Keep the rest as RPC until the pressure tells you otherwise, a future which likely may never come at all!<br>Then, as you get more customers, swap transport mechanisms where the data justifies it. Each change is small. Each one is backed by evidence you collected while the system was running.<br>The whole time, you are delivering features. You are not pausing to rebuild.

This is the part that matters most. A dumb implementation that ships features is worth more than a smart architecture that delays them. Your users don’t care about your message bus. They care about the thing they asked for last week.<br>There is a second benefit that is easy to miss. Starting dumb on every project exercises your ability to handle technical debt on purpose. You are not accumulating debt by accident. You are taking it on deliberately, with a plan to pay it down as the system tells you where to spend.<br>That is a different skill than avoiding debt. Avoiding debt is defensive. Managing debt is operational. The best engineers I have worked with are not the ones who build clean systems from the start. They are the ones who can move through a messy system quickly and know which mess to clean up first. The Product Owner of Technical Debt.<br>Does this mean you ignore everything you learned? No. Experience tells you what to watch for. It gives you faster pattern recognition when a bottleneck appears. It helps you move from RPC to events in an afternoon instead of a week.<br>But it should not tell you where to start.<br>Starting smart feels like saving time. Starting dumb is how you actually save it.<br>In the end, that doesn't look so dumb at all.. 🤔

If you liked this, you might like readplace.com, built for exactly this kind of reading.<br>Thanks for reading. If you have some feedback, reach out to me on LinkedIn, Reddit or by...