DEV Community: Micah Breedlove (druid628)

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.

array_map Is Not A Design Pattern

Micah Breedlove (druid628) — Tue, 07 Apr 2026 11:18:00 +0000

The Moment It Clicked

“Damn it Doug! array_map is not a design pattern!”

I will never forget hearing that yelled across the office during a code review.

And to this day, every time I run across code that’s trying a little too hard to be clever, that line pops back into my head.

How We Get There

Doug was a smart engineer. Seriously smart.

But he had a habit I’ve seen in a lot of really sharp developers — myself included, if I’m being honest. He’d find a tool, a pattern, or a concept he liked…

…and then use it everywhere.

At some point, that turned into what we started calling — half joking, half traumatized —

The array_map design pattern

Which, to be clear, is not a thing.

The Problem in Practice

I remember reviewing a piece of code from his team where it was literally:

an array_map
inside an array_map
calling another array_map
returning an array_map

And I’m not exaggerating.

It worked and was technically correct. It was also an absolute nightmare to read, debug, and maintain.

Clever vs Clear

And that’s the part that matters. Because this isn’t really about array_map. It’s about what happens when we start optimizing for cleverness instead of clarity.

I’ve been guilty of this too -- writing code that made me feel smart, code that looked elegant. Expressive. Maybe even impressive in a code review.

And then six months later, someone else is digging through it trying to fix a bug, wondering what in the world I was thinking.

Sometimes that “someone else” was me.

The Real Issue

The problem isn’t the tool or the technique. It’s how and when we choose to apply it.

The problem is forgetting that code has a second life:

being read, understood, and maintained by someone else.

Most systems don’t fail because they weren’t clever enough. They fail because no one can understand them anymore.

Complexity vs Control

Now, to be fair — I’m not a fan of nested loops either.

If I can avoid them, I will.

I’ll happily spend extra time structuring data, reshaping inputs, or breaking problems apart so I don’t have to stack loops on loops.

That’s not about performance as much as it is about clarity and control. But there’s a difference between avoiding complexity…

…and hiding it behind layers of abstraction that make things harder to follow.

What Good Looks Like

Sometimes the right solution isn’t the most clever one. It’s the one that makes the intent obvious.

Something like:

foreach ($items as $item) {
    $result[] = transform($item);
}

It’s not fancy, nor is is going to win you any style points. But anyone who reads it knows exactly what it’s doing.

And more importantly — they can change it without fear.

That’s the real goal. Not just writing code that works. Writing code that survives.

Closing Thought

Just because a tool exists doesn’t mean it should drive the design. Just because something is expressive doesn’t mean it’s appropriate. And just because it feels clever…

doesn’t mean it’s a good idea.

“array_map is not a design pattern.”

It’s a tool.

Use it when it makes things clearer. Put it down when it doesn’t.

Cross-posted: LinkedIn | Medium

AI Didn’t Make Me Faster. It Made Me Think Better.

Micah Breedlove (druid628) — Thu, 02 Apr 2026 11:30:18 +0000

I wrote recently about some concerns I have with how our industry is starting to treat AI.

This isn’t that.

Because the truth is, AI has also made me better at what I do. Not faster. Not necessarily more productive in the way people like to measure it.

Better.

And the more I’ve thought about it, the closest analogy I’ve found isn’t in software at all. It’s in the forge.

When I was learning blacksmithing, I wasn’t just being shown how to hit steel. I was learning how to think about it.

How heat changes behavior. How structure forms over time. How small decisions early on show up later in ways you can’t undo. And more than anything, I learned by asking questions. Not just "how do I do this?" But "what would happen if I did it this way instead?"

Sometimes the answer came from the person teaching me.

Sometimes the answer came from trying it and seeing what happened.

But the learning came from having a place where those questions could exist.

Most of my career has been spent in backend engineering — working in ecosystems like Symfony, .NET, Spring. Environments where structure matters, where decisions compound, and where “we’ll fix it later” usually turns into “we’re still dealing with this six months from now.”

A lot of the real work in that world isn’t typing code.

It’s thinking.

It’s weighing trade-offs. It’s deciding which problems you’re solving today and which ones you’re intentionally leaving for later.

And historically, that kind of thinking has been… a little isolated.

You either grab time with another senior engineer, or you just sit with it yourself.

AI changed that for me.

The best way I can describe it is this:

AI hasn’t felt like a replacement. It’s felt like something closer to an apprenticeship mirror.

A way to throw ideas out and see them reflected back — sometimes clearly, sometimes distorted — but almost always enough to make you stop and think.

