Forem: Micah Breedlove (druid628)

🌳 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

The Balsam of Fierabras and the Promise of AI

Micah Breedlove (druid628) — Mon, 30 Mar 2026 12:32:48 +0000

Lately, I’ve been watching something happen in our industry that feels familiar in a way I can’t quite shake.

Companies are talking about “efficiency gains” from AI. Numbers get thrown around — 20%, 30%, sometimes more. And alongside those numbers come decisions: smaller teams, fewer engineers, faster timelines.

I’ve even heard stories — whether apocryphal or not — of companies laying off the majority of their engineering teams entirely. Product steps in, increasingly armed with AI tools, generating code directly. The few engineers that remain are no longer building systems so much as reviewing them, deploying them, and keeping the lights on.

I understand the appeal. I really do. If I’m being honest, part of me wants it to be true. But I can’t help thinking about Don Quixote. In the novel, there’s a potion called the Balsam of Fierabras. It’s supposed to be a miracle cure — a remedy capable of healing any wound.

Quixote believes in it completely.

When he finally prepares it and drinks it, the result is… less miraculous. He becomes violently ill. It does not heal him. It does not restore him. It very nearly breaks him.

And yet, he insists it worked.

What stuck with me about that scene isn’t that the balsam failed. It’s that the belief didn’t. The promise of a cure was so powerful that the evidence didn’t matter.

Right now, AI is starting to feel like that kind of promise. Not as a tool — but as a cure. A way to move faster, reduce cost, replace effort, and somehow come out ahead without trade-offs.

To be clear, I use AI. I think it’s useful. In some cases, it’s incredibly useful. It can accelerate workflows, help explore ideas, and remove friction from parts of the development process that used to take longer than they should have.

I do worry about engineers being replaced. Not completely, not overnight — but enough to matter. Enough to change who gets to stay, who gets to grow, and who never gets a chance to start.

But what worries me more is something harder to see. I worry about engineering being redefined as something smaller than it actually is. Because software development isn’t just output. It’s judgment. It’s trade-offs. It’s understanding why something should exist, not just how to build it.

When we reduce engineering to output, tools that accelerate output start to look like complete solutions.

I’ve already started seeing hints of this in the wild.

Engineers running into problems with AI that aren’t really code problems at all — but still burning time and credits trying to solve them like they are.

One example I saw recently stuck with me. An engineer had an AI stuck in a loop, trying to fix the same issue over and over again. Different approaches, different variations — sometimes even repeating the same solution.

The problem wasn’t the code.

It was the environment.

One system was using a case-insensitive file system. The deployed environment was case-sensitive. A single character difference was enough to break everything.

The AI never caught it.

And that’s not a knock on AI — it’s just outside the kind of context it naturally understands.

I’ve run into similar issues myself over the years. The kind of problems where experience matters. Where you’re not just reading code — you’re accounting for the messy, inconsistent, very human systems that code runs inside of.

That’s the part that doesn’t translate cleanly.

If we start removing experienced engineers from the equation — or replacing them with people who rely heavily on AI without that depth of experience — how often do we end up stuck in that loop?

Burning time. Burning tokens. Trying solution after solution… when someone with the right context could spot the issue in minutes.

Efficiency doesn’t just come from speed. It comes from knowing where to look. And that’s where I start to get uneasy. Because the danger isn’t that AI doesn’t work.

The danger is believing it works without consequence.

There’s another piece of this that I don’t hear talked about enough: what happens to the next generation of engineers.

A lot of us didn’t learn this craft by writing perfect code the first time. We learned by struggling through problems. By debugging things that didn’t make sense. By following threads deep into systems until we finally understood what was actually happening.

That process is slow. Sometimes frustrating. Occasionally painful. But it’s where the real skill comes from.

If the day-to-day work of engineering shifts toward writing prompts and reviewing generated code, the skill curve changes. The barrier to producing code gets lower — which sounds like a win — but the opportunity to develop deeper understanding starts to shrink.

And over time, that matters.

Because troubleshooting is not a surface-level skill. It’s not something you pick up by reviewing code that already works. It’s something you earn by being lost, over and over again, until you aren’t anymore.

