DEV Community: Micah Breedlove (druid628)

Archetype: The Chef

Micah Breedlove (druid628) — Mon, 27 Jul 2026 14:15:00 +0000

Most sprint planning meetings follow a familiar pattern.

Work gets divided up. Owners volunteer for different pieces. Infrastructure starts talking about new environments, and QA begins thinking through test cases. Before long, it feels like everything has been accounted for.

Then someone asks a simple question. It may not be exactly phrased like this but it amounts to asking this:

"What has to be true before we can start?"

It’s interesting to watch what happens next.

The conversation shifts almost immediately. People stop talking about individual tasks and start talking about dependencies. Someone remembers the API contract. Another engineer points out the database migration depends on indexes that don’t exist yet. Infrastructure mentions firewall rules. QA asks whether feature flags will be available for testing.

Within a few minutes, the whiteboard is covered in arrows.

The original plan wasn’t wrong. It just wasn’t complete.

I’ve worked with engineers who naturally think this way. They don’t just see the work in front of them. They instinctively see how the work fits together.

I think of them as Chefs.

The Engineers Who See the Whole Kitchen

If you’ve ever watched the kitchen of a busy restaurant, you know it can look almost chaotic. Orders are coming in, multiple dishes are being prepared at once, and every station is focused on its own responsibilities.

Yet somehow everything comes together.

A great Chef isn’t simply cooking their own dish. They’re making sure every station has what it needs before it needs it. They notice when one part of the kitchen is about to become a bottleneck, and they adjust before anyone else realizes there’s a problem.

I’ve worked with engineers who think the same way. They’re fully engaged in their own work, but they also have an uncanny ability to see how dozens of moving pieces fit together.

They Orchestrate From Within

One mistake people make is assuming the Chef is directing everyone else.

That’s rarely what I’ve experienced.

The best Chefs aren’t standing above the team assigning work. They’re contributing alongside everyone else while quietly connecting pieces that don’t yet connect.

They notice when one engineer is about to block three others. They recognize opportunities for parallel work. They see prerequisites before they become blockers.

They don’t orchestrate from above. They orchestrate from within.

They Ask Different Questions

One thing I’ve noticed over the years is that great Chefs aren’t valuable because they always have the answers.

They’re valuable because they ask the questions that reveal the answers everyone else needs.

You’ll hear them ask questions like:

What do you need before you can start?
Who are you waiting on?
If you got that tomorrow, what’s next?
What assumptions are we making?

Sometimes they already think they know the answer. They ask anyway.

Not because they doubt themselves, but because they know the people closest to the work often reveal dependencies no one else has considered.

Those conversations uncover hidden assumptions long before they become production problems.

They Optimize Flow

Most engineers naturally focus on the work in front of them. Chefs naturally focus on how work moves through the system.

They think about sequencing, dependencies, timing, and opportunities for parallel work.

Sometimes the most valuable thing they do all day isn’t writing code. It’s recognizing that a small infrastructure change this morning allows three other engineers to make progress this afternoon, or noticing that multiple teams are all waiting on the same missing piece.

The Chef isn’t trying to maximize their own output. They’re trying to maximize the team’s ability to keep moving.

They’re Not a Job Title

It’s easy to mistake a Chef for an engineering manager, project manager, technical lead, or architect.

Often they are, but sometimes they aren’t.

I’ve known Chefs who were senior engineers, consultants, architects, and individual contributors. Some were exceptional communicators. Others were quiet. Some probably wouldn’t have wanted to manage people at all.

The common thread wasn’t authority. It was orchestration.

A project manager might naturally ask, “When will this be done?”

A Chef is more likely to ask, “What has to be true before this can be done?”

One question tracks progress. The other uncovers dependencies.

Neither is better. They’re simply solving different problems.

The Invisible Ingredient

When you enjoy a great meal, you rarely think about everything that had to happen behind the scenes to make it possible.

You notice the finished product, not the coordination that made it possible.

Great engineering teams work much the same way.

Most people notice the feature, the deployment, or the difficult technical problem that was solved. They rarely notice the engineer quietly making sure everyone had what they needed before they needed it.

The one asking the question that revealed the dependency everyone else had overlooked. The one helping the entire team move together.

That’s the Chef.

In the final article of this series, we’ll bring these archetypes together and explore something I’ve become increasingly convinced of while writing them:

Great engineering organizations aren’t built by hiring one type of engineer. They’re built by understanding how very different kinds of engineers make one another better.

Archetype: The Bear Killer

Micah Breedlove (druid628) — Fri, 17 Jul 2026 15:00:00 +0000

Years ago, an old boss described a friend of mine in a way I've never forgotten.

Whenever a team ran into a problem they couldn't solve—or had simply spent too long trying to solve—he'd bring in my friend Kyle.

Kyle would figure it out, fix it, and then move on to the next impossible problem.

He called Kyle "The Bear Killer."

The analogy came from an old story.

If a village had a bear they couldn't drive away, they didn't expect every villager to become a bear hunter.

They found the Bear Killer.

He came into town, killed the bear, dragged it away, and then continued on to the next village that needed him.

I've thought about that analogy many times over the years because it perfectly describes a certain kind of engineer.

Once I had a name for that kind of engineer, I started seeing Bear Killers everywhere.

The Engineers Who Walk Toward the Bear

It usually starts the same way.

The deployment has failed.

Production is down.

The migration has stalled.

The integration nobody fully understood has finally broken.

The room gets quiet.

Eventually someone says:

"Can we get Kyle involved?"

If you've spent enough time in software, you know exactly who that person is.

Bear Killers aren't necessarily the smartest engineer on the team. They aren't always the architect or even the most senior engineer.

They're simply the person everyone trusts when progress has completely stopped.

Calm Creates Clarity

One of the first things you'll notice about a Bear Killer is that they don't seem to absorb panic the way everyone else does.

While the room fills with theories and speculation, they're usually doing something much less exciting.

They're gathering information.

Their questions are almost disappointingly ordinary.

"When did it last work?"

