Mike Hall

The Durable Insights of UGtastic: Shared Wisdom from the DevOps & Craftsmanship Frontier

Thu, 07 May 2026 00:00:00 -0500

While digging through the UGtastic video archives to prepare them for republication, I’ve been struck by how many of these conversations—recorded over a decade ago—feel like they were scripted for today.

Back in 2012-2014, we were at the “start” of two massive shifts: the DevOps movement and the Software Craftsmanship movement. At the time, we were debating how to bridge the gap between “Dev” and “Ops,” and whether “Craftsmanship” was just a fancy word for “doing your job well.”

Re-reading these transcripts now, with the help of modern analysis, I’ve identified a series of what I call Durable Insights. These aren’t just historical artifacts; they are high-confidence, high-impact principles that distilled complex technical and cultural ideas into punchy truths.

Here is why I valued these interviews then, and why I’m sharing them again now.

🎭 The Human High-Bandwidth

One of the most profound realizations from the archive is that while tools change, the human element of software is constant.

Robert “Uncle Bob” Martin famously told me that the relationship between a speaker and an audience is like a “bartender and a patron.” It’s a service-oriented interaction based on “filling the vessel.” In an era where we often consume technical knowledge through sterile AI summaries, Bob’s reminder that video is a “wide bandwidth” medium for emotion and personality is vital.

Similarly, Hadi Hariri challenged the “introverted developer” myth, calling it a mask for communication friction. These were the early signals that “soft skills” were actually the “hardest skills” to master in a collaborative environment.

🏗️ Strategic Architecture

We often think of “modern” architecture as a post-cloud invention, but the foundations were laid in these interviews.

Camille Fournier provided a masterclass in pragmatism by reframing technical rewrites. They aren’t failures; they are strategic business decisions based on the “maintenance tax.” This perspective is essential today as we navigate the transition from legacy monoliths to distributed, AI-augmented systems.

Jez Humble was already defining DevOps not as a set of tools, but as a cultural movement focused on continuous learning. Looking at where we are now, the teams that succeeded were the ones that took Jez’s cultural advice to heart, while those who just “bought a tool” are still struggling with the same handoff friction we discussed ten years ago.

💡 The Art of Practice

The Software Craftsmanship movement brought “practice” to the forefront. Corey Haines introduced the “throwaway” constraint of the Code Retreat—deleting your code every 45 minutes to focus entirely on design.

In our current era of AI-generated boilerplate, the value of internalized intuition (what Dave Thomas calls “Unknown Knowns”) has never been higher. If we let the machines do all the thinking, we lose the “tacit knowledge” that only comes from deep, deliberate practice.

🤝 The Long Road to Republication

This project is deeply personal. I’ve wanted to get back to these archives for years, but the sheer volume of material made it a daunting task. It was only recently that modern AI tools enabled me to finally recover, transcribe, and analyze these hours of conversation.

It is still very much a work in progress. While I’m retaining the original Vimeo links wherever possible, I am steadily migrating the entire library to YouTube. It’s a heavy lift that has taken a significant amount of time, and honestly, if I waited for every single video to be perfect, they would stay locked away for another decade. It has been long enough.

So, please pardon the dust. You’ll find that some interviews are fully transcribed and analyzed, while others are still pending. Some early transcripts need a second pass to meet the quality standards I’m aiming for, but the process is finally coming together.

Republishing these legacy videos isn’t just about nostalgia. It’s about continuity. We often talk about “internet minutes” being the speed of our industry, but these durable insights prove that certain truths move much slower. They are the bedrock. By sharing what Adrian Cockcroft, Rebecca Parsons, and Avdi Grimm were talking about at the frontier, I want to bridge the gap for a new generation of developers entering a field that feels more chaotic than ever.

I hope you enjoy watching these interviews from a “simpler time” in technology. I am profoundly grateful to every single person who took the time to sit down (or more often, stand) with me to discuss what excited them. They shared their work and their hope that others could take these lessons and build better products.

The “Sound of Tokens” might be the new rhythmic backdrop of our work, but the wisdom in these archives remains the signal in the noise. Stay tuned—the process is in flight, and there is much more to come.

The Sound of Tokens: From 80's Arcades to the AI Era

Sat, 04 Apr 2026 00:00:00 -0500

It’s the 80’s and you’re an early adapter, young, impressionable, lacking life experience. You just stepped into an arcade, the cool kids place. The pressure is on. Money weighs heavy in your pocket. So many choices, possibilities. It feels great to be a kid.
You get in line to trade your $ you earned mowing neighbors’ yards. The machine dispenses tokens with a rapid and rhythmic sound. You will remember this sound for the rest of your life.
You step aside, count the tokens to make sure you got the correct amount. You are ready to begin. First available game or should I be more strategic? After all, not every game has the same reward. Some extend your life while select few give you tickets to redeem for a prize. Just in case, you walk by the glass cabinet to check out the prizes. You do rudimentary math in your head for that prize you want. You begin.
The goals are simple:

Beat the one with the highest score and your name/handle goes on the leader board, or
Get the tickets
It’s your first time, you’re going to do both, you never know which one will have a better outcome. The game is on and you’re in the midst of a critical point when message pops up: “insert token to continue”. You do. Repeat. You’re 5 tokens in. You’re lost in the game when a fleeting thought pops in. Should I try a different game? Yes. Skiball is next. You get bunch of tickets and count them in fervor. Did I get enough?
Eventually your tokens run out. You’re done, need to earn more to play more. You spent $10+, but at least you got a sticker and a piece of gum. You’re proud of yourself. Next time you’ll earn a Slinky.
Winning is exhilarating, so the process repeats for few weeks/months. Everyone at the arcade is all in. You’re among like minded people. Then 1 day your friend rolls into your driveway on a brand new bike. Not a baseline bike, the top tier one. It turns out his Dad is a part owner of that arcade you go to. The business is so good, your friend got the best bike there is. Eventually, he offers you a spin. You love it.
3+ decades later, you meet Claude. Hard not to, Claude is everywhere.
All the cool kids are doing it. You feel the surge of excitement again. You try it. Your Claude session ends on a cliff hanger - pay for a token to continue. Flashback. You know that feeling. This time, however, you don’t just empty your pockets, but the excitement is intoxicating. Everyone around you is shipping, winning and leaving the non-adapters behind.
You have a tool and you’re in search of a problem. Demonstrate work to market yourself. Pivot. Go, go, go. You keep seeing things differently, not because of the moral superiority, just experience Arcade taught you, the original “pay to win”. You proceed with caution, because you know what ROI is. Same game, new operator. You hope for everyone’s sake, they will at least get a sticker or bubble gum in the process. Learn all you can.

🚀 From Y2K Panic to AI Anxiety: Why the Future is Always Worth Building

Mon, 03 Feb 2025 00:00:00 -0600

1999: The World Braced for Collapse—But I Was Planning My Escape

In December 1999, the world was fixated on Y2K. People feared that at the stroke of midnight, technology would fail—planes would fall from the sky, banks would lose all records, and the digital age would come crashing down.

But I wasn’t worried about Y2K. I was planning my own escape.

I was working at my father’s shop—unpaid, surviving on food and shelter, having to justify every dollar I asked for. My first real attempt at an IT career—a warehouse contract job assembling computers—had come and gone. I was back where I started, with no money and no path forward.

By the time Y2K hit, I wasn’t bracing for disaster. I was making my move.

Betting on the Future (Even When It’s Uncertain)

I found an early CareerBuilder job posting for a PC/Network Technician at C.H. Robinson. I didn’t meet all the requirements, but I had:

✅ Hands-on IT experience from my short-lived contract job.

✅ Freight forwarding knowledge from working for my father.

