How I Learned to Stop Panicking and Love the Hack

Perfect code doesn’t matter as much as you think

In January 2010, I moved from Chicago to San Francisco to work at YouTube. After an amazing interview with super-smart folks, I was excited to learn how to develop software the Right Way in the big leagues.

In the end, I learned more than I had hoped for — but only after coming to terms with the Right Way being nothing like what I expected.

My previous gig was at a tiny network security infrastructure startup, where I was the sole UI engineer responsible for designing and building the web console.

As an inexperienced recent grad and minor obsessive-compulsive, I built my web console as a perfect HTML-validation-passing, gracefully degrading masterpiece of markup. I was the only engineer working on it, so the code was exactly as I wanted it to be. Every piece was hand-crafted for a purpose.

Of course, nobody used it. We only had a handful of beta users.

Shortly after I left, the company was sold and my HTML-and-CSS opus was shuttered.

I wanted to work on a popular, user-facing product that people loved. At the same time, I figured I could learn from the best: How to better organize my code; how to build meaningful tests — how to take my artful work to the next level.

Fast-forward to April 2010, three months into working at YouTube.

A mutual friend arranged for me to have dinner with the CTO of a now-very-well-known startup. The CTO guy was nice. He talked about how great the startup was for a bit, half-pitching, and I was almost completely not paying attention. Finally, he asked what I was up to.

I painfully described some of the code I was tasked with fixing at YouTube, which I’d spent months editing at this point.

One low-traffic page I had just been working on contained <script> blocks that opened popup windows with more script blocks, calling back into the parent window to submit forms. All this JavaScript lived in the global scope, sometimes output multiple times, formatted inside crazy long-forgotten python modules. Worse, everything was triggered by more upside-down JavaScript living in huge onclick attributes. It was nearly incomprehensible.

Once I got going, I couldn’t stop bitching to this guy I barely knew. I spewed perfectly fermented vitriol — I had all the hyperbole just right after months of untangling twisted code. It was the stuff of perfectionist nightmares.

“And. On top of everything. They. use. tabs!”

I had moved across the country to learn the Right Way to build web software, but it seemed like everything about the front-end code there was wrong.

The guy paid the check, and we didn’t meet again.

I kept panicking for another month or so, until a good friend slapped me on the face over IM and told me to quit being such an enormous baby. Recognizing the rare opportunity to stop before I’d gone too far, I started to think about things a little bit differently.

I stopped freaking out and stepped back from the code.

YouTube was a rocket ship. YouTube took off near-instantaneously, sold for $1.6 billion in its infancy, and managed to keep up with increasing demand ever since. Their audience is still growing at an astonishing rate.

The amazing engineers making all this possible were building things as fast as they possibly could with a small team. They didn’t have time to figure out a master plan and design all the perfect front-end architecture.

But they shipped, fast.

As a result, some parts of the code — especially the low-traffic pages — were a mess. But it didn’t matter — not one. single. bit. What mattered was the product: what users see and interact with.

Eventually, things started looking up. The engineering culture was coming around to the idea of more mature development process. YouTube, with several hundred engineers, wasn’t a little startup anymore.

During my two years at the company, we made great strides to rework a lot of the early front-end code, to reflect the more mature nature of the product.

We eliminated tons of global JavaScript and made the markup cleaner and simpler. We loaded fewer resources and did a better job caching them.

But I’m guessing none of the users noticed.

Writing beautiful code is not what makes your company or product successful. This might seem obvious, but it was not what I expected at the time.

My single biggest takeaway: Sometimes you need to use a bit of straight-up dirty code to get the job done when something needs to get out the door.

At my current gig, if cooking up a small hack is the best way to ship the feature faster — so be it. We’ll clean it up eventually.