"What changed?"

"Can I see the logs?"

"Can we walk through the deployment?"

They're not trying to sound clever. They're trying to understand reality before they start proposing solutions.

Panic rarely solves technical problems.

Clarity often does.

They Find the Bear

One of the reasons Bear Killers seem so effective is that they refuse to chase symptoms.

Most teams become trapped trying to solve whatever problem is directly in front of them. They fix the timeout, investigate the exception, restart the service, or rerun the deployment. Sometimes those things help.

Often they don't.

Bear Killers work differently.

They assume those symptoms are probably connected, so they keep digging until they find the thing that's creating all the others.

Sometimes it's a configuration change.

Sometimes it's an expired certificate.

Sometimes it's a tiny assumption buried deep inside code that nobody has questioned in years.

Once they find the bear...

Everything else starts making sense.

They're Temporary by Nature

One thing I've noticed about Bear Killers is that they rarely want permanent ownership.

They're drawn to difficult problems, not long-term maintenance.

Once the system is healthy again, they're usually happy to hand it back to the team. In fact, many become restless if they stay too long.

Their satisfaction comes from removing the obstacle that had everyone stuck.

After that, they're already looking toward the next impossible problem.

The Danger of Becoming the Hero

Like every archetype, Bear Killers have a blind spot. Organizations quickly learn who can solve the impossible problems. The temptation is to call that person every single time something goes wrong.

At first, it feels efficient.

Eventually, it becomes dangerous.

Knowledge stops spreading because everyone waits for the Bear Killer. Engineers stop growing because someone else will eventually fix it.

The organization slowly creates a dependency on the very person who has been helping it move forward.

Ironically, the engineer who removes the most bottlenecks can accidentally become the biggest one.

That's not a failure of the Bear Killer.

It's a failure of leadership.

The Best Bear Killers Teach Others to Hunt

The strongest Bear Killers eventually realize something important.

Killing today's bear solves today's problem. Teaching someone else how to hunt solves tomorrow's.

They don't protect their methods.

They explain their reasoning.

They walk younger engineers through the investigation. They document what they learned so the next outage doesn't begin from zero. The goal isn't to become indispensable. It's to make the next crisis a little less mysterious than the last one.

Eventually, the organization needs fewer Bear Killers because more engineers have learned how to think like one.

That's probably the highest compliment a Bear Killer can receive.

Not that everyone depends on them.

That they don't have to anymore.

The Specialists You Hope You Don't Need

Organizations don't plan for crises.

They plan for success.

But every engineering organization eventually encounters a problem that falls outside normal experience.

When that happens, Bear Killers have an unusual ability to restore momentum—not because they're superheroes or because they're always the smartest person in the room, but because they've learned to stay calm long enough to find the real problem.

And once the bear is gone...

They're already walking toward the next forest.

In the final article of this series, we'll meet The Chef—the engineers who somehow bring all of these very different personalities together into a cohesive team.

Archetype: The Blacksmith

Micah Breedlove (druid628) — Wed, 08 Jul 2026 17:02:00 +0000

Some engineers look at an aging system and immediately start planning its replacement.

Blacksmiths usually pause for a moment.

Then they ask a different question.

"Before we replace it, let's understand it."

That question isn't driven by nostalgia.

It's driven by curiosity.

Every long-lived system has a story. Every strange workaround, every awkward abstraction, every design decision was made by someone solving a problem that existed at the time.

The Blacksmith wants to understand that story before deciding what comes next.

The Engineers Who Restore Confidence

One of the easiest ways to recognize a Blacksmith is by the work they volunteer for.

While other engineers gravitate toward new projects, Blacksmiths often find themselves drawn toward the systems everyone else quietly avoids.

They're curious about the service that only one engineer knows how to deploy. They want to understand why the build takes twenty minutes, why the database has become everyone's favorite punchline, or why an application has developed a reputation for being "too fragile to touch."

Most teams see those systems as liabilities.

Blacksmiths see opportunities.

Not opportunities to rebuild everything from scratch, but opportunities to restore confidence.

Modernization Begins With Understanding

People sometimes mistake Blacksmiths for engineers who dislike change.

In my experience, the opposite is usually true.

Most Blacksmiths enjoy modernization.

They simply believe that good modernization begins with understanding rather than demolition.

Legacy systems rarely survive by accident.

Some have quietly supported critical business processes for decades. Others still handle millions of dollars in transactions every year. Even systems that have accumulated significant technical debt often contain years of hard-earned business knowledge.

A Blacksmith knows that replacing software is easy.

Replacing understanding is much harder.

Before deciding what should be modernized, extracted, rewritten, or retired, they want to understand why the system has continued delivering value for so long.

Craftsmanship Over Replacement

One of the things I admire most about Blacksmiths is that they see modernization as a craft rather than a project.

Sometimes preserving value means upgrading an aging framework.

Other times it means breaking a monolith into services one capability at a time.

Occasionally it means deleting thousands of lines of code because the healthiest system is the simplest one.

And yes, sometimes it means replacing an entire subsystem.

The decision isn't driven by fashion.

It's driven by judgment.

The goal isn't to preserve old software.

The goal is to preserve the value that software still provides while making it healthier for the future.

They Leave Systems Better Than They Found Them

Blacksmiths don't just repair software.

They restore trust.

After they've spent time with a system, deployments become more predictable. New engineers can understand the code more quickly. Monitoring improves. Documentation appears. Long-standing bugs disappear. The codebase slowly stops feeling like something people fear.

That's one of the clearest signs a Blacksmith has done their job.

The system isn't merely functioning again.

The team believes in it again.

The Hardest Decision

There's a misconception that Blacksmiths always want to save legacy systems.

The best ones know better.

Not every system deserves another decade of life.

Some architectures have reached the end of their usefulness. Some codebases have become so constrained by earlier decisions that starting over genuinely is the better choice.

The difficult part isn't knowing how to modernize.

It's knowing when modernization has reached the point of diminishing returns.