C.H. Robinson was a freight company, so I made my case:

“I know the industry, and I know computers. I can learn the rest.”

That was enough. I got the job.

But taking the job came at a cost.

When I told my mother about the $42,000 salary, she immediately told me to take it—she would handle my father. But when I told him, his response was simple:

“You will come crawling back.”

He kicked me out, gave me a deadline to leave, and we didn’t talk for years.

I never crawled back. But I did return—on my terms, standing alongside my then-girlfriend Aneta, who would become my wife and my greatest supporter.

2025: The Future is Still Coming, and Fear Won’t Stop It

Today, people fear AI the way they feared Y2K.

“It’s going to take all the jobs.”
“We’re losing control of technology.”
“We need to stop it before it’s too late.”

I understand the anxiety. But I feel the same way now that I did then:

✅ There is no going back.

✅ Staying in place is not an option.

✅ The only way forward is through.

The lesson I learned in 1999 is the same one I carry in 2025: The future is always uncertain, but it’s still worth building.

Y2K didn’t end the world. AI won’t end the world either.

What we do right now—how we adapt, learn, and build—is what matters.

What’s Your Y2K Moment?

Have you ever faced a moment where everything felt uncertain, but you knew you had to move forward anyway?

Drop a comment—I’d love to hear your story. 🚀

“They’re Your Legs.”

Sat, 01 Feb 2025 00:00:00 -0600

A few weeks ago, I was at Valvoline getting an oil change.

It was a busy day—full bays, a strong shop lead keeping things moving, and a small crew working fast. Watching them coordinate, I was impressed. I was enjoying the moment so much that I even agreed to buy an air filter replacement—something I usually do myself.

My car was due for a tire rotation, so I stepped out while they lifted it.

The manager helped the younger mechanics stabilize the lift, ensuring it was locked in place before moving to the next car.

Everything looked good.

And then—I saw it.

One of the mechanics sat cross-legged under the rear axle.

🚨 My dad’s voice hit me before I even realized I was moving. 🚨

I was through the door. “Hey, don’t cross bones. Don’t trust that jack.”

The young mechanic looked up. “I’m okay,” he said.

I just shrugged. “Okay. They’re your legs.”

And he moved back.

A Team Owns Its Own Safety

Once they were done, I spoke with two of the younger mechanics—a young man who had been working on my car and a young woman who had been listening in as she finished her task.

I reminded them about their buddy—the one who hand-waved his safety, the one who thought he’d be fine under the axle.

I told them:

✅ Kneeling might be uncomfortable.

🚨 But it’s a lot more comfortable than getting crushed.

And more importantly—his safety is their problem, too.

If he gets pinned, it won’t just be his crisis. It’ll be theirs. It’ll be them trying to save him. It’ll be them listening to the screams.

Because a team isn’t just responsible for their own safety. They’re responsible for making sure everyone makes it home.

I Grew Up in a Shop. I Know What Happens When You Get It Wrong.

I grew up in a shop. My father was a lead diesel mechanic and later an owner-operator. Keeping him on the road was priority number one.

By 13, I was breaking down truck tires, armed with nothing but a breaker bar and the will to get it done.

By my late teens, I was running the yard while my dad was on the road. When he came back, he’d tell me what needed to be done, then go to sleep so he could get back on the highway.

That meant I had to work alone—late at night, in a steel building, with machines that didn’t care if I lived or died.

There was no room for mistakes.

🛠 I had to know how to be safe—because no one was there to save me if I wasn’t.

🛠 I had to respect the work—because there’s no such thing as "I’ll fix it later" when you’re under 80,000 pounds of steel.

My dad drilled it into me:

✅ Never trust a jack. Always block and chock.

✅ Assume everything is heavier, sharper, and more dangerous than it looks.

✅ Know the difference between discomfort and disaster. A little discomfort today beats a lifetime of regret.

✅ Never rush safety. You’ll never get back the time you lose if you get it wrong.

The lesson was clear:

👉 The best way to learn safety isn’t through experience—it’s through listening to those who already have it.

This Moment Meant Something.

As I got into my car, I called out— “Hey, stay safe.”

And he hollered back— “I will.”

That moment stuck with me.

I was raised to be independent. To survive. But when it comes to safety, no one is truly alone—it’s always a shared responsibility.

Today, I’m not the kid in the shop anymore. I’m older. A professional software engineer. My world today is almost unimaginable to that younger version of me.

But when I see someone who reminds me of the kid I used to be?

I can’t walk away without making sure they know what I know.

Because sometimes, that’s the difference between walking away from the job at the end of the day— And not walking at all.

The Boy Who Told the Truth

Sat, 01 Feb 2025 00:00:00 -0600

There was a boy who saw a wolf.

He was a shepherd, living where the wild met the edges of civilization. His job was simple: protect the flock, watch the hills, and warn the village if danger came.

One day, he saw the shadow of a wolf in the distance. He shouted to the village: “A wolf is coming!”

By the time the villagers arrived, the wolf was gone. They saw nothing, shrugged, and walked back home.

The boy, still uneasy, began reinforcing the fences, setting traps, and watching the darkness more carefully.

The next day, he saw it again—closer this time. He called out once more: “The wolf is coming!”

Again, the villagers arrived too late. And now, they were annoyed.

"Stop being so dramatic," they said. "Why are you always making noise?" "If the wolf was real, we would have seen it too."

The boy wanted them to understand—this was not imagination. He wasn’t calling for fun. He was calling because he lived at the edge, where the safety of the village ended, and reality began.

But the villagers had always been safe. To them, safety was normal. The idea of a wolf coming wasn’t real because it had never happened to them.

The Wolf Comes Anyway

One night, the boy saw the wolf slip through the trees and attack his sheep. He ran to the village, desperate, shouting louder than ever before. “The wolf is here!”

The villagers, tired of his warnings, did nothing.

By morning, the wolf had not only slaughtered the flock—it had entered the village. The villagers, unprepared, finally understood the danger. But it was too late.

Who Do They Blame?

Not themselves.

Not their complacency.

Not the false security of their village walls.

They blame the boy.

"Why didn’t you warn us better?" "You should have told us in a way that made us listen." "You were too emotional about it—no wonder we didn’t take you seriously."

The boy, exhausted, wounded, and furious, stared at them in disbelief.

"I told you," he whispered. "You just didn’t want to hear it."

The Real Lesson of The Boy Who Cried Wolf

People misremember The Boy Who Cried Wolf as a story about honesty. But what if the boy was never lying?

What if the real problem was not urgency, but apathy?

This happens everywhere.

The engineer who warns that the system is vulnerable.
The scientist who warns of environmental collapse.
The security expert who sees the breach before it happens.
The worker who calls out a toxic leader before the damage spreads.

They see the wolf first. They warn the village. And instead of listening, the village argues about tone, about proof, about how the warning makes them feel.

By the time the wolf arrives, the damage is done.

And the worst part? The people who dismissed the warning will never admit fault. They’ll blame the messenger. They’ll say, "If you had only warned us in the right way, we would have listened."

But that’s a lie.

They didn’t listen because they didn’t want to.

When Someone Warns You About the Wolf, Listen.

If someone is raising alarms—especially someone at the edge of the problem—don’t ignore them just because you don’t feel the danger yet.

Listen to the people closest to the problem.
Don’t dismiss warnings just because they don’t sound the way you want them to.
Don’t wait until the wolf is at your door to take it seriously.

Because when that happens, it’s not just the boy who pays the price.

It’s the whole village.

A Moment of Absurdity in Stagnation

Fri, 31 Jan 2025 00:00:00 -0600

