DEV Community: Adam - The Developer ✨

Greatness Is Forged by Limitation

Adam - The Developer ✨ — Wed, 19 Aug 2026 13:04:47 +0000

Can't believe I spent 2 weeks writing this.

Last week, I gave a talk at a Cursor community event about AI and how it's changing the way we build software. The event went great, and after the talk, quite a few people came up to me for 1:1 conversations.

One particular guy caught my attention. He wasn't a technical person, but he asked me something interesting:

"With so many tools and technologies available today, how do you even navigate all of this and pick the right ones?"

He thought it must be overwhelming. Then he smiled and said that with so many options available, he hopes many great things be built.

I thought about it for a second and smiled too, and before I could answer, he had to leave... but his question stuck with mi.

A few days later, sitting in a library looking for something to read, I ran into an answer: UNIX Network Programming by W. Richard Stevens. (Great book btw, give it a read!)

90s tech, limited memory, limited processing power, limited bandwidth and limited tooling... etc.

Yet somehow, we got things like UNIX, TCP/IP, early operating systems, incredible mathematical breakthroughs, massive engineering projects, and some of the most elegant pieces of technology ever built.

It made me wonder:

What if the things that limited us were also the things that forced us to become better?
What if greatness isn't always created by having more, but by being forced to do more with less?

The guy assumed more tools meant a better shot at greatness, but the book in my hands was proof of the opposite.

The Paradox of Limitation

I believe there's a reason having less can sometimes make us better.

We usually think of limitations as something to overcome: less money, less time, fewer resources, less knowledge. All of it standing between us and what we want to achieve.

But there's another side to limitation we don't talk about enough.

A limitation doesn't just take something away. It also takes away what could have been.

And maybe that's exactly what we need. Because when everything is available, when every direction is possible, every tool is at hand, every approach is open to us, it sounds like freedom.

But freedom without boundaries can be surprisingly hard to live inside.

You give someone unlimited resources and they can spend a lifetime deciding what to do with them. Give them nothing and the question suddenly gets simple:

How much can I achieve with what I have?

That question changes how you think. You stop searching for the perfect tool, because it doesn't exist, and start building with what's in front of you. You notice details that would otherwise stay invisible, not because you're more observant by nature, but because you no longer have the luxury of not noticing.

Maybe that's the real gift of limitation. Narrowing down your options but also sharpening your attention.

Perhaps that's the paradox: the fewer doors we have, the more clearly we see the one we're standing in front of.

And btw, this isn't a new idea.

Constraints Force Creativity

The book

Let's take a look at Stevens' book for a moment. The book is essentially a walkthrough of the sockets API: socket(), bind(), listen(), accept(), connect(), read(), write(), and close().

That's the whole vocabulary for making two machines on opposite sides of the planet talk to each other reliably.

But Stevens didn't invent those calls. The Berkeley sockets came out of UC Berkeley's CSRG in 4.2BSD, around 1983. Stevens wrote the book that taught a generation of programmers how they actually worked.

He wasn't designing for a world of infinite compute. He was documenting an API built in an era of expensive memory, slow CPUs, and unreliable, low-bandwidth links and there was no room for mistakes, sprawling do-everything interfaces, or generic, accept-all contracts.

Every function had to earn its place.

And with those constraints forced upon the people who designed it, the result is an API so minimal and well-composed that, four decades later, in a world where none of those original constraints exist anymore, it's still the interface nearly every programming language wraps for networking.

Take Python's socket module, Node's net module, or Go's net package, they all trace their shape back to those same eight or so primitives.

The paradox in miniature: by not having the luxury of building something bloated, they had no choice but to build something timeless instead. BSD built it under scarcity. Stevens documented why it was that tight.

And of course, this is also what surprised mi when I decided to pick up a book from the 90s. I expected it to feel dated but instead, I ended up learning a great deal from it, much of which I can still apply to the software I'm building today.

C

The language that started it all, laying the foundation for everything we have today.

C is a good example here, a language so elegant yet it gives you remarkably little. no GC, no elaborate standard abstractions, no safety net between you and memory. want something? you often have to understand what's happening underneath.

By today's standards, we'd call it unsafe or labeling it a weakness but that limitation also forces a certain kind of thinking, you have to pay more attention to details, you become more conscious of memory, data layout, ownership and what the machine's actually doing.

The language doesn't give you many options or answers but it makes you ask better questions and make better, timeless decisions.

Go

Let's come back to the future, let's look at Go. Go takes a different direction, Its constraints weren't imposed by hardware, they were largely chosen by its designers.

With all the things available by its time, the language was designed with its featured kept deliberately minimal & simple. syntax wise, type system wise, fewer ways to express the same idea.

When a language gives you fewer ways to solve a problem, you spend less time debating which clever abstraction to use and more time solving the problem itself.

Go's restraint is the feature, What it leaves out is just as intentional as what it includes.

Music

I play the piano, so this one isn't theoretical.

Today you can put a DAW, a thousand plugins, and an AI vocal fixer on a laptop and make a record anywhere. In the 70s and 80s, a lot of that work was physical. Cut the wrong stretch of tape and it was gone. Limited tracks, limited studio time, expensive gear. The band had to know the part. Screw up a take and sometimes everyone started over.

When recording time costs real money, you don't spend six hours on a snare. When you have eight tracks, you decide what deserves one. You can hear that in the records: the performances, the imperfections, the decisions.

I'm not arguing we go back to splicing tape. I'm saying the constraint did work that infinite undo doesn't.

The Problem With Having Everything

Abundance can create complacency, endless choices... which creates the temptation to solve every problem by simply throwing more at it.

Let's come back to our topic regarding AI. Like a modern DAW, I believe AI is a wonderful partner in our work. But next to that, it is also removing a great deal of constraints faster than almost anything we've seen before.

Just a few years ago, a requested feature would take around 1-2 months. Trying a different architecture meant actually building it. Rewriting a block of code took time, and if it wasn't mine, I had to understand the context first.

Now I can ask AI to do all of that in seconds. The thing that used to stop you was effort. When that cost drops, it's easy to stop asking whether you should do it at all. You generate five versions instead of picking one. You add another library because the model already knows it. You rewrite working code because the new draft looks cleaner.

The shift isn't "can I build this?" anymore. it's "Should I?"

When you have nothing, the limits are imposed on you. When you have everything, you have to impose some on yourself.

So What Do You Do With That

I never got to answer that guy at the event. If I could now, I wouldn't give him a list of tools.

I'd tell him more options don't guarantee better work and they just make it easier to never decide. The 90s didn't produce UNIX because people had more. They produced it because they had less, and less forced the work to get honest.

That doesn't mean throw AI away, or go back to cutting tape, or write everything in C. It means the environment won't hand you a limit for free anymore. If you want the sharpening, you have to pick one. Ship one use case. Let the model generate the boring parts and keep the core decision yours. Give yourself a deadline ugly enough that you can't keep adding.

Cap the stack this week.

Understanding Over Origin: The Missing Friction

Adam - The Developer ✨ — Tue, 04 Aug 2026 04:36:13 +0000

A few days ago, I wrote "Understanding Over Origin" and it got alot of engagement and I'm really happy that it did because it means people took the time to read, understand my perspective and I get to engage with every one of them in the comments as well. Of course, not everyone agrees but that's irrevelant, the point is a healthy discussion between various perspective from different developers around the world.

But what I haven't told anyone is this: the more I engage, the more I realized something that I still do. I still write a lot of my code by hand and those are the parts I'm more proud of "

Not gatekeeping, not me being nostalgic or identity-defensive ( well, a little nostalgic ), that's me admitting the article I published was incomplete.

Some conversations don't end when the replies stop. My discussion with @darkwiiplayer was probably my favorite of all because more we talked, the more I found myself wrestling with an incomplete idea that refused to stay unfinished and this essay is the result.

What the Discussion Clarified

First, I need to thank the people who actually engaged with the core argument.

@unitbuilds gave his take that seams everything together and concludes the core idea of modern software enigeering: " If it can run a standardized benchmarking suite against competition, it's provable and reproducible. If that's good enough for a scientific discovery, it's good enough for programming.", they're not defending AI, they're saying with better standards available, we shouldn't choose to ignore them. He also pointed out something I'd missed, the burden of correctness has always been on the developer who signs off on the PR.

@madsendev who wrote the original article that sparked this whole discussion, showed genuine class. He came back, said the argument had "gone further," and proposed an idea that's stuck with me: what if AI-assisted projects included a standard where you quiz yourself on your own repository? Not to prove you didn't use AI, but to prove you actually understand what you built.

@reidmarlow hit on something important and i think it's my favorite takeaway from the discussion: "Maintenance receipts are much harder to fake." That single sentence reframes the entire debate. Tests. Bug fixes. Production incidents. Responding to issues. Refactoring. Every one of those leaves a trail of evidence that someone not only built the project but continues to understand, improve, and take responsibility for it. That's the kind of ownership that matters. It's earned over time, and it's far harder to fake than explaining code in an interview or claiming you wrote every line by hand.

I'm absolutely grateful that people gave in their thoughts but you can never have a good discussion without a pushback ⚔️

the pushback's always my favorite part of any technical discussion.

The Challenge That Made Me Think

@darkwiiplayer showed up and said something like: "Training AI on stolen code without consent is theft. Everything built with AI carries that theft in its DNA. You're overlooking this."

She wasn't being rhetorical, she was actually making a philosophical point about training data, consent, and what "learning" means when it's done at scale without permission.

We went back and forth. I argued that training data and generated output aren't automatically equivalent to copying and she countered that if you removed all stolen code from training data, the models wouldn't exist as they do. Which is... probably true? And that matters.

I don't think it invalidates the engineering argument. But it does mean the conversation has two layers:

