DEV Community: Micah Breedlove (druid628)

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

Every successful structure begins with work most people will never notice.

The foundation disappears beneath the building. The road disappears beneath the wagon. The bridge becomes so familiar that people forget it was ever built. Yet everything that comes later depends on those early decisions.

Software is no different.

Spend enough time around engineers, and you'll notice that people are naturally drawn toward different kinds of problems.

Some enjoy building products.

Others thrive on experimentation and growth.

Masons, however, are fascinated by what sits underneath everything else.

Their attention gravitates toward:

architecture
platforms
infrastructure
domain models
developer tooling
foundational systems

While others are thinking about what they're building, the Mason is often thinking about what future teams will build on top of it.

The Engineers Who Build For What Comes Next

One of the easiest ways to recognize a Mason is by the questions they ask.

When a new initiative begins, most conversations revolve around features, timelines, and deliverables.

Masons tend to drift somewhere else entirely.

Rather than asking:

"What are we building?"

they often find themselves asking:

"What will everything else be built on?"

That subtle shift in perspective is what pulls them toward frameworks, platforms, shared services, and architectural foundations.

They're not ignoring the product.

They're thinking a few layers beneath it.

Long before the first feature is delivered, they're already considering what kind of structure will support the work that follows.

Masons Create Leverage

Foundation work can be difficult to appreciate because its value is rarely immediate.

Most organizations know how to celebrate a product launch.

They know how to celebrate a feature release.

Customer feedback shows up on dashboards and in meetings.

A well-designed platform, on the other hand, often disappears into the background.

Ironically, that's usually a sign it is doing its job.

The strongest Masons create leverage.

They invest time in things that make future work easier, faster, safer, or more consistent.

A deployment platform.

A shared authentication system.

An internal framework.

A domain model that allows multiple teams to move in the same direction.

At first, it can look like very little is happening.

Then suddenly dozens of engineers are moving faster because the foundation is there.

The Mason's work often appears expensive right up until everyone starts building on top of it.

The Challenge of Building Ahead

One challenge Masons often face is that foundation work can be difficult to justify before its benefits become visible.

The value of a road becomes obvious once people are traveling on it.

The value of a bridge becomes obvious once people are crossing it.

Before then, all anyone sees is construction.

This can create tension between Masons and the rest of an organization.

While everyone else is focused on the next visible outcome, the Mason is often investing in capabilities that may not pay dividends for months—or even years.

As a result, Masons sometimes find themselves answering the same question repeatedly:

"Why are we spending time building this?"

The irony, of course, is that the best foundation work often becomes so successful that people eventually forget there was a debate in the first place.

They Are Building for People They May Never Meet

One of the things I admire most about strong Masons is that they are comfortable creating value they may never personally realize.

Historically, a mason might spend years constructing roads, bridges, foundations, walls, aqueducts, or public buildings.

The people who benefited most from that work often came later.

Software Masons think similarly.

Many derive satisfaction from knowing:

"Someone else will build something incredible on top of this."

That mindset often leads to a behavior that can seem unusual to other engineers.

After spending months designing a platform, building a framework, or creating a shared service, many engineers naturally want to remain at the center of it.

Masons are often different.

Once the foundation is stable and future work has a place to stand, they're frequently happy to hand the work off and move on.

Their satisfaction comes less from owning the structure and more from knowing the structure can now support others.

In fact, some become restless if they stay too long.

Their attention naturally drifts toward the next foundation, the next platform, or the next piece of infrastructure that doesn't exist yet.

This isn't a lack of commitment.

It's simply where they create the most value.

The Mason's work was never the building itself.

It was making the building possible.

The reward is not ownership.

The reward is enablement.

The Danger of Building Forever

Like every archetype, Masons have failure modes.

A Mason can become so focused on future possibilities that they never reach the present.

Every system can be made more flexible.

Every platform can be made more extensible.

Every foundation can be made stronger.

At some point, however, something must be built on top of it.

Organizations sometimes joke about engineers who spend six months building a framework to avoid writing a two-week feature.

Every joke contains a warning.

The goal of a foundation is not the foundation itself.

The goal is what becomes possible because it exists.

Healthy Masons understand this balance.

The Builders Beneath the Builders

One of the reasons I wanted to include the Mason in this series is because foundation work is often underappreciated.

When products succeed, people celebrate the product.

When teams move faster, people celebrate the velocity.

When organizations scale, people celebrate the growth.

Few people stop to ask what made those outcomes possible in the first place.

But somewhere underneath every thriving technical organization, you'll usually find the work of a Mason.

Perhaps not visible.

Perhaps not celebrated.

But supporting everything above it nonetheless.

The most successful foundations are often invisible.

We rarely notice the roads we travel, the bridges we cross, or the infrastructure that quietly supports our daily lives.

Software is no different.

In the next article, we'll look at The Gardener—the engineers who cultivate growth and help new ideas take root.

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

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