In the early 2000s, before .NET had solidified and JavaScript was still dismissed as a “toy language,” I worked at a small firm developing kiosk-based HR systems. The company was a skeleton crew—just the owner, a senior developer with a long corporate background, a part-time contractor, and me. The entire technology stack was VBScript, ASP, ActiveX, and IE6, dictated by a belief that staying deeply embedded in Microsoft’s ecosystem was the only “serious” way forward.

One of my projects was an on-screen keyboard generator. The initial version in VBScript was bulky and slow, so I rewrote it in JavaScript, dramatically improving speed and maintainability. The next day, I was written up. Not because the solution didn’t work—it did—but because I had violated an unspoken rule. JavaScript was forbidden. It was, according to the senior developer, a “toy language,” and more people knew VBScript anyway.

I sat across from him in the owner’s empty office, as he placed the write-up on the desk in front of me, taking the owner’s chair as if staging a corporate tribunal. The absurdity of the moment hit me then—he had no one but me and a part-time contractor to rely on. He depended on me entirely. Yet, here we were, engaged in a theater of control over something as trivial as which scripting language was used to accomplish the task.

This pattern repeated when .NET entered the conversation. I suggested we explore it. The contractor agreed. But the senior developer shot it down without discussion. When the company’s one major client fell through, a potential buyout followed—only to collapse once the buyer realized the technology stack was already obsolete.

The company folded soon after.

In retrospect, that moment in the empty office encapsulated the entire downfall. A leader so preoccupied with controlling the present that he was blind to the future. So certain of his authority that he refused to see the walls closing in around him.

I walked away from that experience with a simple lesson: sometimes, the greatest risk isn’t change—it’s refusing to change.

The Sound Above: Bridging Inspiration and Understanding in Tech

Fri, 24 Jan 2025 00:00:00 -0600

Defining the Sound Above

“The sound above” represents the echoes of ideas, inspirations, and cultural touchstones that have shaped an industry or a mindset. It’s the legacy carried forward by those who came before, forming an unspoken language and shared context among those who lived through it. For many in tech, Star Trek is part of that sound—a source of optimism, imagination, and exploration that inspired entire generations of programmers, engineers, and dreamers.

But as time passes, the sound grows faint for those who didn’t grow up hearing it. To them, it’s not inspiration; it’s noise—opaque references that can feel like barriers instead of bridges.

Star Trek and the Foundation of Tech

Star Trek, especially The Next Generation, holds a special place in the hearts of many who shaped the modern tech industry. The show’s vision of a future driven by exploration, collaboration, and technology as a force for good resonated deeply with the pioneers of computing. Episodes like “Darmok” embody the spirit of problem-solving, communication, and empathy—core values that underpin not just technology but how we work together as people.

In Darmok, Captain Picard faces an impossible situation: the Tamarians speak entirely in metaphor, referencing their own history and culture in ways that are incomprehensible to outsiders. It’s only through shared struggle, patience, and a willingness to learn that Picard bridges the gap, finding connection where it seemed impossible. This is the heart of what Star Trek has always been—a lesson in overcoming differences through empathy, intellect, and collaboration.

The New Generation: A Different Sound

For those entering tech today, Star Trek isn’t the foundation—it’s a distant echo. To many, it’s just another cultural reference they’re expected to decode, one more hoop to jump through in an industry that already feels intimidating. It’s easy for them to see it as exclusionary, a marker of an in-group they’re not part of. And they’re not wrong—without context, a Star Trek reference might as well be Smurf language: familiar to some, meaningless to others.

But what they may not see—and what senior leaders must help them see—is that Star Trek isn’t just a reference; it’s part of the sound above. It reflects the values and hopes of its time, just as today’s inspirations will shape the next generation of innovators. The task isn’t to force newcomers to learn Star Trek or pass a cultural test—it’s to build a bridge between what inspired us and what inspires them, so they too can contribute to the sound.

The Challenge for Seniors: From Sound to Connection

As senior members of the tech industry, it’s our responsibility to adapt how we communicate and lead. We can’t assume that our references will automatically resonate with others. Instead, we must respect that new people bring their own inspirations, references, and perspectives—and that the gap isn’t a failure on their part. It’s an opportunity for us to connect.

The way forward is through empathy:

Be Receptive: Understand that new voices aren’t rejecting the past; they’re starting from a different place. Meet them where they are.
Respect Their Inspirations: What inspires them might not look like Star Trek, and that’s okay. Their references are no less valid.
Build Bridges: Share the sound above, not as a requirement, but as a gift. Show how the echoes of Star Trek—its optimism, its lessons in connection, its problem-solving spirit—can still inspire, but only if we make it accessible.

Why It Matters

The industry’s strength has always been its ability to build on what came before. But that only works if the foundation is shared. If we want the next generation to care about the sound above—to find inspiration in the values and stories that shaped us—we must first help them thrive. Only then can we inspire them to look up, to hear the echoes of the past and add their own notes to the sound of the future.

In the end, it’s not about forcing people to learn Star Trek. It’s about showing them why it matters to us, and why it might matter to them, too. Just as Picard found a way to connect with the Tamarians, we must find a way to connect across the gaps of generations, culture, and experience. That’s the true spirit of Star Trek—to boldly go where understanding can be built.

The Power of People, Not Just AI

Tue, 21 Jan 2025 00:00:00 -0600

In an era where AI dominates conversations and headlines, it’s easy to feel like the future of work is all about machines solving problems for us. But the truth is simpler—and far more human.

At its core, the work we do is still about people coming together to solve complex problems. And while AI has its place in that story, the most transformative changes I’ve seen are rooted in something profoundly human: collaboration, understanding, and connection.

OpenTelemetry: A Catalyst for Change

For me, OpenTelemetry (OTel) has been one of the most powerful tools for driving these changes—not just as a technical solution, but as a cultural and collaborative one.

OTel provides a framework for observability, enabling teams to measure, understand, and improve their systems. But its real value lies in how it brings people together:

Conversations spark between teams that may never have collaborated before.
Silos begin to connect, as shared dependencies and goals come into focus.
Insights surface into the challenges and triumphs of other teams’ work, creating empathy and understanding across the organization.

The journey to system observability isn’t easy, and it’s far from complete. But even at this early stage, the impact is undeniable.

The Human Impact of Observability

When we introduced observability, I didn’t just see better metrics or cleaner dashboards—I saw people talking.

Teams that were once isolated began collaborating.
Challenges that had been hidden in the complexity of our systems became apparent—and discussable.
Contributors found new ways to align their efforts, building not just better systems, but better relationships.

This is the real value of OpenTelemetry. It’s a practical driver of technical conversations that are inclusive and empowering. And because it’s built on shared frameworks and standards, the innovation it sparks is empirically provable and wholly owned by the people doing the work.

AI’s Role in the Story

AI certainly has its place, and it can help us solve certain types of problems faster or more effectively. But when it comes to the complexity of understanding our systems—and, more importantly, the people behind them—there’s no substitute for human connection.

OpenTelemetry shows us what’s possible when we focus on creating the conditions for collaboration. It’s not just a technical initiative; it’s a cultural shift, a spark for meaningful, distributed change that connects people across silos and teams.

Starting the Journey

We’re still in the early stages of this journey. Observability isn’t perfect, and the work isn’t 100% done. But the act of starting—of creating a shared framework and encouraging collaboration—has already shown how much we can achieve together.

The challenges of complex systems, siloed teams, and competing priorities are daunting. But OpenTelemetry has proven that even the smallest steps toward understanding can unlock meaningful change.

A Call to Action

The future isn’t just about AI. It’s about people, working together to solve hard problems.

It’s about creating frameworks that enable connection.
It’s about breaking down silos and fostering collaboration.
And it’s about starting the conversations that lead to real, lasting innovation.