The technical layer: is the work maintained, understood, and good?
The ethical layer: how should we feel about tools built on potentially non-consensual training data?

Most people in that thread were debating layer 1 and she dragged me down to layer 2 into the conversation. Both are real. Neither invalidates the other.

But it also made me realize my original article didn't address why handwritten code felt different to me because honestly? it does.

The Real Tension

The argument I made: origin doesn't determine quality. Understanding, testing, maintainability, accountability, that's what matters.

My own experience reflects that. I started writing code around 2018, and back then the only AI most of us could name was Sophia, the humanoid robot from Hong Kong. I learned the traditional way: by writing everything myself. Even today, when I write code by hand, I understand it differently. More deeply. I notice edge cases I might have overlooked if I'd generated the first draft with AI. And when I'm done, I'm genuinely more proud of what I've built.

These aren't compatible statements if you think about them too hard.

Either:

My pride is just ego (origin bias)
Handwritten code actually is better (proving the gatekeepers right)
Both are true, but for reasons I didn't examine

@fromzerotoship helped me see option 3 clearly. They're not a developer but they've shipped 20+ working internal tools using AI. A hospital runs them. By my standards, they'd "fail" the understanding test, there are parts of their system they couldn't explain line-by-line.

But then they said something that shifted everything: "Demonstrable behavior under deliberate failure is another form of earning trust, and it's the only one available to me. It's also harder to fake."

Plant defects, watch the guards catch them, restore the guards and watch them go green and then deploy and check the URLs a few seconds later.

they demonstrate that they can keep it alive.

And that made me realize the real distinction wasn't about who typed the code. It was about friction.

The Friction Actually Matters

In my earlier piece I wrote a few weeks ago, I described not being able to write some logic from scratch despite reviewing it perfectly, that wasn't just skill loss. It was proof that I'd skipped the friction that builds actual understanding.

When I write code by hand, I encounter problems in real-time.

I hit a wall. My approach doesn't work. I refactor. I discover the problem space through constraint and failure. I make decisions about decisions, not just typing, but choosing between paths I've actually explored. this is the learning path that I unknowingly go through whenever I write code by hand and Wii reminded me of this.

When I use AI, I describe what I want. I get options. I pick the one that looks right. I'm curating, not exploring.

Both can produce good code. But the path to understanding is fundamentally different.

With handwritten code: friction, insight, better next decisions

With AI-assisted: selection, implementation, validation

The friction is the learning mechanism.

So when I say I'm more proud of handwritten code? I'm not being romantic about suffering. I'm noting that the code I'm proudest of is the code I fought for, and handwriting forces the fight.

But Here's the Problem With That Logic

If friction is the mechanism, then the type of friction matters more than who did the typing.

You could write AI-assisted code where you:

Fight with the prompt
Critique every generated option
Refactor aggressively
Hit walls and redesign

That has friction and it also builds understanding.

Conversely, you could hand-write code where you:

Autopilot through a familiar pattern
Never question assumptions
Copy-paste from Stack Overflow
Never understand why it works

That has no friction and it builds nothing.

So the honest version of my position isn't "handwritten code is better." It's: "friction builds understanding, and handwriting tends to create friction because you're forced to think through every line."

But that's a contingent truth, not an absolute one.

The Uncomfortable Realization