If we reduce the number of engineers building systems from the ground up — if fewer people are forced to wrestle with complexity directly — we shouldn’t be surprised when deep troubleshooting ability becomes rare.

Not gone. But smaller. Harder to find. Concentrated in fewer people.

And that creates its own kind of fragility.

Once decisions are made on the belief that we can do more with less — smaller teams, fewer experienced engineers, more reliance on generated output — the cost doesn’t show up immediately.

It shows up later.

In complexity. In fragility. In systems that no one fully understands anymore.

Systems don’t stay healthy because they were generated quickly. They stay healthy because someone understands them deeply enough to take care of them.

I don’t think this ends with engineering disappearing. But I do think it’s possible we create a gap. Companies optimize for smaller and smaller teams. More output per person. More reliance on generated code. On paper, it looks efficient. Maybe it even is — for a while.

But over time, I can’t shake the feeling that we’re pushing toward a kind of critical mass. A point where the cost of all that generated output — in tokens, in credits, in complexity — starts to rival what it would have cost to simply have experienced engineers in the first place.

And by the time that realization sets in, the landscape may have changed.

Some of those engineers will have moved on. Not out of fear, but out of frustration. Burnout. Or simply because they saw the writing on the wall and chose something more stable.

Others will still be here, but fewer. More spread out. Carrying more of the load.

And the ones coming up behind them may not have had the same opportunities to learn the craft deeply. Not because they lacked ability, but because the environment around them changed.

Fewer chances to struggle through problems. Fewer chances to build systems from the ground up. Fewer mentors with the time, the mandate, the desire — or the instinct — to teach.

That’s the part I keep coming back to. Not the tools. Not the efficiency. But the long-term shape of the profession.

Don Quixote didn’t just believe in the Balsam of Fierabras — he doubled down on it. Even when the results didn’t match the promise.

I don’t think we’re there. Not yet. But I do think we’re at a point where it’s worth asking harder questions.

Not just “can we do this faster?”

But “what are we losing in the process?”

Because if we’re not careful, we may eventually find ourselves trying to rebuild something we quietly let slip away — and realizing the people who knew how to do it are no longer around to ask.

I’m not charging windmills here. Just trying to call it how I see it — and maybe ask a few questions before we all start drinking the balsam.

CrossPosted: LinkedIn | Medium

The Value of Value Objects in Symfony

Micah Breedlove (druid628) — Tue, 11 Feb 2025 23:52:00 +0000

Recently, I was working on an article - similar to this one - focused on Domain-Driven Design (DDD) in Symfony. To illustrate the concepts, I spun up a demo project and brought in one of my commonly used libraries, which includes a collection of data type objects.
That's when I had an epiphany: my primitive and composite data-type objects were essentially just Value Objects with a different name. This realization led me to shift the focus of my article to Value Objects - an essential but often overlooked concept outside of DDD.

What is a Value Object?
At its core, a Value Object is exactly what it sounds like - an object that encapsulates a value. But why use them? While there's no single reason that will blow your socks off, they offer clear advantages in making code more expressive, maintainable, and domain-focused.
That said, not every value in your entity needs to become a standalone Value Object. Overusing them can lead to unnecessary complexity - like the "array_map() Design Pattern." 😀

A Practical Example: Email as a Value Object
Consider an entity with a field that you frequently perform operations on - an email address, for example. Instead of keeping it as a simple string, we can define a dedicated Value Object that encapsulates its behavior and logic.

Step 1: Creating the Email Value Object
For simplicity, I created it in App\Entity\Embeddable:

If you want to create your Value Objects outside of App\Entity then you will need to make modifications to your Doctrine ORM mapping configuration inside config/packages/doctrine.yaml.

Step 2: Embedding it in the Contact Entity

By leveraging the Embedded attribute (Doctrine\ORM\Mapping\Embedded), we seamlessly integrate the Value Object within our entity.

Why is this useful?
Now that we've structured our Email as a Value Object, extracting specific parts - like the user, domain, or TLD - becomes much cleaner, as the logic is all contained within the Value Object:

Now when dealing with your Contact object you can execute the following:

By encapsulating logic within a Value Object, we reduce duplication, improve code readability, and reinforce domain concepts within our applications.

How do you approach Value Objects in your projects? Do you find them useful, or do they add unnecessary complexity?