If you’re considering a journey toward observability, don’t wait for perfection. The act of starting is enough to make a difference—not just for your systems, but for your people.

What I Learned from Running Down a Hallway with Groupon's CEO

Sat, 18 Jan 2025 00:00:00 -0600

Sometimes, a single question can change everything. For me, it wasn’t just a question—it was also a hallway run with Andrew Mason, Groupon’s CEO at the time, that shifted the trajectory of my career and taught me lessons I’m still unpacking to this day.

It started with a lunch that almost didn’t happen. Our engineering team had been scheduled to meet Andrew for months, but the meeting kept getting rebooked. By the time it finally happened, most of our team was at a conference, leaving just a few of us behind. We assumed the lunch would be postponed again, but it wasn’t. Nervously, a small group of us sat down in a meeting room, unsure what to expect.

As we waited, we saw Andrew approach through the glass walls of the office. He glanced in, did a double take, consulted with his assistant, and hesitated for a moment. I’ll never forget that moment of hesitation—it was as if he was deciding whether this meeting was worth his time. Then, he shrugged, walked in, and greeted us enthusiastically.

That decision—to step into a meeting with a smaller group than expected—would end up being pivotal for me, though I didn’t know it yet.

The Question That Changed Everything

The lunch was casual, filled with sushi and light conversation about engineering culture and corporate vision. Toward the end, Andrew asked if we had any questions. I hesitated, then decided to speak up:

"Are you aware of the current attrition rate?"

Andrew was surprised but thoughtful. His initial answer—that attrition was within industry norms—wasn’t unexpected. But I followed up:

"Does that account for who is leaving?"

I pointed out that many of our most skilled and experienced engineers—those who had been with Groupon from the earliest days—were leaving.

Andrew didn’t dismiss the question. He considered it and said he’d look into it. The lunch wrapped up shortly after, and I figured that was the end of it.

But it wasn’t.

The Hallway Run

As I walked back to my desk, I heard someone call out: "Hey, hey, what’s your name?" I turned to see Andrew running down the hallway toward me. He was out of breath by the time he reached me, but he didn’t care about the stares from passing employees. He motioned for me to follow him.

We ran through the office—me, completely bewildered, and Andrew, completely unfazed. Eventually, we arrived at an open-plan intersection where a group of people were deep in conversation with Brian, who was essentially head of engineering. Andrew, still catching his breath, didn’t hesitate to interrupt.

"Mike, this is Brian. Brian, this is Mike. Mike, tell Brian everything you just told me."

And then he ran off, leaving me standing there, completely stunned, in the middle of the intersection with Brian and half a dozen others who had clearly been in the middle of something important.

The Moment That Changed Everything

That moment was life-altering for me, though it likely wasn’t a big deal for Andrew. At the height of Groupon, with millions of things vying for his attention, he heard something I said and decided it mattered enough to act on immediately.

For me, it was overwhelming. At the time, I didn’t fully understand the weight of what had just happened. It was like being hit by a really cool car in an entirely unexpected circumstance—not something I planned for, but something I couldn’t ignore.

That conversation led to a new role as the "Talent Development Business Partner for Engineering," a role I could never have imagined for myself when I first began transitioning into software development.

More Than I Thought Possible

When I took my first timid steps into this new phase of my career, I struggled to believe I was worthy to work with the brilliant minds of Obtiva, let alone play any meaningful role in a company like Groupon. I thought being a Software Developer would be more than enough—that just reaching that point was my goal.

But this moment, this role, this responsibility—it was so much more than I could have imagined. And, honestly, it was more than I could bear at the time. I didn’t feel ready to be "more." It was intimidating to step into something so far beyond what I thought was possible for me.

The Leadership Lesson

That experience taught me a profound lesson about leadership: the further you are from the day-to-day realities of your employees, the harder it becomes to recover when you lose their trust or perspective.

Attrition isn’t just a metric; it’s a story. When you look at who is leaving, you begin to understand the unspoken dynamics shaping your organization.

Andrew didn’t just listen—he acted. That’s the part I reflect on most often. Listening is one thing, but acting before the moment passes you by is what makes the difference.

Why This Matters Now

Organizations often talk about transformation, innovation, and growth. But none of those are possible without the people who make them happen. If you’re in a leadership position, I encourage you to ask yourself: What am I missing? Who should I be listening to? What action can I take today to bridge the gap between strategy and experience?

Sometimes, listening means sitting down over sushi. Other times, it means running down a hallway. Either way, it means acting when the opportunity presents itself—even if it’s unexpected.

The Power of Titles: What I Misunderstood

Tue, 14 Jan 2025 00:00:00 -0600

For most of my career, I’ve eschewed titles. I saw people chase them like prizes—coveting authority without earning respect, collecting accolades without delivering results. I didn’t want to be like that. I thought my work should speak for itself, that my results would be my title.

But that was my mistake.

What I Misunderstood About Titles

I thought rejecting titles meant rejecting ego, politics, and posturing. What I didn’t realize was that titles aren’t just symbols of power—they’re tools of utility. They’re shorthand for your role, your value, and your expertise in a world where time is scarce and perceptions matter.

Here’s what I misunderstood:

Titles Shape Perception A title can mean the difference between being invited to the table or left outside the room. It doesn’t matter if you’re the most qualified person in the building—if your role doesn’t reflect that, people won’t know to include you.
Titles Signal Authority Titles grant weight to your voice. Without them, even your best ideas can be dismissed or overlooked—not because they lack merit, but because people instinctively defer to perceived authority.
Titles Protect Your Work A title isn’t just about status; it’s about accountability. When your role is clearly defined and respected, it’s harder for others to co-opt your contributions or sideline your expertise.

Why I Avoided Titles

I avoided titles because of what I’d seen them represent:

People chasing promotions for the sake of appearances.
Colleagues using their titles as shields to deflect accountability.
Leaders wielding authority without the competence to back it up.

To me, titles seemed like distractions from what really mattered: the work. But I failed to see the bigger picture.

What I’ve Learned About Utility

Titles aren’t inherently good or bad—it’s what you do with them that matters. For someone like me, who values integrity, collaboration, and results, a title isn’t about ego. It’s about utility. It’s about:

Making your contributions visible.
Amplifying your voice.
Ensuring your seat at the table.

A title is a tool—not a prize. And in rejecting it, I gave others tools to define me, to speak over me, and to take credit for work they didn’t do.

Moving Forward

I still don’t covet titles. But I no longer reject them outright. I recognize their utility—not as symbols of status, but as tools for impact. Titles aren’t about what they mean to me; they’re about what they signal to others. They’re a key to opening doors, shaping conversations, and protecting the value I bring to the table.

So no, I don’t want your job. But I do want the recognition and respect that come with doing it well. Titles can help me achieve that—not for vanity, but for fairness. That’s not a mistake I’ll make again.

The Dog Who Caught Their Tail: The Best Collaborators I've Worked With

Tue, 14 Jan 2025 00:00:00 -0600

Some people step into new roles like a dog catching its tail—they’ve achieved something they’ve worked hard for, but the real test comes after the title. Among the best collaborators I’ve worked with are those who make this transition not just about themselves, but about the people around them. They don’t just take on responsibility; they elevate everyone involved.

This isn’t about avoiding mistakes—it’s about embracing growth and collaboration. These are the traits that make someone truly great to work with.

The Strengths of Outstanding Leaders

The best people in new roles have a way of turning potential vulnerabilities into opportunities for connection. They do this by focusing on a few key behaviors:

Sharing Context: They understand that information is most valuable when it’s shared. Instead of hoarding knowledge, they ensure everyone is aligned and equipped to contribute meaningfully.
Seeking Input: They’re not afraid to admit they don’t know everything. By inviting perspectives, they build trust and create space for better solutions.
Celebrating Collaboration: They recognize that working with others isn’t a weakness—it’s the key to collective success.

These behaviors build trust, foster innovation, and make collaboration not just productive but genuinely enjoyable.

The Impact of Great Collaborators

When someone approaches leadership with humility and openness, it transforms the way teams function. Here’s what I’ve noticed about the best collaborators:

They Remove Obstacles: By sharing context and being transparent, they make it easier for everyone to do their best work.
They Build Trust: Open communication creates an environment where people feel safe to share ideas, admit mistakes, and ask for help.
They Inspire Confidence: By valuing input and celebrating contributions, they make their teammates feel seen and appreciated.

This dynamic doesn’t just improve outcomes—it strengthens relationships and creates a sense of shared purpose.

How to Foster Collaborative Intersections

The magic happens at the intersections where collaboration thrives. Here’s what the best people I’ve worked with do to make that happen:

For New Leaders

Share Context Freely
Ask for Input
Celebrate Wins Together

For Teammates

Be Proactive in Offering Support
Focus on Solutions
Build Relationships Through Transparency

What Great Collaboration Looks Like

The best collaborators understand that leadership isn’t about having all the answers. It’s about creating an environment where everyone can thrive. They model humility, transparency, and curiosity, which in turn inspires their teammates to do the same.

Collaboration is a two-way street. When leaders and teammates bring their best selves to the table, the result is more than just successful projects—it’s a culture of trust and mutual growth.

Closing Thoughts

If you’re stepping into a new role, remember that your title isn’t the end of the journey—it’s the beginning. And if you’re working with someone in that position, focus on creating collaborative intersections where both sides can learn and grow.

The best people I’ve worked with know this: Together, we’re not just chasing tails—we’re building something better.

Stand Up and Fight: Running the Gauntlet of Change

Sun, 12 Jan 2025 00:00:00 -0600

Change, whether in ourselves or the systems we inhabit, is rarely easy. It’s a battle—a gauntlet—of meetings, justifications, setbacks, and uncertainty. For anyone who’s fought to make a project, a vision, or even a career change a reality, the battlefield can feel endless and isolating. But it’s not insurmountable.

Dropkick Murphys’ “The Gauntlet” captures the essence of that struggle. Its lyrics, steeped in resilience and determination, provide a framework for how to approach the battlefield of change and emerge stronger, even when the odds feel stacked against you.

“When the walls are closing in…”

“I was weighing in heavy but still feeling alright…”

I’ve stood at the edge of uncertainty, from my blue-collar roots to transitioning into a career in technology. Changing my life wasn’t a sure thing—there was no guarantee I’d succeed. The walls often felt like they were closing in, whether it was self-doubt or the resistance I encountered in systems that didn’t want to change.

The key was recognizing that the weight of those challenges didn’t define me. I had to remind myself: feeling the weight is part of the process. You’re not failing because it’s hard—you’re growing because you keep going despite it.

“Do you think we’re gonna make it? / I don’t know unless we try…”

“You could sit here scared to move or we could take them by surprise.”

This lyric speaks directly to the core of action. There’s a moment in every battle—whether it’s for a professional goal, a personal vision, or systemic change—where you face a choice: sit back, or step forward.

For me, stepping forward meant planting seeds long before anyone could see their value. It meant justifying solutions in meeting after meeting, facing skepticism, and holding onto the belief that what I was doing mattered, even when the results weren’t immediate. The lesson? You won’t know if you can make it until you try. And trying means taking the first step, even when success feels uncertain.

“They’re gonna prey upon your weakness…”

“No man’s soul is ever spared.”

In every gauntlet, your weaknesses will be tested. I learned this early—both in labor-intensive jobs and in white-collar environments. People will question your vision, your ability, and even your motives. Systems will resist change, and you’ll be forced to confront your own fears and insecurities.

The only way to survive is to prepare. Know your vulnerabilities and build resilience. When I entered tech, I didn’t have all the answers, but I was relentless in learning, adapting, and improving. That’s how you protect your soul: by refusing to let the doubts—whether internal or external—define you.

“You’ve got to stand up, yeah, and fight them…”

“Show them what it’s all about.”

This is the anthem of every meeting where I’ve had to fight for solutions that weren’t immediately obvious to others. The project no one believed in. The processes that felt too ambitious. The long, uphill battle of transforming legacy systems that others had given up on. Each of these moments was a fight—not against people, but against inertia, apathy, and fear of change.

Standing up means having clarity of purpose and the courage to see it through. It’s not about aggression—it’s about conviction. When I’ve stood up in meetings, it’s been with a mindset of collaboration, even when I’ve had to fight for my vision. Every fight was a step forward.

“Stand up and fight! / And I’ll stand up with you…”

“We shall succeed.”

The journey is never a solo endeavor. I’ve leaned on mentors, partners, and colleagues who believed in me when I struggled to believe in myself. And I’ve tried to be that support for others—encouraging them to stand up and fight for their own visions.

This lyric reminds us that we’re not alone. Whether you’re leading a team or finding your way in a new role, solidarity matters. When you stand up for what’s right, you inspire others to do the same. Together, you can achieve more than you ever could alone.

“They won’t get me, they won’t get me…”

“I would rather fight and die.”

There were times when the resistance felt overwhelming—when my ideas were dismissed or my confidence was shaken. But this lyric became my mantra. It’s a reminder that standing your ground, even when it’s hard, is better than compromising your values or vision.

Not every battle will be won, and not every seed will grow. But the act of fighting for what matters—to you, to your team, to your organization—is its own reward. It’s how you grow, learn, and ultimately succeed.

A Call to Action: Running Your Gauntlet

To anyone facing their own gauntlet—whether it’s changing your career, transforming a system, or realizing a personal vision—this is your moment to stand up and fight. Here’s what I’ve learned:

Prepare for the unexpected. The path won’t be what you think, but that’s part of the process.
Focus on what you can control. Plant the seeds, even when others can’t see their value yet.
Lean on others. You don’t have to fight alone. Build a network of people who will stand with you.
Keep moving forward. Progress is slow, but every step matters.

The gauntlet isn’t just a struggle—it’s a transformation. It’s where you find out who you are and what you’re capable of. And when you emerge on the other side, you’ll know: the fight was worth it.

So, what’s your gauntlet? Will you stand up and fight?

From Yossarian to Orr: Moving From Seeing the Problem to Solving It

Fri, 10 Jan 2025 00:00:00 -0600

There was only one catch and that was Catch-22, which specified that a concern for one’s safety in the face of dangers that were real and immediate was the process of a rational mind. Orr was crazy and could be grounded. All he had to do was ask; and as soon as he did, he would no longer be crazy and would have to fly more missions. Orr would be crazy to fly more missions and sane if he didn’t, but if he was sane he had to fly them. If he flew them he was crazy and didn’t have to; but if he didn’t want to he was sane and had to. Yossarian was moved very deeply by the absolute simplicity of this clause of Catch-22 and let out a respectful whistle. “That’s some catch, that Catch-22,” he observed. “It’s the best there is,” Doc Daneeka agreed.

For much of my life, I’ve felt like Yossarian from Catch-22. Trapped in systems that felt absurd, unyielding, and indifferent, I could see the problems clearly—how the rules worked against me and others, how progress was stifled by inefficiency and fear. But like Yossarian, I felt helpless to do anything about it. I raged, I resisted, and I tried to fight the system head-on. But the system didn’t budge.