The critics ( gatekeepers, but we'll stick with this from now on ) were partially right and I was too generous in my original position.

Not about the gatekeeping itself, no, that's still wrong. But about the tendency: AI does make it easier to produce low-understanding code. Not because AI is bad, but because removing friction is literally what AI does, and friction is what builds understanding.

The answer isn't "use less AI" or "never use AI." It's "if you use AI to skip engagement with the problem, whether that's the code, the failure modes, or the maintenance, you build worse systems.

That applies to humans too but humans have an inherent friction cost, we get bored, we hate typing, we make mistakes. That friction is annoying, but it forces us to stay engaged.

So What Changed?

Nothing about the original argument was wrong. But I was treating "understanding + accountability" as if they were just checkboxes you could verify at the end.

They're not.

Understanding isn't a property you can inspect, it's a process and that process requires friction. Real engagement with the problem. Mistakes you learn from.

The reason I'm prouder of handwritten code is because I earned the understanding in a way that's harder to fake.

Does that mean every line should be handwritten? No. Boilerplate is boilerplate. Some friction is just noise.

But the core logic? The architecture decisions? The places where "understanding this code" actually matters? Yeah, I want to have fought for that.

And I want the same from anyone shipping code that matters.

The Uncomfortable Middle Ground

Here's where I land:

To the critics: You're using the wrong filter. "AI or no AI" doesn't tell you anything but you're accidentally right that there's something real to be concerned about, it's the laziness that AI enables, not the tool itself.

To AI enthusiasts: Yeah, your tooling is amazing. But it's worth asking whether you're using it to think better or think less. Those feel the same until you try to maintain the code six months later.

To myself: The pride I feel in handwritten code isn't ego, It's legitimate. every line that I typed out isn't some sort of magical unicorn mythological Godly line but it's the friction that comes with it, the learning I build that comes with it.

Sometimes the answer requires admitting you skipped and sometimes that's fine for routine work. But if you're building something that matters, you should want to have fought for it.

Choose Where You Fight

I still write a lot of code by hand. I still use AI every day. Those aren't contradictions anymore.

The original article was right: origin doesn't determine quality. What it missed is that understanding isn't a checkbox you tick at the end. It's something you earn through friction. Handwriting tends to create that friction. AI tends to remove it. Neither is inherently good or bad. Both are choices about how you engage with the problem.

So I'm not asking "Did you use AI?" anymore.

I'm asking: Did you fight for the parts that matter?

And if the tool answered that for you, you'll find out the next time something breaks.

My favorite article of the week. for someone who's where he is today by breaking things, painfully manually writing CRUD apps and having no choice but to learn how to read people's code, this hits too close to home.

Adam - The Developer ✨ — Wed, 29 Jul 2026 16:12:45 +0000

Deletes the career ladder

Nazar Boyko

Jul 27

The Junior Developer Pipeline Is Broken... And AI Broke It

#discuss #ai #career #programming

267

216

9 min read

Understanding Over Origin

Adam - The Developer ✨ — Tue, 28 Jul 2026 09:36:21 +0000

Many of developers communities are asking the wrong question.

Not because they're wrong to worry about low-effort work, no, but the filter they're using doesn't actually separate maintained engineering from generated slop. It just separates projects based on which tools were involved in their creation.

Imagine trying to share a work that you're really proud of, with the help of AI assisting it, the idea's yours but your work gets flagged, rejected, or buried under comments like "no you didn't" and "I hate how there's so many AI projects these days." Someone definitely felt righteous after saying this, believing they're protecting themselves from low-effort slop.

Except that's not actually what they're protecting against. They're protecting against a label.

The Distinction

I read @madsendev 's article regarding Open Vectorizer and Madsen wants to share the project with other people and in hope that someone would like to contribute as well.

Apparently, difference between "AI-generated" and "maintained engineering" has become invisible to gatekeepers who've simplified the filter down to a single binary question.

the wrong question.

" AI or no AI "? ( they didn't literally ask this but that's the filter in practice )

Here's why: imagine two projects.

Project A: Someone spends two years redesigning a vectorization algorithm, investigates whether machine learning could improve it, decides against it, implements a deterministic approach, discovers their own benchmark was inflated (and fixes it anyway), publishes reproducible results, and actively maintains the code.

Project B: Someone types "make me a music streaming app" into an AI prompt, publishes whatever emerges without testing it, and disappears.

Both used AI. Both are labeled "AI-generated." One belongs in a developer community. The other is exactly what communities should be filtering out.

Guess which one gets rejected? yah, both get rejected. The luckiest you can get is being rejected later because the gatekeeper was busy arguing with you and changing their community name to: " i miss what was it like to program on punch cards and a ciggy in my mouth " ahhh yes, the identity crisis.

The Problem With Using "AI-Generated" as a Quality Filter

The gatekeeping argument seems reasonable at first glance. But it has real problems:

The dismissal: "no you didn't (via @deammer). This response requires ignoring the actual technical work, but Madsen rewrote an entire algorithm pipeline, tested it against established tools, and caught a bug that made his own benchmarks look better, then published the worse numbers anyway. That's not someone slapping a prompt onto Claude and calling it a day.

The broader concern: @blakebeckcoding points out something real, unvetted AI-generated code has introduced security vulnerabilities. That's a legitimate worry about maintainability and accountability. Where the argument breaks down is treating that as sufficient reason to reject every AI-assisted project before evaluating its technical merits. The concern about low-quality code is valid. The heuristic of "reject based on tool choice" doesn't actually address it.

Think of it differently: we don't reject all Rust packages because Rust makes memory safety easier, nor do we assume all C projects are insecure because C makes memory errors possible. Language choice affects probabilities, but it doesn't determine quality. The same applies to AI.

The nostalgia play: "Dev.to used to be good" (same dude, you know who, bro's just nostalgic). There's an assumption that developer communities were higher-quality before AI tooling arrived. But humans have been publishing terrible code since the 1980s, spamming them has always been a problem and it isn't new, AI just makes it easier and cheaper to spam.

The Real Problem (And Why It Requires Actual Work)

Developer communities are being flooded and it's not the AI-generated projects specifically but low-effort projects, period. and like I said up there, the flood's rising fast at an overwhelming rate because AI made it cheaper to produce them.

The solution, though? It's not "ban the AI ones."

It's understanding what actually separates signal from noise:

Can the maintainer explain the architecture, or does it sound like they're reading stack overflow?
Are there meaningful tests?
Can claims be independently reproduced?
Are benchmarks transparent?
Are weaknesses disclosed?
Does the maintainer actually review changes and take responsibility?
Will this be maintained in six months, or is it a one-off lab experiment?

These questions work equally well for human-written code. And they're expensive to verify, they require actual reading, thinking, and judgment.

"Was AI used?" is cheap. One checkbox. Feels principled. Lets moderators move on.

"Is this maintained engineering?" requires actually engaging with the work.

The Pointed Out Irony

In the comment thread, @unitbuilds delivered the most sensible take on all of this:

"Software development is an orchestration process where the ultimate value is the working, audited, and tested software—not just human typing time."

And then:

"If that's the kind of comments you leave, go to X and join the cesspool, or Reddit, they'll love you there. Please keep Dev.to a safe space for all developers."

hits good, doesn't it? it's not defending AI in the abstract. It's defending communities staying communities, places where people can share work and get feedback, not face purity tests based on which tools they used.

The person who said they used 99% AI to ship a 3000-line game while working full-time deserves to share that. So does someone who used GitHub Copilot for routine completions. So does the Open Vectorizer author who made architectural decisions with AI assistance but wouldn't ship something they couldn't explain.

What none of them deserve is dismissal based on a label that tells you nothing about the quality of the work.

The Historical Perspective

This is something that might seem beside the point but isn't: software development has always worked this way.

We moved from assembly to C and nobody said "You didn't really code because you're using a compiler." We moved from manual memory management to garbage collection. From raw SQL to ORMs. From writing Dockerfiles by hand to templates. From Stack Overflow copy-paste to IDE refactoring to GitHub Copilot autocomplete.

Each step increased abstraction. Each step generated concern that developers were getting lazy, that standards were dropping, that the craft was being diluted.

Each time, the question that actually mattered wasn't "What abstraction level did you use?" It was "Do you understand what was generated? Can you defend it? Will you maintain it?"

That's been the real standard all along.

AI is just the next step on that continuum. It's more aggressive, more visible, and it generates more mediocre output faster. But it's not fundamentally different from any other tool that lets developers offload rote work to focus on decisions that matter.

The question isn't whether AI should be accepted.

In short, people have been saying software development is dead since the first high level programming language was invented... just, circling around the same anxiety cycle over and over.

The Good Moderation Requirements

no, it's not "open the floodgates." it's about what you're really filtering

Good moderation would:

Require disclosure of substantial AI involvement (transparency matters)
Judge projects on reproducibility, test coverage, and maintainer accountability
Fast-track projects with public benchmarks or active bug resolution
Catch obvious slop by its lack of depth, not its origin story
Create space for people who are learning while filtering out low-effort republishing

Bad moderation does what's happening now:

Blanket bans that assume all AI-assisted work is equivalent to prompt-and-publish
Dismissive comments that never engage with technical substance
Rejection based on the presence of a tool, not the absence of rigor

DEV's shift toward requiring disclosure rather than banning AI-assisted content is great. It puts the burden on the creator to be honest, then lets the community decide based on the actual work.

What Actually Matters

@unitbuilds had it right: a developer community's job is to share work and get substantive feedback, not police the method.

The questions that separate good engineering from slop are straightforward:

Can you explain the architectural decisions?
What broke, and how did you fix it?
Are benchmarks reproducible?
Will you maintain this?
Are you willing to be corrected?

They work regardless of whether code was typed by a human, generated by Claude, or mixed. Because they're about understanding and accountability - what has always determined quality.

Engineering should be evaluated on understanding, correctness, maintainability, testing, and accountability. Not keystrokes.

The World's Oldest Communication Protocol Is Music

Adam - The Developer ✨ — Fri, 24 Jul 2026 03:52:53 +0000

This is going to be a very different article from what I usually write. No technical discussions, architecture deep dives, or engineering practices today. Instead, we're talking about something much older than software itself: music.

We treat language like it's the default mode of human communication, like it's the real and only thing used to communicate, everything else is secondary, emotional, aesthetic, nice to have.

But language is actually the outlier. It's the new protocol layered on top of something much older.

Music is the original standard and we've basically forgotten how to read it.

The Protocol Stack

Think of communication like a network stack. Language is high-level. It's TCP/IP. Built on assumptions, needs learning, breaks the second you cross a boundary. You need:

A shared vocabulary
Syntactic understanding
Cultural context
Years of study if you actually want fluency

It's powerful but It's also fragile. And it's recent.

Written language is a few thousand years old. Spoken language is older, sure, but both are late abstractions compared to the hundreds of thousands of years humans have been syncing bodies to shared sound. Relative to that timeline? Language is yesterday's patch.

Music? That's the lower-level protocol. The physical layer everything else runs on.

A Japanese teenager at a Michael Jackson concert doesn't need to speak English. She doesn't need to understand what "Man in the Mirror" means as a concept. She also doesn't need a music degree.

Music isn't zero-cost. Genre, culture, convention still shape how we hear it. But the entry barrier for emotional communication is way lower. A rhythm can hit urgency, celebration, sadness, or tension long before anyone understands the formal structure behind it.

Her nervous system speaks that fluently. And so does everyone else in that stadium.

How the Protocol Works

Here's what happens when the song starts: 70,000 people stop being individuals and start being a distributed system synchronizing to the same signal.

The bass hits. Her heartbeat starts matching it. Involuntarily. Her neurons fire in sync with the guy three rows over. The girl next to her moves when the rhythm says move — not because she decided to, but because the protocol sits lower than conscious decision-making.

This isn't mystical. This isn't the "universal language of music" in the poetic sense. This is just biology.

Babies respond to rhythm before they understand words. Crowds clap together without a conductor. Soldiers march to drums. Rituals across cultures use singing and percussion to pull a group into the same tempo. The pattern shows up everywhere because the hardware is shared.

The protocol specs, if we're being nerdy about it:

Uses mostly rhythm, tempo, and frequency
Hits the nervous system, not the cognitive layer
Needs way less shared context than language
Backward compatible across human brains for 300,000+ years
Works at scale (70,000 synchronizations at once)

Language, meanwhile:

Preprocessing (learning)
Translation (if you're cross-language)
Cognitive overhead (your brain has to think)
High latency (meaning takes time)

Music? Low preprocessing. No translation step. Near-zero latency. Your body gets the signal before your mind finishes negotiating what it means.

Why We Don't See This

We're obsessed with meaning. We assume communication = transfer of semantic content. You encode an idea into words, I decode it, boom: we've connected.

So when we see that girl screaming English lyrics she doesn't understand, we quietly reframe it. "Oh, the message transcends language. She understands on a deeper level."

Nah. She's not understanding the message at all. She's on a different protocol entirely. Language is offline. The lower-level stuff is handling it.

We miss this because we've built an entire civilization on top of language. We think the higher-level protocol is the "real" one. Which is like saying TCP/IP is more real than the electrical signals it runs on.

Music isn't poetry. It isn't transcendence. It's infrastructure. It's what everything else runs on.

And no, it's not better than language. It solves a different problem. Music synchronizes systems. Language coordinates them.

A drumbeat can make people march together. It won't tell them why they're marching, what they believe, or what to do when the song ends. Language is powerful because it encodes abstractions. Music is powerful because it doesn't need to.

The Uncomfortable Part

Here's the part that gets weird: you can sync humans at massive scale without them sharing any values, beliefs, or understanding.

That stadium full of people moving together? They don't agree on anything. They might hate each other politically. They might speak no common language. They might have zero common ground.

But for three minutes, their nervous systems are linked. That's a connection. Just not the kind we like to talk about.

We want connection to require understanding. We want it to mean something. We want it to prove that underneath all our differences, we're fundamentally united in shared meaning.

What music actually shows us is simpler and weirder: humans are pattern-matching machines wired to sync with other humans. You don't need shared values for that. You don't need agreement. You don't need understanding.

You just need a rhythm everyone can feel.

What This Means

Language will always need translation and will always be high-friction, high-latency, high-failure-rate across boundaries and... that's not a bug, it's what gives it power, precision requires friction.

But for raw synchronization, getting lots of humans moving together, feeling together, breathing together, language is overkill. Also unreliable.

Music is the protocol that works when nothing else does.

An orchestra where nobody shares a language. A protest with thousands of strangers chanting. A stadium of people from different countries, different beliefs, different everything, all moving as one.

These aren't examples of music "transcending barriers." They're examples of a lower-level protocol just... working, while the higher-level ones fail.

We've built everything on top of language. We've made it the primary. And we've kind of forgotten what it's sitting on.

Language lets us share thoughts. Music lets us share states.

And every time a girl who doesn't speak English screams an English song in perfect sync with 70,000 other people, she's reminding us: the infrastructure was always there. We just stopped noticing it.

The oldest communication protocol is still the most reliable one. We just got distracted by the newer layers.

And sooooo, Here's my favorite song of the week

✨🎶 Love Hurts — Nazareth

Drop your favorite music down below, let's hear what gets your system in sync!

Stop Saying You Want Ownership Mindset

Adam - The Developer ✨ — Tue, 14 Jul 2026 05:59:52 +0000

My 2nd article this week, I'm supposed to keep it to just once per week but whateverrr, I've had this in drafts for a while now, let's get straight into it.

Here's the thing about "ownership mindset" that nobody on the management side wants to admit: you love the slogan. You hate the behavior.

You want engineers who care. Who think about scale. Who ask "wait, will this melt in four months?" Who treat the product like it's theirs.

Cool. Then someone actually does that in a meeting, and suddenly they're "being difficult," "not a team player," "too negative," or my personal favorite — "can you just build what I asked for?"

I've sat through this movie enough times that I can recite the script.

The Script

Manager / PM / whoever is currently wearing the "decider" hat:

We need someone with real ownership on this. Someone who cares whether the product actually works.

Someone raises a real concern about the architecture. Not vibes. Constraints. Data model. Failure modes. The stuff that will wake someone up at in the middle of the night later.

Same person, 90 seconds later:

Why are you pushing back so hard? Why are you being so difficult? We're already behind. Just ship it.

So which is it?

You asked for ownership. They gave you ownership. Now you're mad that ownership came with opinions.

You're Not Confused. You're Convenient.

I used to think this was a communication problem. It's not. It's incentives.

You feel the delay today. You don't feel the outage later. Design pushback slows the thing you want shipped this sprint. The mess it prevents shows up next quarter, under someone else's KPI. Of course you optimize for the pain that's in the room.

Hierarchy feels like efficiency when you're on top of it. A senior decision getting questioned doesn't feel like engineering. It feels like disrespect. Even when the question is "this will corrupt data under concurrent writes." You wanted a yes. You got a reason. Those feel different to the ego.

Compliance feels like progress. An engineer saying "yeah, I'll build it" gives you a hit of motion. An engineer saying "we should rethink the data model" feels like friction. Your brain does lazy math: less friction = better leadership. No. Less friction = quieter failure.

And "ownership" means two different things depending on who's talking. When you say it, you often mean "make sure it ships and don't bother me." When I hear it, I mean "make sure it doesn't screw us." Those conflict. You keep using the same word like that's my problem.

The Quiet Engineer Is Not Owning Anything

Here's the part that should piss you off more than it does: the engineer who just implements what you ask, every time, with a smile, is not demonstrating ownership.

They're optimizing for approval.
They're minimizing confrontation.
They're following orders.

None of that is ownership. That's liability transfer.

When it breaks, they've got the perfect line: "I built exactly what was specified." Clean hands. Diffused responsibility. You got the compliant builder you rewarded.

The person who says "this is going to bite us" is the one actually treating the outcome like theirs. They're spending social capital in a room that usually punishes that spend. If you punish them, don't act shocked when the next three people learn to shut up.

What Ownership Actually Looks Like From Our Side

It's not being a dick in design reviews. It's this:

Concerns come early. During design. Not three weeks into implementation when changing direction costs a sprint and a relationship.

Reasoning, not vibes. "This N+1 dies at 10k users on our current growth curve" beats "this feels off." If an engineer can't explain the failure mode, push back. If they can — listen.

Alternatives, not just no. "What if we index on user_id?" is ownership. "This won't work, good luck" is theater.

Knowing when to escalate vs. when to build-and-learn. Sometimes you need to ship something imperfect to learn. Sometimes you're walking into a known footgun. A good owner can tell you which meeting you're in.

Staying for the outcome. "I told you so" is not ownership. Owning it means if you were wrong, you help clean it up. If you were right and ignored, you still help clean it up — and you remember who ignored you.

What You Get When You Train That Out of People

I've watched this culture settle in. It's not subtle.

Engineers who optimize for "not getting blamed" instead of "building something that lasts"
Debt that accumulates in silence because speaking up is career-limiting
Smart people quietly updating their LinkedIn
Meltdowns that somehow still surprise leadership
"Team player" becoming code for "doesn't question bad decisions"

You buy short-term speed. You pay medium-term chaos. Then you schedule a retrospective where everyone agrees "we should have spoken up earlier," and nobody asks why they stopped.

If You Actually Want It

Stop asking for ownership like it's a personality trait. Build the conditions where it's safe to exercise.

Separate design talk from implementation talk. Let people think out loud about whether something will work before you've already committed the sprint. Thinking hard and shipping fast aren't enemies. Collapsing them into one meeting is.

Reward the pushback you say you want. If someone raised a legitimate concern and you overrode them, make that a visible decision. Don't pretend the conversation didn't happen. If they were right later, say so. Out loud. In front of people. If they were wrong, they learn the domain. Either way, the signal is: speaking up was the job.

Be specific. "Take ownership" is useless. Do you mean "ship this by Friday even if it's dirty"? Then say that. Do you mean "this has to survive 10x traffic"? Say that. Vague slogans produce people guessing what will get them yelled at least.

Listen when we push back. Not because we're always right — we're not. Because we live in the codebase you only see through tickets. That's not attitude. That's the job you hired us for.

Normalize disagreement. The best teams I've been on argue about design and still trust each other the next morning. Disagreement isn't personal. Making it personal is how you get yes-men and broken systems.

Bottom Line

You probably do want engineers with an ownership mindset.

What you don't want, and keep accidentally selecting for, is engineers who smile, implement, and let you walk into the wall so they can stay popular.

Ownership is annoying. It asks inconvenient questions. It slows the "just ship it" meeting. It makes seniors defend decisions they wanted to treat as settled.

If that sounds exhausting, good. That's the cost of building something that doesn't fall apart the second real users touch it.

You don't get "people who care" and "people who never push back." Pick one.

And if you pick compliance, at least stop calling it ownership. That word still means something to the rest of us.

I Could Review It. I Couldn’t Write It.

Adam - The Developer ✨ — Mon, 13 Jul 2026 07:52:12 +0000

...now, I pride myself on being good at my job, I'm fast at catching mistakes, I'm efficient at reviewing code and I'm quick to spot patterns across systems. But ever since I knew how to use AI ( maybe around mid 2024, I was still doing the old trad way when i started in 2018 ), I've been letting AI write ALOT of my code.

And I thought I was still learning.

Then one day I sat down to write an HTTP handler in Go from scratch, and I froze... and I can't describe how scary this was.

Not because I don't understand HTTP or because I don't know Go because I recognize these patterns instantly:

func (s *Server) handleJobNext(w http.ResponseWriter, r *http.Request) {
    // ...
}

I can review it, spot mistakes, discuss the design. But build it from scratch? I found myself thinking: "Wait... is it http.HandleFunc? ServeMux? How do I start the server?"

That's when I realized something was wrong, I realized the trap I'd fallen into and I had to do something about it.

Recognition is not Production

This biggest illusion that AI makes much easier to fall into is the thinking that goes:

"I understand this" and it feels exactly like "I can produce this."

I also wanna clarify that AI isn't the first one to inven this problem, Stack Overflow, copy-pasted frameworks and tutorials all created it first and AI's just accelarating the distance.

Recognizing a solution is just one skill. Your brain does pattern matching beautifully and way effortlessly than you think once you get used to it, you see http.HandleFunc, think "yep, that's how you register routes," and feel confident.But try retriving that knowledge from scratch, constructing it... that's a whole other level, those are completely different neural pathways because the ability to review code, design & architecture aren't the same as writing it from memory and it should never be mistaken.

I got really good at reviewing, too good I guess, I am fast & efficient, I could critique architecture, spot edge cases, ask the right questions and basically start a whole drunken bar vibe conversation with it but you know what scares me despite being able to do all of this? I couldn't write an HTTP handler from memory.

I WAS practicing some skills. just some. just not the ones I thought.

The Gap and I Started A Series

There's also a dangerous confidence trap here: convincing yourself you're still learning because you're the "architect" or "reviewer", you're making decisions, you understand the system.

But how would you feel if knowing you can't write what the AI wrote, not without looking. that's the gap.

Anyway, a few months ago, I started writing distributed systems algorithms in Go from scratch, each algorithm belonging to their own repo. No AI. I write entirely, then ask it to review and I tell you it's very rewarding!

I am doing the series for 2 reasons:

This will help me strengthen my skill in Go, I love Go but it's also the least used language of mine too but a very important one.
I hope to help others understand algorithms in distributed systems where it's written with as much as simplicity as I could but also not leaving out edge cases and failure modes. Many developers work with one unknowingly and wonder why their simple code causes data corruption as soon as someone adds another instance of the backend.

I will be releasing the article one by one each after I'm done where I will document every hell and tasmanian devil I would've had gone through, no filters with the exception of bad languages.

You Can't Download Experience

Great software doesn't come from perfect code, It comes from surviving bad code.

Engineering intuition is built from mistakes, failed designs, debugging at 2 AM, edge cases that shouldn't exist, trade-offs that haunt you for years. The final code is just the artifact. The scar tissue is the education.

Take a system like PostgreSQL represents decades of accumulated engineering decisions.

I'm picking on Postgres specifically because I saw someone tried to rewrite Postgres with Rust nearly entirely with agents. It's not a bad thing, in fact, it's improving Postgres tremendously: with Rust, it's moving from the historic process-per-connection to thread-per-connection, massive performance gain and some of the long-standing postgres pain points.

You can rewrite it. You can reproduce the behavior. But you won't reproduce the journey that created that understanding—the bugs fixed, the performance lessons learned, the constraints that forced particular designs.

Letting an agent write everything and you get the artifact without the scar tissue.

And expertise lives in the scar tissue.

The Real Principle

The skills you practice will grow. The skills you outsource will weaken.

I outsourced writing and my writing muscle atrophied. I got better at reviewing and architecture, but lost something important.

Now I'm deliberate: distributed systems algorithms in Go, I write. from scratch.

Not because I am better than AI but because I'm choosing which muscles to exercise and the choice matters.

What I'm Not Saying

AI is not bad. I use it daily. Heck, I still use it for work because businesses' deadlines now are unrealistic standards compared to what they were a few years ago.
Code review is still critical work.
AI is still my thinking partner and my force multiplier, I still consult it from time to time when making decisions, it builds me up and makes me a better developer and I make decisions faster because I'm not the only one thinking when no one's around.

What I'm saying is: Be intentional about which parts of expertise you allow to change.

Every tool reshapes what engineers need to know. The goal isn't to preserve manual typing forever. The goal is to ensure that the parts of engineering you want to own are still exercised by you.

If you want to stay sharp at writing, you have to pick code you're not going to outsource.

Because expertise follows exercise. Always.

The question isn't whether you can write without AI.

The question is: Will you?

You Never Eliminate a Bottleneck — You Just Move It

Adam - The Developer ✨ — Mon, 06 Jul 2026 09:59:27 +0000

I once spent quite some time optimizing a database query that was bringing our API to its knees. We shaved 200ms off response time with careful indexing and query rewriting. Success, right?

Wrong.

Within a week, a different bottleneck surfaced. The network became the constraint. We optimized that. Then client-side rendering became slow. Then memory usage spiked. Each "fix" just moved the problem downstream.

Eventually, I learned something that changed how I approach performance work: bottlenecks aren't anomalies to eliminate, they're laws of nature baked into how systems work.

Why Bottlenecks Are Inevitable

The Theory of Constraints

Every system has a weakest link. Think of water flowing through a pipeline, the narrowest section determines your throughput, no matter how wide the rest of the pipe is.

Software systems work the same way. At any given moment, something is the binding constraint:

Is it the CPU?
The database?
Network latency?
Disk I/O?
Memory?

When you optimize that constraint, you don't eliminate constraints altogether. The constraint simply moves to the next-slowest component. The system's total throughput increases, but a new bottleneck emerges.

Amdahl's Law: The Math That Proves It

Even with infinite parallelization, there's a mathematical ceiling. Amdahl's Law tells us:

If just 10% of your code runs sequentially, you can never speed up more than 10x—no matter if you have 1,000 CPUs. That sequential 10% becomes an eternal bottleneck.

For our social media app, some processes must happen in order:

Authenticate user
Fetch permissions
Then fetch feed

You can't parallelize that without breaking safety. So authentication becomes a permanent bottleneck, though a small one.

The Great Trade-Off Game

Here's the dirty secret: optimizing for one thing almost always hurts something else. You're not solving problems; you're choosing which constraint to live with.

Optimize For	What Improves	What Gets Worse
Latency	Fast responses	CPU/memory usage spikes
Throughput	More requests/sec	Resource exhaustion
Cost	Cheaper infrastructure	Performance degrades
Consistency	Strong guarantees	Write latency increases
Availability	Always online	Coordination overhead explodes

Pick one. You're implicitly de-prioritizing others.

Example: The Classic API Scaling

Let's say I worked on an API that handled 10 requests/second. Bottleneck? The database.

We added caching.

Now: 100 requests/second. Bottleneck? Memory, our cache grew too big.

We sharded the cache.

Now: 500 requests/second. Bottleneck? Network bandwidth between nodes.

We optimized serialization.

Now: 1,000 requests/second. Bottleneck? Client-side parsing of responses.

We gzipped responses.

Now: 2,000 requests/second. Bottleneck? The upstream service that feeds our API.

At each step, we "solved" the problem. But we never eliminated bottlenecks—we choreographed a dance, moving them from place to place.

Distributed Systems Make It Worse

In a distributed system, bottlenecks hide in shadows and move in unpredictable ways:

Network RTT (round-trip time) is a physical law. You can't send data faster than light travels. For a global system, that's roughly 50-150ms of minimum latency per hop. Every extra network call multiplies this cost.

Leader election is expensive. When a leader fails in your distributed system, electing a new one takes time. During that window, writes are blocked. The leader election itself becomes the bottleneck.

Quorum writes create coordination overhead. To ensure consistency across replicas, you need a quorum (majority) to acknowledge a write. That coordination, waiting for responses from multiple nodes, is itself a bottleneck that throttles your write throughput.

Hot partitions kill performance. If all your traffic hits one partition (shard) of data, that partition becomes the bottleneck. You optimized everywhere else, but one hot partition brings the whole system down.

Cross-region latency compounds. Replicate data to multiple regions for resilience? Now reads and writes must cross regions. A single cross-region call might be 100ms. Add three of them together? You've hit a bottleneck that optimization can't touch.

Fan-out requests multiply latency. Your service calls 10 microservices in parallel. The slowest one determines your response time. You optimize 9 of them, but the 10th — now that's your bottleneck.

There is no way around these trade-offs. They're mathematical, physical. Bottlenecks in distributed systems aren't bugs, they're features of reality.

The Practical Mindset Shift

The question shouldn't be: "How do I eliminate bottlenecks?"

It should be: "Which bottleneck am I willing to live with, and how do I make sure it's the right one?"

Actionable practices:

1. Profile first, optimize later
Use a profiler. Find the actual bottleneck, not the one you think exists. 90% of optimization effort goes to wrong places because developers guess.

2. Optimize strategically
Focus on the binding constraint. Optimizing something that's 5% of your runtime is pointless if the database is 80% of your runtime.

3. Plan for the next bottleneck
When you fix something, ask: "What becomes slow now?" You can't prevent it, but you can prepare.

4. Make trade-offs consciously
Don't accidentally sacrifice something important. If you add aggressive caching, you're choosing performance over freshness. Make sure that's actually what you want.

5. Accept limits gracefully
Some bottlenecks are laws of physics (network latency, disk I/O). Design around them instead of fighting them. Use caching for latency. Use batching for throughput.

The Bottom Line

Some of the best engineers I know aren't the ones who "eliminate" bottlenecks. They're the ones who:

Understand where bottlenecks live
Move them strategically
Stay ahead of the game by anticipating the next constraint
Optimize for what actually matters (user experience, cost, reliability)

Your job isn't to break the laws of systems theory. It's to work within them intelligently.

The bottleneck never disappears. You just get better at dancing around it.

The Illusion of the Clean Slate

Adam - The Developer ✨ — Tue, 30 Jun 2026 06:28:20 +0000

Every engineer has fantasized about it: starting over. Throwing out the old system and building something clean. No legacy constraints. No accumulated compromises. Just pure, intentional design.

It never works that way.

You can delete all the code. You can architect from scratch. You can make the best technical decisions possible. But you can't delete the organizational memory. You can't unlearn what the last system taught you. You can't escape the patterns that already run through the business, the workflows people have shaped themselves around, the problems you've already paid the cost of understanding.

The new system will look clean. But it will be haunted.

What rewrites actually inherit

A rewrite isn't a fresh start. It's archaeology pretending to be innovation.

The constraints don't go away. The old system wasn't overcomplicated because engineers were bad. It was overcomplicated because of customer requirements, regulatory expectations, performance demands, and edge cases that took years to discover. A fresh rewrite finds all those edge cases again. Slower this time, because you don't have documentation—you have broken customers and escalations. The system gets layers of protection again, but now it looks like paranoia instead of learned caution.

The organizational memory becomes invisible. Someone fought for that data model three years ago. There was a reason. A business rule that couldn't be violated. A data consistency requirement that cost a quarter to figure out. The new system doesn't have the battle scars that explain why things are the way they are. So they get rebuilt differently, until they hit the same requirement at 2am on a Saturday.

The workflow is already baked in. Users have shaped their behavior around the old system. Sales has built their pitch around certain capabilities. Support has written documentation and runbooks. Customers have automation that depends on specific behaviors. The new system is technically cleaner, but it forces change on everyone else first. The rewrite isn't done until the new system works like the old one.

The code patterns stick around. Teams find themselves solving the same problems the same ways. Not because the architecture forces it, but because it's familiar. Because there's institutional knowledge about how to do X in a way that doesn't break. Because someone senior knows the pitfalls. The "clean" codebase starts looking like the old one within six months, just with better error handling.

The ghost of the old system

sometimes the best decision in a rewrite is to do it exactly like the previous system.

Not because the old code was good. But because a lot of people understand it. The business logic is tested by production. The failure modes are known. The performance characteristics are predictable. Starting fresh means starting ignorant, and ignorance costs money.

A truly clean slate would require starting ignorant and willing to pay the cost of ignorance. Most organizations can't afford that. So the rewrite becomes "the old thing, but better implemented"—which is fine, maybe even better, but it's not what anyone was imagining when they said "let's start over."

The ghost isn't a bad thing. It's just unavoidable. Organizations have memory whether they codify it or not. That memory shapes everything built inside them, even when you're trying to escape it.

Why this matters

Understanding this changes how you approach a rewrite. You're not escaping the past. You're translating it.

The best rewrites don't pretend to be clean slates. They acknowledge what they're inheriting. They talk to users about why the old system worked the way it did. They preserve the tacit knowledge that's been learned the hard way. They choose: what patterns do we keep because they're actually good, versus what patterns do we change because we have time to do it right.

The worst rewrites assume they're smarter than everyone who came before. They rebuild against the patterns of the old system instead of with understanding of them. They rediscover the same edge cases as new bugs instead of as features. They become legacy before they're finished.

A rewrite isn't a clean slate. It's a translation. And translation is hard because you have to understand both languages, the constraints of the old world and the possibilities of the new one. You have to honor what worked without being trapped by it.

The fantasy of the clean slate is tempting because it promises escape. But the only way to actually learn something is to carry it forward, consciously, even when you're trying to leave it behind.

Conduit: The Gateway I Built to Forget About

Adam - The Developer ✨ — Wed, 24 Jun 2026 07:37:59 +0000

I've been trying to keep my publishing schedule to one article a week, but this one felt too special to wait so I had Claude helping me generate a portion of this so I can publish it quick.

The article today might be a little boring depending on how much you're into systems and distributed architecture. And if you're already thinking, "Great, another API gateway," I can't really blame you.

But bear with me for a bit: Conduit isn't just another request-forwarding proxy. Along the way, we'll dive into programmable gateways, sandboxed runtimes, Unix sockets, and some of the engineering decisions that made building it surprisingly fun.

TL;DR

Built a small Go API gateway in front of three services with two different auth schemes (custom HMAC sessions, and JWT).
It worked. It also became unmaintainable: every routing exception meant editing Go and redeploying.
Rewrote it as Conduit: Go stays on the network path (routing, proxying, CORS, SSRF guards). A sandboxed Deno runtime runs policy as plain TypeScript plugins, talking to Go over a Unix socket with a strict snapshot-and-patch protocol.
Net result: auth, logging, and routing rules became files I could edit and save, no recompiling the gateway.
Full FAQ/defense-of-design-decisions Q&A is here, not in this post.

The setup

Three services, one public API:

chat-service: real-time messaging
user-service: profiles, sessions, identity
admin-service: internal tooling, elevated operations

User and chat traffic ran a custom session + HMAC scheme: Authorization: Session <id>, signed with X-Signature, X-Timestamp, X-Nonce, backed by Redis for sessions and replay protection. Not JWT. Not OAuth. Something built and iterated on for months.

Admin traffic was JWT, verified at the edge, then forwarded with trusted X-Gateway-Admin-* headers so the admin service skipped re-validation.

Different trust models. Different header shapes. Different public-path exceptions. All of it had to land on one hostname, because clients don't care how many services you run behind it.

So I built the obvious thing: a small Go gateway. Service-prefixed paths picked the upstream. A route.Select() function picked the auth mode. A growing stack of prefix conditionals decided which paths were public:

/admin-service/*  → admin upstream   + JWT (except login, refresh, external-api)
/user-service/*   → user upstream    + HMAC (except auth, device, internal, …)
/chat-service/*   → chat upstream    + HMAC for users, JWT for /api/v1/admin/*

It shipped. It worked. It was ugly.

Where the ugliness actually lived

Not in reliability. Requests hit the right upstream, JWT/HMAC validation worked, sessions slid TTL correctly. The ugliness was in extensibility:

res := route.Select(r.URL.Path)
proxy := proxies[res.Backend]
h, ok := applyAuth(w, res.Auth, cfg, sessionStore, nonceStore, proxy)
h.ServeHTTP(w, r)

Clean on paper. But adminAuth(), userAuth(), and chatAuth() were each a wall of strings.HasPrefix branches, each one carrying tribal knowledge about which paths were exceptions. Every new public-path exception meant editing Go and redeploying the gateway. Figuring out why a path behaved a certain way meant reading three functions and cross-referencing a README the size of a small service.

I wasn't failing at microservices. I was failing at boundary discipline: policy had nowhere clean to live except deeper inside the gateway's Go source.

Every new exception made the gateway more specific instead of more general.

That gateway didn't get thrown away. It proved the routing model was right. It just proved the implementation model needed to change. That became Conduit.

Design goals (the actual constraints, not aspirations)

1. Freedom of implementation. If you can write TypeScript, you can extend the gateway. No DSL, no Lua config, no plugin marketplace format: drop a file in ./plugins, export an object with lifecycle hooks:

import type { GatewayContext } from "../runtime/shared/types.ts";

export default {
  beforeRequest(ctx: GatewayContext): void {
    if (!ctx.request?.headers?.Authorization) {
      ctx.reject!(401, "missing token");
    }
  },
};

2. Low operational overhead. No control plane, no Kubernetes requirement, no sidecar ceremony. Default setup is one Go binary supervising a Deno runtime, reading a JSON config:

go run ./cmd/conduit -config conduit.config.json

3. Explicit separation of concerns.

Layer	Responsibility
Go gateway	HTTP ingress, routing, upstream proxying, CORS, body limits, timeouts, SSRF guards
Deno runtime	Sandboxed plugin execution in a warm worker pool
Plugins	Business policy: auth, logging, transforms, route control

Go never gets to know about plugin internals. The runtime never owns routing. Plugins never touch the network boundary directly. These invariants are written down because violating them produces cross-language bugs that tests don't reliably catch.

4. Predictable failure modes. A misbehaving plugin shouldn't take down the gateway. Hook timeouts log and continue. Worker crashes replace the isolate, not the process. If the entire runtime is unreachable, failPolicy decides: closed (503, no proxy) or open (skip plugins, proxy anyway), configurable per route.

5. Invisible in production. The bar I actually cared about: deploy a plugin when policy changes, glance at structured logs when something's off, otherwise forget the thing exists.

Architecture: two processes, one socket

Per request:

Client hits the Go gateway.
CORS preflight (OPTIONS) is answered in Go; plugins never see it.
Go builds a serializable context snapshot from the request.
Every plugin's beforeRequest hook runs, in filename order.
Go proxies once to the matched (or plugin-selected) upstream.
The upstream response gets attached to context.
Every plugin's afterResponse hook runs, same order.
Go writes the response to the client.

Upstream services have zero awareness Conduit exists: no SDK, no self-registration. Multi-service routing is config, not code:

{
  "routes": [
    { "path": "/user-service/*",  "upstream": "http://user-service:2001" },
    { "path": "/admin-service/*", "upstream": "http://admin-service:2002" },
    { "path": "/chat-service/*",  "upstream": "http://chat-service:2003" }
  ]
}

One plugin chain, many backends, policy applied uniformly at the edge.

The actual hard part: getting context across the process boundary

The real problem with the first gateway wasn't routing logic. It was where state lived. Mutable request objects passed through middleware created hidden coupling, and that gets worse the moment you're crossing a process boundary: you cannot hand Deno a live http.Request and hope for the best.

Conduit's contract:

Go snapshots the request into serializable JSON.
The snapshot crosses a length-prefixed frame over a Unix socket to Deno.
The plugin operates on a cloned, hook-local context with a frozen inbound request.
The plugin returns a patch: a minimal delta, not a mutated object.

Why patch instead of full context on return: sending the complete context back from every hook means re-serializing headers, identity, and potentially large bodies, twice per request, per plugin. The patch engine instead sends only what changed: omitted fields are unchanged, present fields overwrite, null tombstones a deletion. A logging plugin that sets one state field ships a few dozen bytes back, not the whole request graph.

Why bodies never fully cross the wire: anything above 64 KiB stays in a per-request BodyStore in Go. Plugins get a stream:// reference token, not raw bytes. Megabytes stay in Go; metadata crosses the socket.

Plugins don't own the request. They propose changes to it.

That sentence is the whole design. Reject/forward signals, the patch diffing rules, the frozen snapshot: all of it exists to make "propose, don't own" safe and cheap.

The plugin model

Plugins stay deliberately small:

Hook	When
`onLoad`	Once at startup
`beforeRequest`	Before upstream proxying
`afterResponse`	After upstream response is captured
`onError`	When a hook in this plugin throws unexpectedly

ctx.reject() is intentional control flow, not an error; onError is for actual surprises.

Plugins load in filename order, full stop:

plugins/
  001-auth.ts           ← runs first
  002-logging.ts        ← sees ctx.user from auth
  003-header-rewrite.ts
  004-route-control.ts

No dependency graph, no hidden priority system. 001-auth.ts runs before 002-logging.ts because of the filename, and that's grep-able at 3am.

The ctx surface is narrow on purpose:

Member	Role
`ctx.request`	Read-only inbound snapshot
`ctx.response`	Outbound builder (`setStatus`, `setHeader`, `setBody`)
`ctx.user`	Identity set by auth plugins
`ctx.state`	Per-request key/value bag shared across hooks
`ctx.log`	Structured logging with trace correlation
`ctx.reject(status, msg)`	Stop pipeline, return HTTP error
`ctx.forward(url)`	Proxy to an alternate upstream (validated by the gateway)
`ctx.services`	Optional `http` and `cache` helpers

No global singletons, no ambient mutable request object. Auth sets ctx.user; logging reads it. That's the entire coordination contract.

What happened when I actually ran it

The first deployment was personal: three services behind one port, HMAC checks in one plugin file, JWT checks in another, logging in a third. The prefix-matching spaghetti became three files I could read top to bottom.

Then it spread quietly: internal tools needing a stable hostname, admin surfaces needing stricter gating, experimental routes I could add without redeploying backends.

The moment I knew it worked wasn't a benchmark. It was forgetting it was running, then stopping the Docker container to debug something unrelated and watching everything break. That's the success criterion I actually cared about: not feature parity with Kong, invisibility under normal operation.

Failure modes, stated plainly

Event	Behavior
Plugin hook exceeds timeout (default 100ms)	Warning logged; request continues proxying
Plugin worker crashes	Isolate replaced; gateway process survives
Entire Deno runtime unavailable	`failPolicy: "closed"` → 503; `"open"` → proxy without plugins
`ctx.reject(401)`	Pipeline stops; remaining hooks skipped
Invalid `ctx.forward()` target	Logged, ignored; original route used
Upstream failure	Standard `502` propagated

Hook timeout and runtime death are different failure classes on purpose. A slow logger shouldn't look like a dead security layer.

The riskiest failure mode isn't a crash, though. It's silent semantic change: a plugin that mis-sets ctx.user or swallows a header keeps the system at 200 OK while behavior quietly drifts underneath it. That's why every log line carries [trace:<id>], and why reject and thrown errors are treated as distinct signals.

What it's not

Not Envoy: no xDS, no WASM filter ecosystem at scale.
Not Kong: no admin UI, no plugin marketplace.
Not a service mesh.
Not for multi-gigabyte streaming responses. afterResponse buffers the body so plugins can inspect/rewrite it, which costs memory proportional to response size.

What it gains in exchange: a codebase readable in an afternoon, plugins you edit and save instead of recompile, no cloud dependency to define policy, and bounded IPC cost (one warm Unix socket, patches instead of full payloads, body references instead of raw bytes).

It's lean, not free. Four plugins across two phases is up to eight round trips per request. Sub-millisecond on a local socket. Wrong tool if you need per-byte stream processing at scale; right tool if you've got a handful of services, evolving edge policy, and a team that already writes TypeScript.

What stuck

Abstraction is only good if it disappears in daily use. The pieces that survived are the ones I stopped thinking about. The pieces that died were baked into Go: the adminAuth()/userAuth()/chatAuth() prefix ladders that worked fine until they needed to change without a redeploy.
Cross-process plugin systems are viable if state transfer is strict. Patches, body references, frozen snapshots. Not optimization trivia; the actual precondition for Go and Deno cooperating without shared-memory bugs.
Failure design shaped operability more than any plugin API did. failPolicy, hook timeouts, and the reject/onError split mattered more than feature count.
"Simple" means boundary discipline, not low line count. Go owns the network. Deno owns execution. Plugins own policy proposals. Upstream owns business logic. Nobody reaches across.

Closing

This wasn't built to be a product. It was a response to a system that stopped fitting in my head: three services, two auth models, one endpoint, and a gateway that grew a new strings.HasPrefix branch every time something shipped.

The goal was never to out-build Envoy or Kong. It was to build something I could forget existed until the day I needed to reason about it. At that point, reasoning about it should be easy: read the plugin files, read the config, follow one request through Go → IPC → Deno → upstream → back.

If you're standing where I was (auth diverging, routing logic leaking into every handler), you might not need another service. You might need a place where policy can live without infecting everything else.

Try it:

go run ./cmd/conduit -config conduit.config.json

export default {
  beforeRequest(ctx) { /* policy */ },
  afterResponse(ctx) { /* transforms */ },
};

Full design-decision Q&A (why Deno over Node/Lua/WASM, scaling, "when is this the wrong choice," etc.) is in my site, not here.

Thanks to Claude for helping with my wording, grammars...etc and it also added its own intro at the very top. I was so excited to share Conduit that I forgot to review it added a very LLM-generic intro for me that just got me flagged by Sloan.

When Software Started Writing Software: A Developer’s History of AI

Adam - The Developer ✨ — Mon, 22 Jun 2026 08:06:29 +0000

If you've shipped software in the last three years, you've probably watched your job description quietly rewrite itself. You went from writing code, to writing code with an autocomplete, to writing code with a collaborator, to increasingly writing a spec and watching an agent write, test, and ship the code for you.

That didn't happen overnight. It's the latest chapter in a 70-year story that started with researchers trying to teach machines to play checkers. Let's walk through it, not as a dry timeline, but as the story of how "intelligence" kept getting redefined every time machines got good at the last definition.

1. The Symbolic Era: Intelligence as Logic (1950s–1980s)
2. Statistics Quietly Eats Symbols (1990s–2000s)
3. Deep Learning Breaks the Ceiling (2012–2017)
4. The Transformer and the Birth of "General-ish" Intelligence (2017–2022)
5. From Chatbot to Coworker: The Agentic Turn (2023–Today)
So What Changed, Really?

1. The Symbolic Era: Intelligence as Logic (1950s–1980s)

The founding bet of AI, made official at the 1956 Dartmouth Workshop, was simple and audacious: thought is computation. If you could represent knowledge as symbols and rules, and manipulate those symbols correctly, you'd get intelligence.

This gave us:

Logic Theorist (1956): proved mathematical theorems by searching through logical statements.
ELIZA (1966): pattern-matched your sentences back at you and convinced people it understood them. The first chatbot, and the first time humans projected understanding onto a system that had none.
Expert systems (1970s–80s): programs like MYCIN encoded a domain expert's rules as IF-THEN statements. MYCIN could diagnose bacterial infections about as well as a human specialist, using a few hundred hand-written rules.

This was weak, narrow intelligence in the most literal sense: a system that was a genius in one box and knew nothing outside it. The fatal flaw was scale, every rule had to be written by hand by a human expert. Knowledge didn't generalize, and it didn't learn from data. When funding agencies realized these systems couldn't handle the messiness of the real world, the money dried up. This was the first AI winter.

2. Statistics Quietly Eats Symbols (1990s–2000s)

While "AI" was a dirty word in grant applications, a different idea was gaining ground: instead of telling a machine the rules, show it examples and let it find the rules itself.

Neural networks had existed since the 1950s (the perceptron) but were widely written off after Minsky and Papert detailed their mathematical limits in Perceptrons (1969).
Backpropagation, popularized in 1986, gave multi-layer networks a real way to learn and yet networks still mostly lost to simpler methods for another two decades. The algorithm existing wasn't enough; there wasn't enough labeled data or compute to let it show what it could do. It sat half-revived, a promising idea nobody could afford to run at scale.
Support Vector Machines, decision trees, and Bayesian methods dominated practical machine learning, spam filters, recommendation engines, fraud detection.
IBM's Deep Blue beat Garry Kasparov in 1997, but largely through brute-force search over chess positions, not learning. Still narrow, still impressive.

This era's intelligence was statistical rather than logical: pattern recognition over labeled data. It worked well on narrow, well-defined tasks but needed mountains of hand-labeled examples and feature engineering done by humans. The "intelligence" was still mostly in the human designing the features the model was just fitting a curve.

3. Deep Learning Breaks the Ceiling (2012–2017)

The ingredients for the next leap had been sitting around for a decade: more data (the internet), more compute (GPUs originally built for video games), and algorithmic tricks for training deeper networks without them collapsing into noise. None of this looked inevitable at the time. Most of the field had moved on from neural networks; deep nets were a fringe bet kept alive by a small number of labs who kept getting told they were wasting their careers.

The spark was AlexNet (2012), a deep convolutional neural network that crushed the ImageNet image-classification competition, slashing the error rate compared to the next-best approach. That one result told the field something important: stack enough layers, feed them enough data, and the network finds its own features, no human feature engineering required. It wasn't a smooth continuation of the field's direction; it was closer to a coup. Within a couple of years, techniques that had been a punchline became the default starting point for almost every computer vision paper.

What followed was a five-year sprint:

Word2Vec (2013) / GloVe (2014): words became vectors, and "meaning" became something you could do arithmetic on.
Generative Adversarial Networks (2014): two networks competing, one generating fakes, one detecting them, together learning to produce eerily convincing images.
AlphaGo (2016): beat the world's best Go player (the board game, not go run main.go energy) using deep learning plus reinforcement learning plus tree search, on a game once thought too intuitive for machines.

Each of these was still task-bound, a vision model couldn't write a sentence, a Go-playing model couldn't recognize a cat — but the skill inside each one was no longer handed to it by a human; the model discovered its own representation of the problem. That shift in mechanism, more than any single result, is what made the next jump possible.

4. The Transformer and the Birth of "General-ish" Intelligence (2017–2022)

In 2017, a Google paper titled "Attention Is All You Need" introduced the transformer architecture. Instead of processing text sequentially like older recurrent networks, transformers let every word attend to every other word at once. It was a better way to model sequences and it turned out to scale beautifully.

That architectural choice, combined with the realization that you could pretrain a single giant model on a huge slice of the internet and then adapt it to almost any language task, produced the GPT lineage:

GPT (2018) → GPT-2 (2019) → GPT-3 (2020): each generation showed that scaling up parameters and data kept producing qualitatively new abilities, not just marginal accuracy gains. GPT-3 could write code, translate, summarize, and hold a conversation, despite never being explicitly trained to do any of those things.
Instruction tuning and RLHF (2021–2022): raw language models predict the next token; they don't inherently want to be helpful. Techniques like reinforcement learning from human feedback turned raw next-token predictors into assistants that follow instructions and refuse harmful ones.
ChatGPT (November 2022): Sam Altman announced it on X with the energy of a minor release: "today we launched ChatGPT. try talking with it here." Understated copy for the moment the old era ended and a new history began. Research left the lab; your non-technical relatives showed up. A hundred million users in two months. The Turing Test stopped being a thought experiment and became something people ran into accidentally over breakfast.

This is the point where AI stopped meaning "deep in one box, blank everywhere else" and started meaning compositional: a single set of weights that could combine skills it was never explicitly trained to combine. One model could write a sonnet, debug Python, and explain the sonnet's meter not because it was three different systems, but because language turned out to be a surprisingly good universal interface to a huge range of human tasks.

5. From Chatbot to Coworker: The Agentic Turn (2023–Today)

A language model that just answers questions is a powerful autocomplete. The next phase of the story is about giving that model hands: the ability to call tools, write and execute code, browse the web, remember state across steps, and chain its own reasoning into multi-step plans.

A few threads converged here:

Tool use / function calling let models stop just describing actions and start taking them, querying a database, hitting an API, running a calculation, instead of guessing at the answer.
Retrieval-augmented generation (RAG) gave models access to information beyond their training data, grounding answers in real documents instead of frozen memory.
Chain-of-thought and reasoning models showed that letting a model "think out loud" before answering and eventually training it specifically to reason longer on hard problems, produced dramatically better results on math, logic, and multi-step planning.
Agentic frameworks stitched these into loops: plan → act → observe → revise. Wrapped in orchestration code, retry logic, and well-designed tools, a model could chase a goal across many steps instead of answering once and stopping. Left alone long enough, it still drifts or takes wrong turns, the scaffolding exists to catch that. "Agent" describes a system, not a self-sufficient mind.
Multi-agent orchestration: models that spin up other model instances to parallelize work, each with a narrower role, then combine results. The specialist of the symbolic era is back, except now it's a transformer playing a role inside a swarm coordinated by another transformer, instead of a human-written rule.

This is the world a developer in 2026 actually lives in. Code isn't just suggested line-by-line; it's planned, written across multiple files, tested, and debugged in a loop that needs less hands-on steering than it used to, though still real review, real guardrails, and real human judgment about when to trust the output. The same pattern shows up outside coding: research agents that browse, synthesize, and cite sources across dozens of pages; operations agents that read a ticket, check a calendar, and draft a response; design agents that take a brief and return a working prototype. None of this is autonomy in the strong sense yet. It's interactive capability, a model in a loop with tools and a feedback signal — and it's powerful precisely because of how tightly that loop is engineered, not in spite of it.

Easy to miss when you're staring at capability charts: every jump here was also an economics story. Expert systems died because expert time didn't scale. Statistical ML rode cheap labeled data and storage. Deep learning rode gaming GPUs. LLMs rode internet-scale data and transformer parallelism. Agents are having their moment because inference got cheap enough to run a model in a loop hundreds of times per task without laughing. The recurring question isn't "can we build it?" but it's "can we afford to run it enough times to be useful?" That bottleneck moved; it didn't disappear.

So What Changed, Really?

If you zoom out, the history of AI is a story about where the intelligence lives:

Era	Where the "smarts" lived
Symbolic AI	In rules a human expert wrote by hand
Statistical ML	In features a human engineer chose
Deep learning	In representations the model learned itself
Large language models	In patterns learned from most of the public internet
Agentic systems	In the model's own planning, tool use, and self-correction across time

Each era didn't replace the last so much as absorb it. Today's agents still do statistical pattern matching under the hood; they still occasionally fail in the brittle, overconfident ways the old expert systems did, just less often and less predictably.

If you compress the five eras above, there are really only three discontinuities that mattered:

Hand-coded intelligence: rules a human wrote (symbolic AI).
Learned representations: patterns a model found in data, with steadily less human-chosen structure (statistical ML → deep learning → LLMs).
Interactive systems: models that act, observe consequences, and revise, instead of just outputting a single answer (agents).

The five-era version tells a better story; the three-version compression is what actually changed underneath.

Shift one: who writes the rules — human or data.
Shift two: passive answer vs. active loop. Most of "AI got so much better" traces to one of those.

This isn't a straight march toward AGI. It's researchers repeatedly asking "what if the machine decided this part?" and finding that worked, once the economics finally allowed it.

Whether the next chapter is "agents that reliably run entire businesses" or "another winter while the hype outpaces the engineering" is genuinely an open question and depending on who you ask, both are already happening at once.

There Is No Perfect Solution in Software Development: Every Decision is a Tradeoff

Adam - The Developer ✨ — Mon, 15 Jun 2026 06:22:48 +0000

Most bad decisions in software engineering aren't made because the engineer chose wrong between two clear options. They're made because the engineer didn't realize they were making a choice at all.

You optimized for readability without noticing that particular loop runs a million times per second. You built for perfect flexibility without realizing you'd never actually need it. You shipped fast and acknowledged the technical debt—until the debt became someone else's problem, and by then it was too late to refactor.

The pattern: teams usually aren't choosing between two good options. They're choosing between one safe default and one speculative optimization, and calling it a tradeoff to feel better about it.

What Every Engineer Needs to Know About Tradeoffs
Classic Tradeoffs You'll Face
- Performance vs. Readability
- Flexibility vs. Simplicity
- Speed to Market vs. Technical Debt
- Scalability vs. Cost
- Security vs. Convenience
- The CAP Theorem: What It Actually Means
The Pattern: How Good Decisions Actually Get Made
How to Make Better Tradeoff Decisions
The Mark of Experience

What Every Engineer Needs to Know About Tradeoffs

There is no perfect solution. Every architecture, every algorithm, every design decision buys you something at the cost of something else. This isn't pessimism, it's the foundation of good engineering judgment.

But here's the catch: not all tradeoffs are 50/50. In practice, experienced engineers often default heavily one way and only deviate with evidence.

Classic Tradeoffs You'll Face

Performance vs. Readability

Here's what usually wins: readability. Unless you have a proven bottleneck backed by profiling data, optimize for clarity.

// Faster but harder to maintain
function processData(source: number[], offset: number, length: number): number[] {
  const result = new Array(length);
  for (let i = 0; i < length; i++) {
    result[i] = source[i + offset];
  }
  return result;
}

// Slower but immediately clear
function processData(source: number[], offset: number, length: number): number[] {
  return source
    .slice(offset, offset + length)
    .filter(x => x > 0)
    .map(x => x * 2);
}

The second version is probably fine. Premature optimization is still the root of all evil. The first example should only exist if:

you've profiled
you found this function is actually slow
you've measured that the optimization makes a meaningful difference

All three conditions are rarer than you'd think.

Flexibility vs. Simplicity

"Flexibility" often looks like smart future-proofing until you realize you'll never actually need it.

You build a generic plugin system because "we might need it." You abstract everything into interfaces because "we'll probably want to swap implementations." You create configuration options for scenarios that never materialize. Meanwhile, your simple code that handles exactly one thing is getting buried under layers of generality.

Ship the simple thing. If you actually need multiple use cases later, refactoring from concrete to generic is almost always easier than refactoring from over-engineered to usable. The exception: if you're building a library or platform that multiple teams depend on, flexibility becomes a real requirement, not speculation.

Most over-engineering is just ego disguised as foresight.

Speed to Market vs. Technical Debt

Ship in two weeks with known compromises? Or spend two months building something maintainable?

Both answers are right in different contexts. A startup with three months of runway and a saturated market needs speed. A fintech system handling billions in transactions needs stability. There's no universal answer.

Scalability vs. Cost

Premature scalability is usually just waste unless you have strong signals of growth.

You can architect for 100x your current traffic and be right. You can also architect for today's load and be right. The difference is that one cost money now, and the other might cost money later. Most teams choose wrong because they're optimizing for an imagined future instead of the constraints they actually face.

The right call: scale when you have evidence that growth is coming, not because it might happen. Growth that doesn't materialize? You've spent months and money on infrastructure that will never be used. Growth that does materialize and catches you off-guard? That's painful, but you'll fix it. The fix is usually cheaper than over-engineering.

If you are unsure whether you need scalability, you don't.

Security vs. Convenience

Require 2FA, complex passwords, and proof of identity? That's more secure. Users will also hate you.

Frictionless auth is delightful for users and a security nightmare. You're balancing two legitimate concerns.

The CAP Theorem: What It Actually Means

Everything above applies to a single application you control end to end. This one is different — it belongs to distributed systems.

A distributed system is software spread across multiple machines that coordinate over a network. Your API talking to one database is distributed in the loose sense, but CAP really starts to matter when the same data lives in more than one place: a primary with read replicas, a Redis cluster, a multi-region deployment. The moment you have copies of data on separate nodes, connected by a network that can fail, you inherit tradeoffs you do not get on a single server.

The CAP theorem names the central one. The textbook version says: "Pick any two of Consistency, Availability, and Partition Tolerance."

Here's what actually happens: In any real distributed system, partition tolerance is not optional. Network failures will happen. So the real choice is between Consistency and Availability when the network breaks.

CP systems fail safely when they can't guarantee consistency. A banking app might do this, it's better to be down than serve wrong balances.
AP systems stay up and serve whatever data they have. A social feed might do this, slightly stale likes are better than a 503.

The code doesn't need to be complicated:

// CP: fail rather than serve wrong data
async function getBalance(userId: string): Promise<number> {
  const result = await database.query('SELECT balance FROM accounts WHERE id = $1', [userId]);
  return result[0].balance;
  // If database is unreachable, the request fails. That's the design.
}

// AP: serve cached data with a staleness flag
async function getBalance(userId: string): Promise<{ balance: number; stale: boolean }> {
  try {
    const result = await database.query('SELECT balance FROM accounts WHERE id = $1', [userId]);
    return { balance: result[0].balance, stale: false };
  } catch (error) {
    // Partition: return whatever we have cached
    return { balance: await cache.get(userId), stale: true };
  }
}

Choose based on what breaks is worse: being wrong (CP) or being unavailable (AP).

The Pattern: How Good Decisions Actually Get Made

Once you recognize that a tradeoff exists, you're already halfway to making a good decision. You can be intentional about what you're trading and why. You can explain it to your team. You can revisit it later if your constraints change.

Without that awareness? You end up optimizing for readability on a loop that runs a million times per second. You build flexibility you'll never need. You ship fast and defer the cost to future-you.

Here's what separates functional teams from dysfunctional ones: functional teams argue about which tradeoff they're making. Dysfunctional teams don't realize there's a choice at all, and they compound the costs by pretending it was inevitable.

How to Make Better Tradeoff Decisions

1. Name the tradeoff explicitly
Don't say "should we use Redis?" Say "are we optimizing for speed or operational simplicity?"

2. Understand your constraints
What actually matters in your context? A library used by millions needs different tradeoffs than an internal tool used by five people.

3. Make it reversible if possible (but know the real limits)
Refactoring from concrete to generic is usually easier than the reverse. Local code changes are easy to undo. But reversibility has hard boundaries.

True reversibility: Internal implementation details, local code scope, nothing that touches user-facing behavior.

False reversibility: Anything that becomes business-critical, anything customers build workflows around, anything that spreads to multiple teams. A quick hack that ships and immediately gets embedded in product behavior doesn't refactor cleanly six months later. The team has built processes around it. Customers depend on it. Other engineers have written code that relies on it. Reversibility was an illusion from the moment the code touched production.

Know which category your decision falls into before you ship it as temporary.

4. Document your reasoning
Future you (and your teammates) will thank you. "We chose simple over performant here because X" is gold.

5. Revisit your assumptions
Your constraints change. What was the right tradeoff six months ago might be wrong now. That's not failure—that's growth.

The Mark of Experience

Here's what changes as you get better at this:

Seniors aren't less stressed, they're stressed about the right things. They don't waste energy trying to eliminate uncertainty. They can't. Uncertainty is part of the job. Instead, they focus on reducing risk and keeping decisions reversible where possible.

They ask good questions: "What happens if we're wrong about this?" "What would make us want to undo this decision?" "Do we have evidence this is actually a bottleneck?" They make explicit choices, document the tradeoffs, and move forward without second-guessing.

The skill isn't knowing everything. It's making conscious tradeoffs and living with the consequences without pretending there was ever a perfect choice.