There’s something incredibly valuable about being able to just… nerd out over a design.

No meeting. No calendar. No worrying about whether you’re taking up someone’s time.

Just throwing ideas out there:

"What if I structure it this way?" "What happens if this scales?" "Is this clever, or is this going to bite me later?"

And getting something back that isn’t trying to impress you — just trying to be useful.

It’s not just solutions, either.

Some of the most useful conversations I’ve had haven’t been about solving a specific problem at all. They’ve been about exploring different approaches, frameworks, and even languages.

Just nerd-talking through things.

Comparing trade-offs. Challenging assumptions. Asking "why not this?" instead of defaulting to "this is how I’ve always done it."

That’s led to something I didn’t expect.

Honestly, some of my favorite conversations I’ve had with AI have been around those exact moments — revisiting ideas, technologies, or approaches I had already written off.

It’s made me more willing to reconsider tools and approaches I might have dismissed in the past.

Not because AI told me I was wrong — but because it gave me a space to actually think through those decisions instead of relying on instinct or habit.

There’s another angle to this that I didn’t expect.

In the past, when I was working through a design or a tricky decision, the best thing you could do was grab another engineer — or a couple of them — and effectively red team it.

"Alright, poke holes in this."

And if you had good people around you, that was incredibly valuable.

The problem is, time is expensive.

Everyone’s busy. Calendars are full. And pulling someone into that kind of deep, focused thinking isn’t always easy.

What I’ve found is that AI fills that gap surprisingly well.

Not as a replacement for good engineers — but as a low-friction way to pressure-test your thinking. You can throw an idea out there and say:

What am I missing?

Where does this break?

What happens if this assumption isn’t true?

And you’ll get something back that isn’t trying to be clever. It’s not trying to win the argument. It’s just trying to work through the problem.

It’s not perfect. It won’t catch everything.

But it’s fast. It’s available. And it’s often enough to surface the kinds of questions you should be asking anyway.

One thing I’ve come to appreciate is how often the best answer isn’t the most clever one. It’s the one that’s easiest to understand six months from now.

More than once, I’ve ended up in a conversation where the feedback essentially boils down to:

Future you is going to hate current you in six months if you do this.

And it’s usually right.

That’s the part that’s been the most valuable. Not the answers. The feedback loop.

Sometimes the best part of using AI isn’t the answer it gives you — it’s the question it makes you ask. Or the hesitation it introduces. Or the moment where you stop and think:

"Why am I doing it this way?"

That kind of interruption in your own thinking is hard to come by when you’re working alone.

None of this replaces experience.

If anything, it makes experience more valuable.

Because the better your understanding is, the better you can evaluate the feedback you’re getting. The better you can separate useful pushback from noise. The better you can recognize when something is technically correct… but practically wrong.

And sometimes, just wrong.

That’s something I think is important — especially for engineers coming up behind me.

It’s okay to push back on AI. It’s not always right.

AI is useful — but only if you stay in charge of the thinking.

I ran into this just yesterday. I moved a conversation into a new chat, and in doing that, a lot of the context got lost. The suggestions I got back were clean. Reasonable. Technically sound.

But they were based on assumptions that weren’t true anymore. If I had just taken that answer and run with it — no pushback, no clarification — it would have worked just well enough to get through the moment…

…and then turned into an absolute nightmare a year or two down the road.

It only got better once I pushed back.

That won’t work here because…

You’re missing this constraint…

This part of the system behaves differently…

And once the context was corrected, the answer changed. That’s the difference. The value isn’t in getting an answer.

It’s in being able to challenge it.

Back at the forge, the person teaching me didn’t just give answers. They gave me space to ask better questions. To try things. To think things through. To understand not just what worked — but why.

That’s what this feels like.

I still think there’s real risk in how our industry is starting to position AI. I still think we need to be careful about what we think it is. But at a personal level, the impact has been hard to ignore.

AI hasn’t replaced my thinking.

It’s made me more deliberate about it.

It’s made me question decisions a little more.

It’s made me a little less attached to being “right” and a little more focused on getting it right. And in a field where small decisions compound over time…

That might be the most valuable thing it can do.

In the forge, iron sharpens iron. We make better tools through pressure, repetition, and refinement. I think there’s something similar happening here.

We can make AI better by how we use it. But we have to be just as intentional about letting it make us better in return. Because at the end of the day, the tool doesn’t define the craft.

The craftsman always has.

Crossposted: LinkedIn | Medium