TL;DR
In 1997, my family got our first computer—a Windows dinosaur with a little skiing game called SkiFree. At seven years old, I started pulling it apart with library books, trying to figure out what it was written in and how it worked. I pushed that machine past its limits repeatedly—tinkering with frame rate and swapping graphics with my own (terrible) drawings—until I broke the game more than once. That was also the moment my “engineering habit” was born: I started writing down what I changed, what happened, and what I’d try next. That early loop—curiosity → experiment → break → document → improve—is still the core of how I build today.

---

In 1997, William Clarke—Bill—brought my mom our family’s first computer.

It wasn’t sleek. It wasn’t fast. It was a Windows dinosaur. But to me, it might as well have been a portal.

It came with a game that, if you know it, you know it: SkiFree. You’d ski downhill, dodging trees and outrunning a yeti that eventually showed up to ruin your day. Simple, funny, and addictive in that late-90s way where the game didn’t need photorealism to feel like magic.

That game is where my tech story starts—not because it made me want to be a “developer,” but because it made me want to understand why things worked… and what would happen if I changed them.

---

The First Program I Tried to Take Apart

At seven years old, I didn’t have a roadmap. I didn’t have a mentor explaining code. I had curiosity, stubbornness, and whatever I could get my hands on.

So I did what a lot of self-taught builders do when they don’t have access to formal instruction: I went to the library.

I started checking out books trying to figure out basic questions like:

• What language is this written in?

• Where does the game store its graphics?

• What controls speed and frame rate?

• What does changing one part of the program do to everything else?

I didn’t even know the vocabulary for half of what I was doing. But I understood cause and effect. Change something, see what happens. Change something else, see what breaks.

That became the pattern.

---

I Kept Breaking the Game (and the Machine)

I wasn’t satisfied just playing SkiFree. I wanted to touch the machinery.

So I started tinkering with:

• frame rate (or what I thought was frame rate at the time)

• behavior and feel

• and most memorably… the graphics

I swapped in my own “art creations.” To be clear: my graphics were horrible. Even for the time. I was seven. But the quality didn’t matter—the fact that I could change anything at all was the hook.

And I pushed that poor machine hard.

I burned out that computer’s ability to run the game multiple times while I experimented. Sometimes I’d improve something. Sometimes I’d make it unplayable. Sometimes I’d break it so completely that the only option was to back out, undo, or start over.

Looking back, that’s basically the earliest form of:

• performance tuning

• regression testing

• rollback planning

• and learning that changes have consequences

I didn’t have those words yet, but I was already living the reality.

---

Where Documentation Started (Before I Even Knew It Had a Name)

Here’s the part that still defines how I work today:

I started writing everything down.

Loose leaf paper. Notebooks. Whatever I had.

I would document:

• what I changed

• what happened

• what got worse

• what got better

• what I thought I should try next

I wasn’t doing it because someone told me it was “best practice.” I was doing it because I didn’t want to waste time repeating the same mistakes, and because I wanted to be able to return to a good version after breaking everything.

That’s the moment my documentation priority emerged.

When you’re learning under constraints, documentation isn’t corporate overhead—it’s survival. It’s how you keep forward progress when you don’t have perfect tools or unlimited time.

That habit stuck.

---

The Lesson I Carried Forward

This early experience taught me a few principles that show up in my work now—whether I’m building custom software, optimizing WordPress performance, or operating a web platform:

1) Curiosity is good. Unmeasured curiosity is expensive.

Experimentation is powerful—but without measurement and recordkeeping, it becomes thrash.

2) Breaking things is part of building—if you can roll back

If you can’t undo a change, you’re gambling. Even at seven, I learned the value of a “known good state.”

3) Documentation isn’t paperwork; it’s leverage

When you write down what happened, you accelerate learning, reduce rework, and make systems safer to evolve.

4) Performance is a system, not a trick

If you push the machine too hard, it fails. Performance isn’t “one setting.” It’s how everything interacts under load.

---

Why This Still Matters Today

It might sound funny to trace a professional mindset back to SkiFree. But that’s honestly where it started: the instinct to understand the system, test changes, and document outcomes.

Today the systems are bigger, the stakes are higher, and the tooling is better—but the operating loop is the same:

Curiosity → experiment → measure → document → improve → protect against regression

That’s what performance engineering is. That’s what WebOps is. That’s what disciplined software development is.

And it started for me at seven years old on a Windows dinosaur, chasing a yeti downhill.

---

Next in the Biography Series

In the next post, I’ll talk about how that early “break it, fix it, document it” habit evolved into real-world workflows—building under constraints, learning to ship reliably, and why I treat websites like production systems instead of one-time design projects.

---

Want to talk?

If you’re looking for someone who brings that same discipline to modern platforms—WordPress performance, technical SEO enablement, hardened hosting, monitoring, and clean delivery—book a call and tell me what you’re trying to build (or stabilize).