It wasn’t until I started thinking more like Orr, Yossarian’s quietly brilliant counterpart, that I began to make real progress. Orr didn’t just see the problem—he acted. While others raged against the machine, Orr spent his time preparing. He crash-landed planes to perfect his survival tactics. He didn’t waste energy fighting battles he couldn’t win. He studied the system, found its cracks, and created a way out.

That shift—from seeing the problem to solving it—has been transformational for me.

The Lesson: Seeing Isn’t Enough

Yossarian and Orr both understood the absurdity of the system, but their responses couldn’t have been more different. Yossarian fought against it, growing increasingly frustrated and hopeless. Orr, on the other hand, accepted the system’s absurdity but refused to let it define him. He focused on what he could control, planned meticulously, and eventually outmaneuvered the system entirely.

For a long time, I was stuck in Yossarian’s mindset. I saw the flaws, the inefficiencies, the roadblocks, and I let my frustration and anger take the lead. I thought if I pushed harder, if I fought more, I could break through. But all I did was burn myself out. The system didn’t change—but I had to.

The Shift to Orr: What I’ve Learned

Here’s what moving from Yossarian to Orr has taught me:

Calm Is a Superpower
Focus on What You Can Control
Learn the Rules to Rewrite Them
Prepare for the Long Game

Moving Forward With Purpose

Many of us feel like Yossarian at some point—seeing the problems in our systems but feeling powerless to address them. It’s an overwhelming place to be. But we don’t have to stay there. By shifting our mindset and actions, we can move from frustration to strategy, from reacting to creating.

The journey from Yossarian to Orr isn’t easy. It requires patience, clarity, and focus. But the rewards are worth it. When we stop fighting against the system and start thinking our way through it, we create something far more powerful than resistance: real progress.

So, if you’re feeling stuck or overwhelmed, ask yourself: What would Orr do? How can you prepare, adapt, and quietly build your path forward? The answer might surprise you—and it might just set you free.

Image sourced from Wikimedia Commons: https://commons.wikimedia.org/wiki/File:Catch22-1970_opening.jpg
Quote by Joseph Heller author Catch-22 sourced from Goodreads

Practice vs. Repetition: The Key to Real Growth

Sat, 04 Jan 2025 00:00:00 -0600

We’ve all heard the phrase, “Practice makes perfect.” But does it? Not really.

Practice doesn’t make perfect. It makes you better. But only if you’re doing it right.

Here’s the thing: practice and repetition are not the same. Repetition—mindlessly doing the same thing over and over—will only make you better at doing that one specific thing, flaws and all. Practice, on the other hand, is intentional. It involves analyzing, experimenting, reflecting, and improving as you go.

Think about it this way:

Repetition is attempting the same skateboard trick in place, never adjusting your approach.
Practice is trying that trick on a winding skate park path—learning, falling, and progressing toward landing it.

Why Practice Matters

Practice is like paying into the “mortgage” of your skills. Every session is an investment in future returns. Sometimes the return is huge, and you see massive improvement. Other times, it’s smaller—a fractional gain. But here’s the kicker: you always get something. Even if the return is just the knowledge that you weren’t meant to pursue that skill long-term, you’ve learned something valuable.

When I was reteaching myself skateboarding in my 40s, I had to accept the limits in my practice. I had to adjust my expectations so I could work through significant challenges and fears. Before each trick, I would repeat to myself, “All that matters is the rideaway.” Pushing through the fear of falling or failing, I focused on following through—on finishing the trick, no matter the outcome. What I was really practicing wasn’t just the trick—it was commitment.

I even wrote it on my griptape as a psychological reminder every time I looked down at my board before a run at the curb, an obstacle, or dropping in on a ramp. All that mattered was the rideaway—and that required commitment.

Embrace Imperfection

We live in a world obsessed with perfection. But here’s the truth: the perfect product, system, or performance doesn’t exist. What does exist is the willingness to create something, no matter how “crappy” it seems at first. That’s where growth happens.

Some of the most successful companies and systems in the world started as messy, flawed experiments. I’ve seen it firsthand: imperfect products being used by real customers, while the “perfect” systems remain stuck in development.

The lesson? Execution beats perfection. The willingness to act—to create, learn, and refine—is what drives real progress.

What About You?

Are you practicing with intention or just repeating?
How do you balance imperfection with progress?

I’d love to hear your thoughts. Share your experiences in the comments—let’s start a conversation about how we can grow smarter, not just harder.

What Seasoned Developers Forget About Starting Out

Sat, 28 Dec 2024 00:00:00 -0600

Sitting with a half-dozen senior technologists at my local user group, we were joined by half as many junior developers eager to learn. After all, they came to a software craftsmanship meetup—they were ready to soak up knowledge.

The seasoned developers among us started chatting about our work challenges. We felt so smart, sharing our hard-earned wisdom. Then, one of the junior members asked a simple yet profound question:

"Do you have any career advice?"

Naturally, we responded with advice tailored to the problems we’re dealing with today—problems shaped by 20+ years in the industry. I can’t recall exactly what we said, but looking back, it didn’t matter. It was meaningless to someone just starting out.

That realization hit me. Our advice was for people with decades of experience, not for someone navigating today’s entry-level job market—a landscape vastly different from the one we entered.

So, I paused and reframed the conversation.

I asked the junior developer, "What’s your language?" Whatever they said, I told them it was perfect. Because it is—it’s their language. It’s the foundation of their journey, and there’s no point arguing otherwise.

I shared what I hoped was more practical advice:

Focus on your toolkit. Master your language, learn to write tests, and understand your build scripts.
Spend time optimizing your environment. Learn your IDE, terminal, and editor.
Find resources that teach fundamentals in a fun and engaging way. I love Dave Farley’s work, but I also recommend checking out someone like The Primeagen on YouTube. Keep an open mind!
Explore tools like ChatGPT—but learn their limits as well as their strengths.
Attend user groups, webinars, and meetups. Surround yourself with people who share your curiosity.
Be patient with Agile, TDD, or any process your company uses. Pay attention to the pain points—they’re often signaling something deeper.

For those of us further along in our careers, it’s tempting to offer advice that mirrors our own paths or solves the challenges we face today. But we must remember: there’s a 20-year gap between their now and our today.

People need space to learn how to learn. They need room to discover what we often take for granted. Let’s not forget what it felt like to not know yet.

Mentorship Starts With a Conversation

Sat, 28 Dec 2024 00:00:00 -0600

If you're a senior developer working with colleagues just a few years junior to you, you already have everything you need to be a mentor. It doesn’t take years of preparation or a formal program to begin—it starts with curiosity and conversation.

Ask about their setup:

"Which fonts do you use in your editor?"
"Oh, you use X IDE? How do you like that workflow?"
"I noticed you use X technique for this task. That’s cool—here’s how I approach it with Y. I like what you did with X—maybe I can integrate that into my process."

These small exchanges are the first steps towards mentorship. When you open the door by being curious and genuinely interested in how someone works, you show respect for their ideas. You also set the stage for mutual learning—mentorship isn’t a one-way street.

When you engage this way, you build confidence:

You’re implicitly saying, “What you do matters.”
Recognizing their strengths helps junior developers feel valued.

And mentorship is a learning opportunity for you, too. Junior developers often bring fresh ideas or approaches you might not have considered. By being curious, you might discover something new or see a challenge from a different perspective.

Mentorship also makes collaboration easier. When people feel heard and supported, they’re more likely to share ideas and ask for help. A team where everyone feels valued—regardless of experience—works more cohesively.

Start small:

Invite someone to pair program.
Ask for their opinion during a code review and explain why you value it.
Share a small trick you’ve picked up, and ask if they have one to share.

These conversations build trust and open the door for deeper collaboration.

Mentorship doesn’t have to be formal or intimidating. It begins with respect, curiosity, and a willingness to learn from each other.