Blacksmiths understand that stewardship sometimes means rebuilding.

The key is making that decision deliberately instead of emotionally.

The Danger of Becoming Too Attached

Like every archetype, the Blacksmith has a blind spot.

Because they see value where others see decay, they can sometimes invest too much effort trying to save systems that no longer justify the investment.

Craftsmanship can become perfectionism.

Stewardship can become attachment.

Healthy Blacksmiths recognize that their responsibility isn't to save every system.

Their responsibility is to exercise good judgment about which systems are worth saving.

The Quiet Craftsmen

Organizations naturally celebrate new products, new technologies, and ambitious initiatives.

Far less attention is given to the engineers who quietly ensure yesterday's successes continue serving tomorrow's customers.

Yet without them, every organization eventually accumulates brittle systems, fragile deployments, and institutional knowledge that exists only inside someone's head.

Blacksmiths prevent that from happening.

They modernize instead of merely replacing.

They strengthen instead of merely repairing.

They leave systems—and the teams responsible for them—healthier than they found them.

The best Blacksmiths don't preserve the past.

They carry its value into the future.

In the next article, we'll meet The Bear Killer—the engineers who thrive when everyone else is simply trying to survive.

Archetype: The Gardener

Micah Breedlove (druid628) — Tue, 23 Jun 2026 14:16:00 +0000

Some engineers seem to come alive when they're handed a blank page.

No legacy constraints, aging systems, or years of accumulated decisions. Just possibility.

Where many engineers see uncertainty, the Gardener sees opportunity.

They are often the first to ask:

"What if we tried this?"

Or:

"I wonder what would happen if we built it differently."

Gardeners are naturally drawn toward growth. Not growth in the organizational-chart sense. Growth in the sense of creating something that does not yet exist.

The Engineers Who Cultivate Possibility

Gardeners are often easy to recognize because they're constantly exploring possibilities.

They're the people who walk away from a meeting and say:

"Oh, I have an idea."
"Give me a couple days. I'll have you something."

A few days later they're back with a prototype, a proof of concept, or an entirely new way of looking at the problem.

Not every idea succeeds.

The Gardener understands that.

They're simply willing to plant more seeds than most people.

One of the easiest ways to recognize a Gardener is by their relationship with uncertainty.

Many engineers become uncomfortable when requirements are vague. When nobody is entirely sure where they're headed or how they're going to get there, Gardeners often have the opposite reaction.

Uncertainty feels like open ground. A place where experimentation is possible and where new ideas can take root.

That doesn't mean Gardeners are reckless.

The best Gardeners are thoughtful experimenters. They know not every seed will grow. They're simply willing to plant more of them than most people.

Growth Requires Cultivation

People often imagine innovation as a lightning strike. A sudden moment of brilliance.

In reality, most successful ideas emerge through cultivation.

They begin as rough concepts.

Then prototypes.

Then experiments.

Then small successes.

Then larger wins.

Gardeners thrive in this process.

They enjoy:

exploration
iteration
discovery
experimentation
continuous refinement

What excites them isn't necessarily the finished product.

It's watching something grow from an idea into a reality.

Gardeners Create Momentum

One reason organizations need Gardeners is that growth rarely happens by accident.

Someone has to be willing to venture into the unknown. Teams need someone to challenge assumptions. There has to be someone who will ask whether there might be a better way.

Gardeners create momentum.

They push ideas forward.

They discover opportunities.

They help organizations avoid becoming trapped by their existing successes.

Without Gardeners, many organizations become excellent at preserving what already exists and terrible at discovering what comes next.

Growth Needs Foundations

At first glance, Gardeners and Masons can look remarkably similar.

Both are usually excited by what comes next.

Both prefer creating over maintaining.

Both spend much of their time thinking about the future.

The difference lies in what they're trying to create. A Gardener cultivates growth while a Mason creates stability.

A Gardener sees an empty field and imagines what could grow there.

A Mason sees the same field and wonders whether the ground can support it.

Neither perspective is sufficient on its own because growth without foundations becomes fragile.

Foundations without growth become monuments to unrealized potential.

The strongest organizations understand the importance of both.

The Danger of Endless Planting

Like every archetype, Gardeners have failure modes.

A Gardener can become so excited about new possibilities that they lose interest in tending existing ones.

The next idea is always more exciting than the current implementation.

The next project is always more interesting than maintenance.

The next experiment is always more appealing than refinement.

Left unchecked, this can create organizations filled with unfinished initiatives and abandoned experiments.

Healthy Gardeners understand that growth requires more than planting.

It also requires cultivation.

The goal isn't to start everything.

The goal is to help the right things grow.

The Future Doesn't Build Itself

One reason I wanted to include the Gardener in this series is because growth-oriented engineers are often misunderstood.

Organizations frequently celebrate outcomes while overlooking the people who discovered the opportunity in the first place.

The product gets celebrated.

The revenue gets celebrated.

The success gets celebrated.

What often goes unnoticed is the person who first looked at an empty patch of ground and imagined something growing there.

Somewhere inside every successful organization, you'll usually find a few Gardeners.

They're asking uncomfortable questions.

Exploring uncertain paths.

Planting ideas that may not bear fruit for months—or years.

Most won't succeed.

A few will change everything.

In the next article, we'll look at The Blacksmith—the engineers who restore durability and strengthen systems that others might be ready to abandon.

Archetype: The Mason

Micah Breedlove (druid628) — Wed, 17 Jun 2026 17:18:40 +0000

Some engineers look at an aging system and immediately start planning its replacement.

Blacksmiths usually pause for a moment.

Then they ask a different question.

"Before we replace it, let's understand it."

That question isn't driven by nostalgia.

It's driven by curiosity.

Every long-lived system has a story. Every strange workaround, every awkward abstraction, every design decision was made by someone solving a problem that existed at the time.

The Blacksmith wants to understand that story before deciding what comes next.

The Engineers Who Restore Confidence

One of the easiest ways to recognize a Blacksmith is by the work they volunteer for.

