You'll Always Remember Your First System

Early in my career I always panicked a little when beginning a new role. This time, I was really panicking.

I'd just joined a Ruby on Rails shop after spending years in the .NET world. The organization I was coming from ran an entire Microsoft stack down to the version control. My new role? A different programming language, a different database, different source control, it was all different!
​
I shared an office with the most senior developer there and every time I asked him a question his response was:

"Why would you ever do it that way?"

Every time I explained how I'd approach something, he'd look baffled. Short answers, deep voice. Not hostile exactly, just bewildered by my thought process.

The panic lasted for months.

When You Don't Even Know There Are Other Worldviews

Here's what I realize now: I only knew one way to do anything. I had taken Computer Science classes in college so programming in Ruby wasn’t too bad, but everything else. The source control, the ticketing system, package management, all the pieces to build a platform.

It can be hard to differentiate if something is standard practice or the way a certain system works if you have nothing to compare it to. I didn't know there were alternative approaches. My first team was small, isolated, and downsized. We had been sold off from a bigger company with multiple rounds of layoffs behind us. There wasn't room for "hey, why do we do it this way?" conversations when you're just trying to ship.

It's not like nowadays. It was the very beginning of Stack Overflow back then. Now there are so many more resources, especially online. You can see there are multiple ways to solve problems.

Things Started to Get Better

One time, colleagues and I were at a bar, and my officemate went over to another table to ask about an extra chair. Except he didn't really ask—he just sort of grunted and gestured. The people were completely taken aback.

That's when I realized: Oh. That's just how he is.

He wasn't being difficult with me. He was genuinely baffled. In his experience, nobody did it the way I described. He literally couldn't understand why anyone would. We became friends later, but I never told him about those panicked months.

The Pattern Emerges

With one system, you have "how it's done." With two systems, you have "the old way" and "the new way." With three or four systems, you start to see: "Oh. These are all just ways." You begin to know what patterns to apply and anti-patterns to avoid.

I built a new system at Cadasta, that was my third. But it was really at Wikimedia, my fourth system, where my eyes fully opened.

Wikimedia is an interesting mix of people who were on their first system for more than a decade and others that were coming in from a 5th or 6th or even greater systems. This often caused friction. One debate was often around immediate or eventual consistency. If you and I both edit the same Wikipedia page, the system handles it right away for editing. Compare that to Facebook, where if you and a friend comment at the same time, one comment might not show up immediately. That's eventual consistency.

The engineers who'd come from other distributed systems sometimes would struggle with this. They'd say, "Wikipedia does it this way, but I've also seen it work when..." They had reference points.

Why This Matters for Engineering Leaders

In hiring: A senior engineer from a single-company background brings deep expertise but narrow assumptions. They'll have strong opinions about "how things should be done" that are really "how my previous company did it." Evaluated for this.

In architecture decisions: When someone says "we've always done it this way," ask: we who? This team? This company? This industry?

In onboarding: How do you help someone distinguish "our way" from "industry standard"? One framework I love: "considering the outside view" a concept from Thinking, Fast and Slow by Daniel Kahneman. Do we have perspectives from other systems?

For mission-driven orgs: It's easy to take Silicon Valley patterns and assume they'll work because they worked for Google. I've also seen NGOs that refuse to learn anything from for-profit companies. They spend months inventing frameworks unnecessarily.

The question isn't "is this how successful companies do it?" The question is: "What's universal, what's contextual, and what serves our mission?"

How to Spot This

Listen for the language:

• "That's how it's done" vs. "That's how we did it at Company X"
• "That won't work" vs. "I haven't seen that work, but I've only worked with..."

Watch for:

• Confidence without curiosity
• Defensiveness when asked "why do you approach it that way?"

Ask yourself:

• Does my team have enough varied experience to challenge assumptions?
• Have I only worked with one approach to [tech stack / org structure / decision framework]?
• When I think "that's wrong," am I defending a principle or just what I know?

What I'd Tell My Younger Self

I think about that version of me, sitting in that office for months, panicking. I feel compassion for her. She needed a mentor.

I'd tell her: You don't have another worldview yet. That's okay.

Ask questions. And your officemate? That's just how he is. It's not personal.

You'll get to a third system, then a fourth. You'll learn to distinguish between what's universal and what's just familiar.

And eventually, you'll be able to help someone else who's in their first system, panicking, not even knowing that other worldviews exist.

What was your first system? What have you learned about that system now that you have learned from other systems?

-Kate