So go ahead: ask about their fonts. Ask about their techniques. Watch how these simple conversations transform your relationships, your team, and even your own perspective on growth.

Leverage the "J" in JRuby for Powerful Concurrency

Mon, 27 Apr 2015 00:00:00 -0500

I was working on a project that required some heavy-weight processing of links to determine if they were valid based on a variety of criteria. Since the standard Ruby interpreter was running each process sequentially the naive approach was taking a prohibitively long time. Fortunately this was a simple pure Ruby problem and each record was processed independently of each other this was a good opportunity to use JRuby and it’s Java interoperability to get some real concurrency power.

Using the ruby-concurrent library and JRuby Interop I first load in the Java Futures libraries.

java_import java.util.concurrent.Callable
java_import java.util.concurrent.Executors
java_import java.util.concurrent.FutureTask
java_import java.util.concurrent.LinkedBlockingQueue
java_import java.util.concurrent.ThreadPoolExecutor
java_import java.util.concurrent.TimeUnit

Since the goal is to squeeze as many executions as possible I set the pool size to saturate all available cores.

POOL_SIZE = java.lang.Runtime.getRuntime.availableProcessors * 8

The application reads in a CSV and writes each row into a threadsafe array for later processing. Since the input itself wasn’t the bottleneck sequentially reading in the file had little impact on the execution time.

class App
  def initialize(file_to_process)
    @queue = ThreadSafe::Array.new

    CSV.foreach(file_to_process, 'r') do |row|
      @queue.push(row)
    end
  end

App.work sets up the futures creation and execution. I looped over the queue of rows and create a new Worker (defined below) and hand that off to the Java Future in preparation for execution. Again, the list of tasks in the queue wasn’t the bottle next so enumerating over the queue was not a significant impact on the execution performance.

  def work
    tasks = ThreadSafe::Array.new

    executor = ThreadPoolExecutor.new(POOL_SIZE, POOL_SIZE, 60, TimeUnit::SECONDS, LinkedBlockingQueue.new)

    while @queue.size > 0
      row = @queue.pop
      email = row.shift
      task = FutureTask.new(Worker.new(email, row))
      executor.execute(task)
      tasks.push(task)
    end

As each future completes it’s work the tasks array enumerates the results of the worker execution. In this case I’m just writing the output to STDOUT.

    tasks.each do |t|
      result = t.get

      if result[:status] == :passed
        $stdout.puts([result[:email], result[:data]].flatten.to_csv)
      else
        $stderr.puts([result[:input], result[:data], result[:reason]].flatten.to_csv)
      end
    end

    executor.shutdown
  end

Worker implements the actual reason for the script. We include Java’s Callable module so we can work with the FutureTask defined above.

  class Worker
    include java.util.concurrent.Callable