While other engineers gravitate toward new projects, Blacksmiths often find themselves drawn toward the systems everyone else quietly avoids.

Most teams see those systems as liabilities.

Blacksmiths see opportunities.

Not opportunities to rebuild everything from scratch, but opportunities to restore confidence.

Modernization Begins With Understanding

People sometimes mistake Blacksmiths for engineers who dislike change.

In my experience, the opposite is usually true.

Most Blacksmiths enjoy modernization.

They simply believe that good modernization begins with understanding rather than demolition.

Legacy systems rarely survive by accident.

A Blacksmith knows that replacing software is easy.

Replacing understanding is much harder.

Before deciding what should be modernized, extracted, rewritten, or retired, they want to understand why the system has continued delivering value for so long.

Craftsmanship Over Replacement

One of the things I admire most about Blacksmiths is that they see modernization as a craft rather than a project.

Sometimes preserving value means upgrading an aging framework.

Other times it means breaking a monolith into services one capability at a time.

Occasionally, it means deleting thousands of lines of code because the healthiest system is the simplest.

And yes, sometimes it means replacing an entire subsystem.

The decision isn't driven by fashion.

It's driven by judgment.

The goal isn't to preserve old software.

The goal is to preserve the value that software still provides while making it healthier for the future.

They Leave Systems Better Than They Found Them

Blacksmiths don't just repair software.

They restore trust.

That's one of the clearest signs a Blacksmith has done their job.

The system isn't merely functioning again.

The team believes in it again.

The Hardest Decision

There's a misconception that Blacksmiths always want to save legacy systems.

The best ones know better.

Not every system deserves another decade of life.

Some architectures have reached the end of their usefulness. Some codebases have become so constrained by earlier decisions that starting over genuinely is the better choice.

The difficult part isn't knowing how to modernize.

It's knowing when modernization has reached the point of diminishing returns.

Blacksmiths understand that stewardship sometimes means rebuilding.

The key is making that decision deliberately instead of emotionally.

The Danger of Becoming Too Attached

Like every archetype, the Blacksmith has a blind spot.

Because they see value where others see decay, they can sometimes invest too much effort trying to save systems that no longer justify the investment.

Craftsmanship can become perfectionism.

Stewardship can become attachment.

Healthy Blacksmiths recognize that their responsibility isn't to save every system.

Their responsibility is to exercise good judgment about which systems are worth saving.

The Quiet Craftsmen

Organizations naturally celebrate new products, new technologies, and ambitious initiatives.

Far less attention is given to the engineers who quietly ensure yesterday's successes continue serving tomorrow's customers.

Yet without them, every organization eventually accumulates brittle systems, fragile deployments, and institutional knowledge that exists only inside someone's head.

Blacksmiths prevent that from happening.

They modernize instead of merely replacing.

They strengthen instead of merely repairing.

They leave systems—and the teams responsible for them—healthier than they found them.

The best Blacksmiths don't preserve the past.

They carry its value into the future.

In the next article, we'll meet The Bear Killer—the engineers who thrive when everyone else is simply trying to survive.

The Five Engineering Archetypes

Micah Breedlove (druid628) — Tue, 02 Jun 2026 20:51:34 +0000

The software industry has a strange habit of pretending there is only one correct kind of engineer.

Depending on the era, we call them:

rockstar
ninjas
10x developers
staff-plus unicorns
AI-native engineers
or whatever the latest LinkedIn post insists will save civilization

But after more than two decades in software, I've become increasingly convinced that healthy engineering organizations are not built around a single ideal engineer.

They are built around complementary strengths.

Some engineers excel at building foundations.

Some cultivate growth.

Some restore aging systems.

Some thrive during crises.

Others bring order and cohesion to growing complexity.

The longer I've worked in this industry, the more I've noticed that these engineers often resemble older craft archetypes more than modern corporate titles.

Not because software engineering is "just like blacksmithing."

But because civilizations have always depended on different kinds of specialists.

Builders.

Cultivators.

Repairers.

Protectors.

Organizers.

Modern software organizations are no different.

Beyond the Mythical Engineer

One of the recurring themes in engineering culture is the search for a mythical engineer.

The person who can:

innovate
architect
modernize
lead
rescue failing systems
coordinate teams
mentor others

and yet somehow do it all simultaneously

The longer I stay in this profession, the less convinced I am that such people exist.

At least not sustainably.

What I do see are engineers who consistently create value in different ways.

Not because they are better than their peers.

Because they are drawn toward different kinds of problems.

Over time, I found myself grouping many of those tendencies into five broad archetypes:

The Mason
The Gardener
The Blacksmith
The Bear Killer
The Chef

These are not personality types.

They are not measures of seniority.

And they are certainly not measures of worth.

They are simply different ways engineers contribute to the health and survival of technical organizations.

The Mason

The Mason builds foundations.

These engineers are often drawn toward:

platforms
frameworks
domain models
infrastructure
architecture
and foundational systems

What makes them unique is that much of their work exists to support things that have not been built yet.

A Mason may spend months building something that only becomes valuable when dozens of other engineers begin building on top of it.

They think in terms of structure, stability, and permanence.

Where others see a project, the Mason sees the ground beneath it.

The Gardener

The Gardener cultivates growth.

These engineers thrive in:

greenfield projects
experimentation
discovery
iteration
and possibility

They are often the first to ask:

"What if we tried this?"

Gardeners create conditions where new ideas can take root and grow.

They are comfortable operating in uncertainty and often help organizations discover opportunities that were not obvious beforehand.

The Blacksmith

The Blacksmith restores durability.

These engineers are often found working on:

modernization efforts
technical debt
infrastructure improvements
performance bottlenecks
and aging systems

Where others see something outdated, the Blacksmith sees something worth repairing.

They understand pressure, stress, and failure modes.

More importantly, they understand how to strengthen systems so they can continue serving the people who depend on them.

The Bear Killer

The Bear Killer handles existential threats.

Every organization eventually encounters problems that normal processes cannot solve.

They come alive during:

