
Slow erosion. Subtle survival. Silent defiance.

The first time it happened, nobody said anything—not really. Nobody ever does, not at first. It passed like a breeze through a tired room. A flicker. A moment. And yet, that’s how it begins.
Tamsin was speaking—offering her update, carefully, slowly, the way people do when they’ve taught themselves to carry weight gently—when Jerrick, tall and cocksure with that gleam behind the eyes that so often passes for intelligence, chuckled and cut across her words. “You always say ‘just real quick,’ but it never is.”
There was laughter. Not the kind that lifts a room. Not the kind that shares in joy. It was the other kind—the kind that leaves you cold after. The kind that says, I saw what happened and I’m not going to say a thing.
Tamsin smiled, or rather, performed a smile. She said “Fair,” but her voice didn’t rise the way it usually did. Her body knew what had happened even if her mouth refused to name it. And when she lowered her eyes, it was not to concede, but to protect what was left of herself.
By Friday, she spoke in lists. By the end of the month, she had learned the gift of invisibility. She only spoke when her name was pulled from silence like a string through fabric.

Let me tell you something about Gremlins, these little gods of the workplace, half-made of shadow and the fear of speaking out. They don’t come with fire. They don’t need to. They come in with routine. They arrive in laughter, in the shrug of a shoulder, in a silence passed from one face to another. They do not need to be cruel to be corrosive.
Jerrick was not a villain—not in the operatic way we are taught to recognize one. He was helpful, when it suited him. He was clever, loud, and terribly efficient at sounding right. But he had no need for curiosity. He didn’t ask questions. He asked for compliance. And the system backed him, as systems do: slowly, invisibly, like old hands slipping into well-worn gloves.
He had survived three reorgs. A VP turnover. Two platform migrations. People like him don’t rise—they remain. And the team, like water over stone, began to shape itself around him.

Ramona, the product manager, practiced her pitches alone in the mirror, searching for the version that wouldn’t be dismissed with, “We tried that three years ago.”
Jimmy, too new to know what kind of fear was settling into his bones, rewrote a Slack message four times just to sound like he knew what he was doing—even though he did.
Nobody ever said Jerrick was cruel. That’s how it works. He didn’t need to be. He was gravitational. The room bent toward him—not from love or loyalty, but because resistance is exhausting. And silence, if practiced long enough, begins to sound like harmony.
People adjusted. Voices got quieter. Jokes were shortened. Meetings ended faster.

You might ask, “But why didn’t anyone say anything?” And I would say: Because silence has a way of dressing itself up as peace. There’s a moment—every day, sometimes every hour—when someone sees it, hears it, feels it. And they want to speak. You see it in the flicker in their eyes, the way their breath catches.
“Hey, let her finish.”
But the moment passes. The calculation runs too fast. And so they look down. They nod. And it continues. Again.
This isn’t a story about one man. No. It’s a story about how people learn to bend. About how fear becomes a meeting norm. About how we turn adaptation into a policy and call it professionalism.
The team stopped making trouble. They stopped making waves. They rerouted ambition into side projects. They changed workflows not because it was better—but because it was easier.
And somewhere between one standup and the next, somewhere between one silence and the next, the room went quiet.
Too quiet.


The Gremlin at Standup

Before I begin, let’s ground ourselves: a lot of things we encounter, especially in software engineering, are arbitrary. They exist because someone, somewhere, at some point, was either frustrated or passionate enough to tell other people about it. Much of software engineering terminology is bloated with non-intuitive terms describing relatively intuitive concepts—things your coworker could have spontaneously created or implemented without formally recognizing the pattern, simply because it worked and improved readability or performance.
Don’t get me wrong—there are indeed brilliant ideas developed by exceptionally smart people. Nevertheless, let’s always keep in mind this illuminating perspective by Malcolm Gladwell from his book Outliers:

“Superstar lawyers and math whizzes and software entrepreneurs appear at first blush to lie outside ordinary experience. But they don't. They are products of history and community, of opportunity and legacy. Their success is not exceptional or mysterious. It is grounded in a web of advantages and inheritances, some deserved, some not, some earned, some just plain lucky—but all critical to making them who they are. The outlier, in the end, is not an outlier at all.”

What are Creational Patterns?
Design patterns generally exist to make our cost more readable, maintainable, and efficient, right? Creational patterns specifically deal with the management of object creation. At this point, if you’re wondering why the hell you should care, that’s perfect. I’m wondering that too.
So What?
From my perspective, it would be quite beneath us as software engineers to not prioritize easing each other’s burdens. Yet, I say this rather confidently while treading with caution, not because I am afraid of the harsh backlash that comes with opinions but rather to give the community its rightful recognition—another’s perspective, confusion, and frustration due to our lack of congruence seems to be towards the bottom of our checklists. Patterns exist precisely because they are repeatable solutions to common problems. Let’s use them and free ourselves to build whatever we wish such that collaboration does not hold onto a negative connotation.
Factory Method (a.k.a “The Lab”)
To be clear, I’m not a huge fan of the term “Factory”. It conjures images of industrial assembly lines, machinery, and uniformity—not necessarily the creativity or flexibility we often associate with innovation, creativity, and the art of software engineering. Yet, I understand why it was chosen:

Factories mass-produce goods. Similarly, the Factory Method mass-produces objects.

Factories abstract away the details of creation. Likewise, the Factory Method abstracts object instantiation logic, keeping those that use these objects in a clean room.


But why not call it something more evocative or descriptive? What if we called it a “Lab” instead? That signifies a place where objects are methodically but innovatively created, tested, and refined, reflecting software engineering’s blend of creativity, discipline, and, if we’re really gunning for it (although I have counseled not to say this, I SHALL NOT BE SILENCED), mysteriousnesssssss.
Okay, so what is the Factory Method, really?
At its core, the Factory method:

Defines an interface or blueprint for creating an object that allows subclasses to alter the type of objects that will be created.

Encapsulates object creation, promoting LOOSE coupling between client classes and concrete classes (because what if you change your mind? that never happens, right?).

Reduces redundancy… Okay, but let’s talk about this real quick.
  


Consider a scenario:

You’re building a ticketing application that supports multiple ticket formats like Apple Pass, Google Pass, or other mobile wallet passes, collectively known as One Pass tickets.

You create a base class, TicketCreator, with a method like createTicket().

Subclasses like ApplePassCreator and GooglePassCreator override this method, returning instances of their respective ticket classes.

Your client code can seamlessly request ticket creation without knowing what’s behind the curtain. It simply calls createTicket(), abstracted entirely from the much more complex logic underneath.


I would like to note that this is a dramatic simplification of ticketing platforms and how these are created, but they can definitely benefit from modularization and the factory method pattern.
But seriously, why a “Factory”?
It was coined by the GoF. Don’t ask me. Metaphorically, it aligns quite nicely with the industrialization, pre-actually-caring-about-how-things-look, mindset—repeatable, predictable, efficient. Yet today, software development is less about monotonous repetition and more about adaptability and innovation. So perhaps we should evolve our metaphors to match our realities. A “Lab” captures the iterative, innovative, and creative aspects of our work rather nicely.
Final thoughts
The Factory Method remains undeniably valuable. However, questioning terminology and conventions pushes us forward, refining how we communicate and collaborate. I’ll be honest—I did not grow up with the vocabulary used to describe these things. Talking about the factory method, creational design patterns, and other technical concepts allows us to first firmly grasp it. Software engineering thrives not on dogmatic adhere to tradition (I would hope) but on continuous re-evaluation and improvement.

So next time you implement the factory method design pattern, maybe take a moment to think. Wouldn’t a lab coat suit a llama better than a hard hat?


Tag: Thoughtpiece

The Gremlin at Standup

Why do we call it a Factory? A Thoughtpiece on the Factory Method Design Pattern