This code is less important but represents some of the work being done. It was a rough experiment and the data was a mess. The scrub_input was kind of a work in progress.

    attr_reader :input
    attr_reader :data

    def initialize(email, data)
      @input = email
      @data = data
    end

    def scrub_input
      @input
        .sub(/^(%20|%3c|%22)+/, '')
        .sub(/^(\\)+/, '')
        .sub(/(%20|%3c|%22)+$/, '')
        .sub(/^[-.]+/, '')
        .sub(/^#+/, '')
    end

Since the rules were being implemented in a plugin style I had a little fun with the naming. I’ll leave the references up to you.

    def call
      email = scrub_input

      inspector = Schrute::BeetInspector.new(email, [
        Schrute::Beets::TldBeet,
        Schrute::Beets::DomainBeet,
        Schrute::Beets::LocalpartBeet,
        Schrute::Beets::SuppressionListBeet,
        Schrute::Beets::KeywordBeet,
        Schrute::Beets::TelnetBeet
      ]).call

Here I take the result of the input inspector and format it so it can be returned and handled by the executor.

      status = inspector.passed? ? :passed : :failed

      {
        status: status,
        email: email,
        input: input,
        data: data,
        reason: inspector.result[:evaluation].last.reasons
      }
    end
  end
end

Since the code was implemented in a single script file the execution is defined at the bottom.

file_to_process = ARGV[0]
fail "Usage: process <file_to_process.csv>" unless file_to_process

App.new(file_to_process).work

The original gist is up on GitHub. In the end using this technique reduced a multiple hour process into a few minutes. There was some tweaking for handling particularly slow Beets but those were separate issues entirely.

Using Postgres RegEx Expressions to Find Very Specific Matches

Wed, 25 Feb 2015 00:00:00 -0600

Coderwall has been having issues with certain avatars generating 403 errors in the browser console. You probably wouldn’t notice unless you had your dev tools open while you were browsing but there were a little over 25% of our Twitter avatars that weren’t rendering properly due to trying to connect via HTTP instead of HTTPS. (And other changes to how Twitter resolves it’s profile images but that’s a bigger issue.) Fortunately with the power of Ruby and Postgres RegEx selectors it’s relatively trivial to find and transform the HTTP urls to use HTTPS.

User.where("twitter_token is not null AND thumbnail_url ~ '^https:' AND thumbnail_url ~ 'twimg\.com'").find_each(batch_size: 500) do |user|
  begin
    url = URI.parse(user.profile_url)
    puts "Update #{user.username} because #{user.profile_url} appears to be HTTP."
    url.scheme = 'https'
    user.update_attribute(:thumbnail_url, url.to_s)
    puts " ==> #{user.profile_url}"
  rescue URI::InvalidURIError
    ap url
  end
end

Our User model has a field thumbnail_url which holds the URL for users who log into Coderwall via OAuth. Since the issue was currently a problem predominantly for Twitter logins, and LinkedIn doesn’t allow for fetching the thumbnails via HTTPS, I first limited the query to known Twitter login users.

Next I want to filter by users who have thumbnail_url’s that are not already using HTTPS. That number was near-zero after some poking I did to verify the issue, but better to be safe than sorry and it also helps with re-running the script, no sense in selecting a record that’s already been updated. I used the Postgres RegEx matcher thumbnail_url ~ '^https:' but could very well have used thumbnail_url ilike 'https:%' which can still utilize some indexes if available. The ilike vs like is also preferable in this case because it is case-insensitive

The last part of the query thumbnail_url ~ 'twimg\.com' could have also been thumbnail_url ilike '%twimg.com%' but was used because I was refactoring from matchers that were inside the block as I was testing this little bit of functionality.

Then I used the find_each(batch_size: 500) to fetch the records in batches of 500 to avoid excessive queries. Given this batch size I did about 56+ selects instead of 28,000+.

We can fetch Avatars from a few different places so we abstract the url via the profile_url method. I could have just fetched from thumbnail_url but it didn’t make any difference in this case. I load the url into URI.parse so I can manipulate the url without string manipulation. I convert the scheme on the URI instance and then update the attribute on the model. The puts and ap (awesome_print) statements are just there to help me as I watch the process run.

While the query could have further been simplified via ilike wildcard statements the Postgres RegEx expressions are very useful for matching data inside a Postgres instance and let you have extremely fine grained control over the your results without having to pull more than you absolutely must from the database. They come at a cost of being rather non-index friendly but they are a useful tool to have at your disposal when you need it.

Improve Case-Insensitive Queries in PostgreSQL Using Smarter Indexes

Wed, 25 Feb 2015 00:00:00 -0600

One of the unique features of Postgres is it’s powerful index engine. Using Postgres you can get much more fine grained control over how your data is indexed. For example indexes on expressions which allow you to create indexes on fields that have UPPER or LOWER functions applied to them.

Typically a VARCHAR field is case-sensitive in Postgres. Meaning that fieldname = 'FOO' and fieldname = 'foo' won’t match when the actual value is “FOO”. A common technique is to normalize the field value like lower(fieldname) = lower('FOO') to coerce the fields to match using their lower-case form. The problem is that this will ignore indexes and cause Postgres to use a Sequential Scan to find the match evaluating each row looking for a match. This is expensive and non-ideal for large and frequently queried tables.

explain select username from users where lower(username) = lower('just3ws');
                        QUERY PLAN
-----------------------------------------------------------
 Seq Scan on users  (cost=0.00..13327.36 rows=558 width=9)
   Filter: (lower((username)::text) = 'just3ws'::text)
(2 rows)

Compare that to the query with no expression and a simple index on the username field.

explain select username from users where username = lower('just3ws');
                                     QUERY PLAN
-------------------------------------------------------------------------------------
 Index Scan using index_users_on_username on users  (cost=0.00..4.07 rows=1 width=9)
   Index Cond: ((username)::text = 'just3ws'::text)
(2 rows)

There’s a significant cost to pay when querying against expressions. But all is not lost. Postgres will let you build indexes against expressions.

In this case we’ll apply a index that will take the lower() expression into account.

create index ix_users_username_lower on users (lower(username) varchar_pattern_ops);

Now when we query for lower(usernames) we’ll be able to take advantage of the index to avoid full table scanning.

explain select username from users where lower(username) = lower('just3ws');
                                       QUERY PLAN
----------------------------------------------------------------------------------------
 Bitmap Heap Scan on users  (cost=4.92..988.43 rows=558 width=9)
   Recheck Cond: (lower((username)::text) = 'just3ws'::text)
   ->  Bitmap Index Scan on ix_users_username_lower  (cost=0.00..4.90 rows=558 width=0)
         Index Cond: (lower((username)::text) = 'just3ws'::text)
(4 rows)

It’s much better than the Sequential Scan now although still a little bit slower than just querying against the simple index.

The Bitmap Heap Scan is useful when there is a lot of variety in the data and Postgres is able to intelligently segregate the data. Basically the data is chunked into smaller sets that Postgres can filter though and more intelligently decide which sets to scan and which to skip. Where the Sequential Scan will touch every single row in the table.

Read more about the Postgres Index on Expressions in the official documentation and this explanation by the author of the Postgres Bitmap Heap Scan algorithm Tom Lane.

For a full explanation of what the cost, rows, and width values mean please check out Using Explain from the Postgres documentation.

varchar_pattern_ops is explained in Postgres Index documentation.

360 Learning at User Groups

Wed, 26 Sep 2012 00:00:00 -0500

Retrospective

This article reflects on the idea that learning at user groups is multi-directional: the speaker, the audience, and the organizer all learn in different ways at the same time. The key insight is that facilitation is an active craft, and that “360 learning” emerges when the group creates space for questions, pacing, and shared problem-solving.

Original text

First a small plug for my user-group community.

[Software Craftsmanship North America](http://mchenry.softwarecraftsmanship.org) (SCMC) is a group that meets once a month at [Follett Software Company](http://www.follettsoftware.com/) in the far-northwestern suburbs of Chicago. We’re a diverse group of individuals with members in their teens all the way up to the great grandparents of software development. It’s a lot of fun and we always learn something at each meeting.

There’s more to learn than just the topic at User-groups.

I think that user-group meeting topics are just the tip of the learning possibilities at user-group meetings but you have to take a step back to get the full picture.

Let’s paint the scene. Last night [Surya Gaddipati](http://twitter.com/suryagaddipati) was presenting on his work in building [LINQR](https://github.com/suryagaddipati/linqr), a [LINQ DSL in Ruby](http://www.meetup.com/Software-Craftsmanship-McHenry-County/events/79576612/). He was presenting to 11 software professionals who were mostly versed in Java and C++ programming.

Let’s look at the possibilities for learning within the group…

The speaker who’s creating a very cool set of utilities for Ruby was presenting on a very dense set of topics for the first time.
Many people in the audience were not .NET developers or Ruby developers so they were simultaneously trying to absorb the DSL concepts but also enough Ruby and .NET concepts for it to make sense.
As the meeting facilitator I learned a lot about the dynamic of the group.

This multi-faceted learning is what I think is very unique about user-groups. I’ll write a comparison of tech conference learning opportunities in another post.

What did the speaker learn?

Don’t try to pack too much information into one meeting.

Remember over the months and years you’ve spent learning or building whatever your presenting on that there’s almost no way to summarize that down into a one or two hour session. You need to choose to go deep or wide. If you go deep then you’ll need to pick one facet and just focus on that bringing in only enough to support that topic. If you go wide you’ll likely be discussing things in broad stokes, only giving enough detail for context.

Lean on your organizer.

If you have any trouble with technical aspects or with how to engage your audience, then speak to the organizer. They’re there to make sure everyone has a good time and gets as much value as possible. If you’re stuck then mention it, your organizer probably knows the technical difficulties already and can rescue you quickly. If your audience is a sea of blank faces sometimes engaging your organizer directly can give them a clue that you need some more interaction and they can help with engaging the group on your behalf.

Lean on your audience.

Most of the time the audience is very technical and has something to offer besides attention. If you do get stuck it’s also okay to say, “Ugh. I can’t remember how to set the color scheme on my Vim, does anyone know how to change that?” It’s hard to remember these kinds of things when you’re under pressure in front of a live audience. By breaking the “fourth wall” and asking for help you’ve let the audience in on you a little and they’ll often be more patient, understanding and engaged because you’ve let some of your humanity show.

What did the audience learn?

Know when the firehouse is open too wide.

Sometimes when there’s just too much information to be synthesized all at once audiences will typically kind of shutdown and become less likely to ask questions. This is your chance as an organizer to interject with a question or try to work with the speaker and audience to figure out what’s the right level of content for people to get value. If things are too high-level for the audience they’ll leave more confused but too low-level and they’ll get bored and just leave. I like to sometimes start with a question to the speaker and then turn it back around to the group to encourage feedback and interaction.

What did I as the facilitator learn?

You know your group better than your speaker does.

Even if you’re getting a presenter who’s a regular member of the group they’re probably not experienced in reading the body language of the people in the group yet. As the group leader you’ve had a lot more chances to see how your people react in different situations.

If you the group getting uncomfortable with the pace of a presentation then maybe take a moment to ask a question or make a comment that we might need to slow down a bit or speed up the presentation a little. I’ve interjected with “That’s neat. Can you show us an example?” or be the first to plead ignorance “I’m sorry I didn’t understand what you meant by ‘Foo bar baz’?”. These can give clues to the presenter and also break the ice for the other people in the audience to ask their own questions.

Save a struggling presenter.

Even if we’ve practiced our talks sometimes things go wrong. If the presenter seems to be stuck with a technical problem or just seems to be getting a bit nervous then you should give them a break and move the focus off them so they can recover.

If they’re having trouble with the keyboard or projector during a presentation and seem to be struggling to catch up that will usually escalate whatever their anxiety levels might already be from public speaking. Take a chance to get everyone who’s staring at them to look away. Mention that there’s still food, suggest a short break or start a side-conversation. That takes the spotlight off the presenter and then you can move in to help resolve the issue, offer a few words of encouragement and then prepare to resume the presentation.

Bringing it all around.

The concept of 360 degrees of learning is that everyone has a chance to learn, the facilitator, the presenter and the audience. The learning opportunities come full circle and that’s something that is easier to do in small groups that meet somewhat frequently. This 360 degree learning is something I didn’t anticipate when I started SCMC but something I’ve learned to value and is partly why I want to support user-group communities through UGtastic. When we have such opportunities to learn I can’t help but say, “User-groups? Fantastic!”.