Outages
Critical failures
Security incidents
Impossible migrations
High-pressure emergencies
The problems no one can solve

Bear Killers are often the engineers who become calmer as pressure increases.

They simplify chaos.
Focus attention.
Contain damage.
And help organizations survive moments when everything feels uncertain.

The Chef

The Chef creates cohesion.

As organizations grow, complexity grows with them.

More teams.
More systems.
More dependencies.
More moving pieces.

The Chef understands how all those pieces fit together.

They think in terms of:

timing
coordination
communication
sequencing
and flow

A Chef recognizes that successful systems require more than technical excellence.

They require orchestration.

Healthy Engineering Organizations Need All Five

One of the mistakes engineering organizations often make is overvaluing whichever archetype happens to be fashionable at the moment.

Startups often celebrate Gardeners.

Large enterprises desperately need Blacksmiths.

Crisis-heavy organizations become dependent on Bear Killers.

Growing companies eventually discover the importance of Chefs.

And many organizations fail to appreciate Masons until years after the foundations have already been laid.

But healthy engineering cultures usually require all five.

Because software systems are not static.

They are born.
They grow.
They age.
They fail.
They evolve.

And different engineers are naturally drawn toward different parts of that lifecycle.

That diversity is not weakness.

It is how technical civilizations survive.

In the articles that follow, I want to explore each archetype individually, beginning with The Mason — the engineers who quietly build the foundations upon which entire technical organizations are constructed.

The Myth of the 10x Developer

Micah Breedlove (druid628) — Wed, 27 May 2026 14:50:53 +0000

The idea of the "10x developer" has been floating around the industry for years.

Usually, it gets framed around speed.

Someone who writes code faster.
Ships more tickets.
Pushes more commits.
Produces more.

Personally, I've never really liked that definition.

Not because highly productive engineers don't exist. They absolutely do. But I think we've been measuring the wrong thing.

The best engineers I've worked with were rarely the people writing the most code.

In fact, sometimes they were writing less. Because a lot of their value came from preventing problems before they ever existed.

They asked uncomfortable questions early and spotted assumptions no one else noticed. They challenged designs that "should probably be fine," and they saw downstream consequences before the rest of the room had even finished discussing the feature.

And sometimes?

They slowed things down.

That part is important. Because speed and effectiveness are not always the same thing.

I've seen engineers move incredibly fast, straight into bad decisions. I've seen teams optimize themselves directly into complexity.

I've even seen projects hit every sprint goal while quietly becoming increasingly hard to maintain.

The best engineers I've worked with understood something deeper:

Working code is not the finish line.

A strong engineer thinks beyond:

"Does this work?"
"Did the tests pass?"
"Can we ship it?"

They think about:

maintainability
operational cost
onboarding friction
future flexibility
failure modes
team comprehension

They think in trade-offs.

That's where the real multiplier effect comes from. Not typing speed. Not commit count. Not how quickly someone can scaffold a feature.

The real multiplier is reducing future pain.

Sometimes that looks like:

preventing a rewrite
simplifying a design
catching a scalability issue early
asking the question no one else thought to ask

And sometimes it looks like saying:

"I think we're solving the wrong problem."

That kind of engineering value is hard to measure.

Mostly because the best outcomes are often invisible.

Nobody sees:

the outage that never happened
the incident that was avoided
the migration that didn't become necessary
the complexity that never entered the system

But experienced engineers know those things matter.

A lot.

Ironically, AI has made me think about this even more. Because AI can absolutely make people faster. I've seen it firsthand. But faster is only useful if the direction is correct.

If anything, the rise of AI makes strong engineering judgment even more valuable.

Because now the bottleneck isn't always code production.

Sometimes the bottleneck is knowing what should be built in the first place.

The best engineers I know can work in multiple languages, frameworks, and environments.

But the thing that makes them valuable isn't syntax.

It's perspective.

They can look at a problem from every angle:

technical
operational
organizational
long-term

They don't just understand how to build systems. They understand how systems fail.

That's the skill.

And no productivity metric fully captures it.

So when people talk about "10x developers"...

I think they're pointing at something real. But I think they're measuring the wrong thing.

The best engineers aren't the ones producing 10x more code.

They're the ones creating 10x less chaos.

🔐 Working with Private Symfony Recipes

Micah Breedlove (druid628) — Thu, 21 May 2026 14:25:52 +0000

Private Symfony Recipes (or: how I stopped repeating myself)

I got tired of setting up the same things in every Symfony project.

Same configs.
Same services.
Same little pieces of glue code that aren’t hard—but add up.

Symfony recipes solve a lot of this.

Until you need your own.

At some point I decided:

“Surely there’s a way to do this privately.”

So I sat down one evening and started digging.

Docs open.
Composer configs half-understood.
A couple of tabs that looked promising but didn’t quite connect.

And for a while… nothing clicked.

I remember getting to the point where I was about ready to reach out to someone a lot smarter than me and just ask:

“Alright, what am I missing here?”

And then it finally clicked.

🧠 The idea

Symfony recipes aren’t magic.

They’re just:

A repository
With a specific structure
That Flex knows how to read

So instead of relying only on the public recipes repo, you can point your project at your own.

A private recipes repository.

🪓 The basic setup (no fluff)

At a high level, you need:

1. A recipes repository

This is just a git repo with a structure like:

recipes/
  vendor/
    package/
      version/
        manifest.json
        config/
        src/

The important piece is the manifest.json.
That’s what tells Symfony Flex what to do.

2. A manifest

Example:

{
  "copy-from-recipe": {
    "config/": "%CONFIG_DIR%/"
  }
}

This is where you define:

files to copy
configs to apply
environment setup

3. Tell Composer where to find it

In your project’s composer.json:

{
  "extra": {
    "symfony": {
      "endpoint": [
        "https://your-private-recipes-repo",
        "flex://defaults"
      ]
    }
  }
}

👉 Order matters. Your repo goes first.

4. Install your package

Now when you require your package:

composer require your/package

Symfony Flex will:

check your private repo first
apply your recipe
then fall back to defaults if needed

💡 What I actually use this for

This is where it gets useful.

My private recipes handle things like:

Shared configuration across projects
Common service wiring
Internal conventions I don’t want to rethink every time

Instead of:

“Alright, how did I set this up last time?”

It becomes:

“composer require → done”

⚠️ The gotchas (aka the part that took way too long)

A few things that tripped me up:

The structure has to be exactly right
The endpoint configuration is not intuitive the first time
Debugging why a recipe didn’t apply is… not fun

If it’s not working, check:

Is your repo reachable?
Is the path correct?
Is the version directory matching what Flex expects?

Most of my time wasn’t spent building this.

It was spent figuring out why it wasn’t working.

⚡ The payoff

Once it clicked, everything got easier.

New project?

Require package
Config shows up
Services wired
Done

No more:

digging through old repos
copying configs manually
forgetting one small but important detail

Closing

This isn’t a flashy feature.

It’s not something you demo.

But it’s one of those things that quietly saves time every single time you start something new.

And if you’ve ever found yourself thinking:

“I’ve done this before… why am I doing it again?”

This might be worth the evening it takes to figure out.

Even if that evening is a little frustrating.

Why Ember Feels Natural to Backend Engineers

Micah Breedlove (druid628) — Tue, 05 May 2026 12:30:00 +0000

I’ve never really struggled to learn frontend frameworks.

I’ve struggled to feel like I’m building something stable with them.

Most of the time, I’m working on the backend.

When I’m doing frontend work, it’s usually in bursts—building something out, proving an idea, or wiring up a system so it’s actually usable.

A lot of times, I’m doing that solo.

And every time I come back to frontend work, I run into the same problem.

Everything has changed.

The patterns are different.
The tooling has shifted.
The “right way” to do something is no longer the way it was the last time I touched it.

So now, before I can even start building…

I have to get spun back up.

Again. I don’t have time for that.

Sure, I could build my own set of patterns.

Put together a little rapid development setup.
Standardize how I do things.
Create my own “mini framework” on top of whatever I’m using.

But that only works until the next time I need it.

Because by then, everything underneath it has changed again.

That’s the cycle Ember breaks for me.

I’ve picked Ember up, put it down, and come back to it multiple times over the years.

And every time, I’m productive again in about an hour.

Not because nothing changed.
But because what changed made sense.

The last time I spun something up in Ember, I realized Ember Data was on its way out.

Warp Drive was coming in.

In most frontend ecosystems, that’s a red flag.

That’s a sign you’re about to spend time relearning something fundamental.

But this wasn’t that.

Warp Drive didn’t feel like a replacement.

It felt like the next logical step.

I didn’t have to rethink how everything worked.
I didn’t have to throw away what I knew.
I just… kept going.

That’s the difference.

Ember doesn’t optimize for constant reinvention.

It optimizes for continuity.
And as a backend engineer, that matters more than anything else.

I’m used to systems where structure matters.
Where things have a place.
Where decisions you make today are still going to exist six months from now.

Ember feels like that.

It gives you a structure up front:

routing that makes sense
services that behave predictably
a clear place for things to live

It doesn’t ask you how you want to organize your application.
It gives you a way to do it.

And that’s not a limitation.

That’s a relief.

Because I don’t want to spend time deciding where things go.

I want to build something.

That’s where Ember really clicks for me.

Most frontend frameworks give you flexibility.

You can structure things however you want.
Pick your tools.
Define your patterns.

And that sounds great.

Until you have to maintain it.
Until you come back to it six months later.
Until someone else has to figure out what you were thinking.

Flexibility solves the problem you have today.
Consistency solves the problems you don’t know you’re going to have yet.

Ember chooses consistency.

It’s not perfect.

Ember Data has its quirks.
Adapters can feel like a maze sometimes.

But the trade-offs are intentional.

It’s not trying to be everything.
It’s trying to be predictable.

And that predictability compounds.

I don’t need a framework that lets me do anything.

I need one that helps me do the right thing consistently. I don’t want to rebuild my frontend architecture every time I start a project.

I want to start building features.

That’s why Ember feels natural to me.

Not because it’s easier.
Not because it’s simpler.
But because it aligns with how I already think about building systems.

And when a tool does that...

you stop fighting it.

You just build.

We're Not Hiring for Languages Anymore

Micah Breedlove (druid628) — Tue, 28 Apr 2026 12:30:00 +0000

I found myself wondering recently:
Are job descriptions asking less about languages than they used to?

So I went looking.
I started going through postings to see if it was real…

And the pattern showed up pretty quickly.

Job descriptions aren't asking for languages as much.

Instead, I'm seeing more emphasis on:

specific AI tools
platforms
workflows

Less:

"strong experience in X language"

"experience with [tool] or [AI-assisted development stack]"

That's a shift. And I don't think it's accidental.

AI has lowered the barrier to writing code. You don't need to know everything about a language to get something working anymore.

That's powerful.

But it also raises some questions.

What Are We Optimizing For?

If language expertise becomes less important, what replaces it?

Because something always does.

Right now, it looks like we're replacing:

deep understanding of a language

with:

familiarity with tools that generate or assist with code

That's not inherently bad.
But it changes how decisions get made.

Concern #1: Choosing the Right Tool

If fewer people have deep language experience, then fewer people are equipped to evaluate:

trade-offs between languages
long-term maintainability
performance implications

The risk isn't that we pick a bad language.

It's that we stop asking:

"Is this the right language at all?"

Concern #2: AI Bias Becomes Industry Bias

AI tools don't treat all languages equally.

Some are better supported. Better trained. More represented.

I ran into this firsthand recently.

I was exploring a project idea and decided to use AI as a sounding board. I'd already done most of the thinking—worked through trade-offs, had a direction in mind.

But as I talked through the design, it kept nudging me.

Away from what I had chosen…
Toward C#, Python, or Go.

Not once. Repeatedly.

So afterward, I ran a small experiment. I started having similar conversations—same kinds of problems—but across different languages and frameworks.

And it didn't take long to notice a pattern.

Some languages were consistently favored. Others were… gently discouraged.

Not explicitly.
But enough that, if you weren't paying attention, you'd end up somewhere you didn't choose.

Over time, that can create a feedback loop:

AI favors certain languages
developers use those languages more
those languages become even more dominant

Not because they're always the best choice.
But because they're the easiest.

And languages that fall outside that loop?

They start to fade.

Concern #3: The Perception of Skill Changes

If AI can generate working code...

then the perception becomes:

"How hard can this really be?"

That's not new.
But it gets amplified.

Because now, more people can produce something that looks like a solution.

The difference between:

working code
good code

becomes harder to see.

I've seen how that perception can play out.

I worked at a place where the owner of the company was heard—more than once—saying:

"I don't understand why I have to pay engineers more than data entry people. It's the exact same thing."

That wasn't coming from malice.
It was coming from misunderstanding.

A lack of visibility into what actually goes into engineering:

the decisions
the trade-offs
the long-term consequences

AI doesn't create that misunderstanding.
But it can reinforce it.

Because when code becomes easier to produce, it's even harder from the outside to see the difference between:

something that works
and something that's built well

And when that distinction disappears…

so does the perceived value.

Concern #4: A Tighter Job Market

Lowering the barrier to entry does something else. It increases the number of people who can compete.

That's great for access.

But it also means:

more applicants per role
more noise in the hiring process
harder differentiation

Especially for engineers early in their careers.

This isn't all downside.

There Are Real Advantages

1. Easier Transitions Between Languages

Switching stacks used to be a real hurdle.
Now?
It's easier to ramp.

That opens doors for engineers who want to:

explore different ecosystems
move into new roles
avoid being locked into a single stack

2. Access to New Industries

Language requirements have historically acted as gatekeepers.

If you didn't have the "right" experience, certain roles were just off-limits.

That's changing.

More people can move into:

industries they care about
problems they're interested in solving

That's a good thing.

3. Working Across Environments Gets Easier

AI reduces friction when jumping between systems.

You don't have to context-switch as hard.

You don't have to remember every detail.

That makes engineers more flexible.

So Where Does That Leave Us?

I don't think language knowledge is going away.

But I do think it's being deprioritized.

And that means we need to be more intentional about what we value. Because if we're not careful, we don't just lower the barrier to entry.

We lower the standard.

The real skill has never been writing code.

It's understanding what should be written…
and why.

The best engineers I've worked with know multiple languages.

Not because the languages matter that much—

but because thinking in different systems does.

They can look at a problem from every angle:

performance
maintainability
trade-offs
long-term impact

They don't just solve the problem in front of them.
They understand the shape of it.
That's the skill.

And no tool replaces that.

At least not yet.

The Case for Red Teaming Your Design

Micah Breedlove (druid628) — Tue, 21 Apr 2026 14:00:00 +0000

The System That Was Never Challenged

I worked on a system that, on the surface, was well-architected.

It had structure. It had clear intent. It solved the problem it was designed to solve.

And in a lot of ways, it was good work.

It also had an N+1 problem.

On top of that, it was running, on average, an additional 60 or so queries per page load.

And there was enough “magic” baked into it that, over time, only a couple of us really understood how it worked.

None of that happened because the engineer who built it didn’t know what they were doing.

Quite the opposite.

They were capable. Thoughtful. Intentional.

The system didn’t fail because of a lack of skill.

It failed because it was never truly challenged.

Red Team vs Blue Team

Before I go too far, it’s probably worth calling out the obvious question:

If there’s a red team… what’s the blue team?

In this context, the blue team is the group responsible for the design itself — the people building the architecture, writing the technical design document, and making the initial set of decisions.

They’re the ones solving the problem.

The red team exists to challenge how that problem is being solved.

And if you’ve ever had a TDD red-teamed and absolutely shredded by the Navy’s N6… everything else tends to pale in comparison.

In a lot of places, that challenge gets folded into a design review.

A TDD or TAD walkthrough where stakeholders, engineers, and leadership all sit in a room and talk through the design.

On paper, that sounds like the right place for it.

In practice, it usually isn’t.

Those meetings tend to be high-level.

There’s pressure to keep things moving.
To stay focused.
To not get bogged down in edge cases or deep technical rabbit holes.

And that’s not necessarily wrong — those meetings serve a purpose.

But it also means the harder questions…

The uncomfortable ones…

The “what happens when this breaks?” conversations…

often don’t get asked.

Or don’t get asked deeply enough.

That’s why I prefer to separate them.

A blue team session to design the system.

And a dedicated red team session to pressure-test it.

Different goals. Different mindset. Different conversations.

One builds.

The other challenges.

And you need both.

Building the Right Red Team

In security, we talk about red teams.

Groups whose job is to actively probe, challenge, and break systems before someone else does.

Engineering doesn’t always have an equivalent.

But it should.

Over time, I’ve found that the most effective red teams aren’t random.

I try to be intentional about who’s in the room — or at least what perspectives are represented.

At a minimum, I want:

someone strong on the backend — how the system is structured and behaves
someone who understands the frontend — how it’s actually used and where it breaks in real interaction
someone with a deep understanding of the database — how queries behave and where performance issues hide
someone security-minded — thinking about abuse, edge cases, and failure modes

And depending on the system, I’ll also try to bring in:

someone with an operations or SRE mindset — thinking about failure, recovery, observability, and “what happens at 2am”
someone approaching it from a maintenance perspective — “how hard is this to live with in six months?”

Sometimes one person can cover multiple areas.

I also try to be mindful of how many people I’m pulling into this.

In most cases, I’ll cap an initial red team at around four people.

That tends to be the sweet spot — enough perspective to meaningfully challenge the design, without unnecessarily interrupting half the team.

If I can get the right coverage with three, I’ll do that.

And if I can only get three, I’ll take three.

That’s where having people who can span multiple disciplines becomes really valuable.

The goal isn’t to make this heavy.

It’s to make it effective.

One of the more surprising things I’ve learned is how valuable it is to include mid-level engineers in these conversations.

Not because they know less — but because they see things differently.

They’re often the ones closest to the day-to-day work.

They’re the ones most likely to be maintaining what gets built.

And they ask questions that more senior engineers sometimes skip right past.

The kind of questions that sound simple…

until you realize they’ve just exposed something you hadn’t considered at all.

More than once, those have been the questions that mattered most.

What Red Teaming Actually Looks Like

Because most design problems don’t look like problems at the beginning.

They look like decisions.

Reasonable ones.

Individually justifiable.

Even clever.

Until they aren’t.

Until load increases.

Until someone new joins the team.

Until a bug shows up in a place no one expects.

Until the system becomes something only its author can safely modify.

That’s where red teaming comes in.

Not as criticism.

Not as bureaucracy.

But as a deliberate practice:

“Let’s try to break this before reality does.”

In practice, that often looks like questions:

What happens under load?
Are we introducing N+1 queries?
How many queries does this page actually generate?
Where are we relying on implicit behavior or “magic”?
How long would it take a new engineer to understand this?
What assumptions are we making that might not hold?

None of these questions are particularly difficult.

But they’re easy to skip when you’re focused on getting something built.

Why It Matters

That’s the trap.

Because building is visible.

Shipping is measurable.

Thinking ahead… isn’t.

And to be clear — this isn’t about slowing things down.

It’s about avoiding the kind of complexity that slows you down later.

I’ve found that some of the best engineering conversations happen when someone is willing to say:

“I don’t think this breaks yet… but I think it will.”

That’s not negativity.

That’s experience.

And this is where tools — including AI — can help.

Not as decision-makers, but as pressure testers.

A quick way to ask:

“What am I missing?”
“Where does this fall apart?”
“What assumptions am I making?”

But just like anything else, that only works if you’re willing to question the answers you get back.

Because at the end of the day, red teaming isn’t about tools.

It’s about mindset.

Closing Thoughts

Good engineers build systems that work.

Great engineers build systems that survive scrutiny.

If there’s one thing I’ve learned, it’s this:

Most of the issues that hurt the most later…

were visible earlier.

We just didn’t ask the right questions.

Or we didn’t ask them soon enough.

Red teaming isn’t about catching everything.

It’s about catching enough early that the system stays understandable, maintainable, and resilient over time.

Because systems don’t break all at once. They erode. Quietly. Until one day, they’re too complex to safely change. And by then, it’s already expensive.

So ask the questions.

Invite the pushback.

Pressure-test the design.

Before reality does it for you.

🌳 Watering the Bonsais

Micah Breedlove (druid628) — Tue, 14 Apr 2026 14:30:00 +0000

There was a point in my career where I had a dozen open pull requests.

Not half-finished experiments.
Not “I’ll get back to this later” work.

Twelve branches.
Each one solved a real problem.
Each one was implemented, tested, and ready for the next step—code review, QA, or in some cases just validation.

They just… weren’t a priority.

One of them stands out.

It was one of those problems everyone agreed needed to be fixed.
The kind that shows up in conversations, gets a few nods, and then quietly gets pushed to “later” because it’s assumed to be expensive.

“Probably a week of work.”
“Maybe more.”
“Let’s not disrupt the sprint.”

One Friday afternoon, I had a few hours between tasks—too late to pick up anything substantial, too early to call it a day.

So I took a swing at it.

Four hours later, it was done. Tested. Ready for review.

Not a week. Not a sprint.

Four hours.

And then it joined the others.

Waiting.

So once a month, usually on the first, I’d go through and rebase them all.

Resolve conflicts.
Update dependencies.
Make sure nothing drifted too far from reality.

I started calling it:

Watering the bonsais.

What is a “bonsai branch”?

A bonsai branch is work that is:

Fully (or nearly fully) implemented
Solves a real, known problem
But is blocked by prioritization, validation, or timing

It’s not dead code.
It’s not abandoned.

It’s maintained, deferred value.

The part most teams don’t see

From the outside, these branches look like:

“Engineering started something and didn’t finish.”

From the inside, it looks more like:

The problem was identified
The solution was designed
The work was implemented and tested
And then… it waited

Not because it wasn’t useful.

Because something else was more urgent.

The hidden cost

Bonsais aren’t free.

Every time you keep one alive, you’re paying for it:

Rebase time
Merge conflict resolution
Context switching (“what did this fix again?”)
Mental overhead of tracking what’s “almost done”

You’re maintaining a solution that isn’t delivering value yet.

And if you don’t maintain it?

It dies.

And when it dies, that work doesn’t just pause—it resets.

The hidden value

Here’s the part that matters:

A bonsai branch is already paid for.

The risk is mostly burned down.
The unknowns have been explored.
The implementation exists.

When you finally prioritize it, you’re not starting from zero.

You’re starting from:

almost done.

The tension

Good engineers tend to move faster than prioritization cycles.

They see a problem, they solve it, and they move on.

Organizations don’t always move that way.

They have:

competing priorities
validation cycles
timing constraints

So you end up with this strange middle ground:

Work that is finished… but not allowed to be done.

For engineers

If you’ve got bonsais, be intentional about them.

Keep them alive if they matter
Document what they solve
Don’t let them sprawl endlessly

And maybe most importantly:

Don’t confuse “not prioritized” with “not valuable.”

Those are not the same thing.

For product and business

You might be sitting on solutions you’ve already paid for.

Ask:

What’s been built but not shipped?
What’s been deferred but maintained?
What could be delivered quickly because the work is already done?

Because sometimes the fastest way forward isn’t a new initiative.

It’s revisiting something that’s already been solved.

Closing

Some teams let these branches rot.

Others quietly maintain them—keeping them ready for the moment they’re needed.

Not everything grows in the open.

Some things are shaped, maintained, and patiently kept alive.

Waiting for the right time.

Sometimes the most valuable work in your system
is the work that’s just been… waiting.