Give A Damn

I want to tell you about The Kid. I met The Kid a few years ago, right out of high school. He had shipped some popular iPhone apps, made a few websites, had a bright future.

I don't know how it started, but The Kid really believed in "Move Fast and Break Things". Ship-First-Questions-Later sort of guy. It made sense to him: the product was the purpose, and the code was a means to an end. He loved the things he could build, but wasn't big on the process.

So The Kid carried on and built a lot of cool stuff. I saw some of the code, and it ain't pretty. But the end result still worked fine. And it got him pretty far, too. He'd flaunt these creations and eyes would go wide. It all looked impressive. He was young, sure, but who wouldn't want to grab that talent while it was cheap?

The Kid started working. He was famous for shipping new features that the users loved. And damn could he do it fast! Usually from idea to production in just a few days. Hundreds of lines of code in an afternoon, I kid you not. Lots of pats on his back, I'm sure. It all seemed to be working out for him, living the good life.

And then things changed. I saw The Kid just about a year ago, working feverishly on a complete product redesign. Lots of new code, not a lot of time to think about it. Just him on the project, no second opinions or supervision. As with all redesigns, feature requests piled up at the pace of a bad game of Tetris. But who was The Kid to say no? Sleepless nights later, The Kid emerged with something. At first glance it looked great; even I couldn't believe it came together so quickly. Champion effort on his part, right?

But here's the rub: delve beneath the surface and it was just too buggy. And these weren't just sloppy edge-case bugs, they were "What idiot do we need to fire?"-class problems. The redesign was shelved and rewritten again without The Kid.

The Kid didn't lose his job, but I could tell it hurt him like hell. Because to programmers like us, what is our work but extensions of ourselves? What did this disaster say about The Kid?

He laid low for a bit, ashamed of what he had done. Moving fast and breaking things had gotten him far, but now he had finally broken too much. Kind of world-shattering to him, I guess. It was a dark place for The Kid.

And that's when I heard The Kid grew up. You could say he became The Guy, The Dude, whatever; the point is he had a change of heart. He started to realize shipping might not be everything. His screwup was a loud wakeup call that he needed to change his scene.

And so (and this is all hearsay, mind you) The Kid started caring about his code. Not just caring, but really giving a damn about it. And not because it was a means to an end, but for the sole sake of caring about it. "Code is more than just a tool," I heard he said. "It's our craft. It's our muscle. And we need to train it. Chop wood. Carry water. Code."

I heard all sorts of wild rumors. That The Kid started using "best practices" in all his Google searches. That he started learning the deep internals of the beasts he wrangled, whether it were Rails or iOS or whatever, just for the intellectual pleasure of it all. Code was no longer a beast to be tamed; it was a creature, to be both studied and admired. He even tried to teach others the error of his old ways. Wild stuff, right?

Did The Kid completely abandon his old ways? Well, apparently not. He said something about how there's a, "time and place for everything." That sometimes we need to ship fast and will break things. But if we take all the other time we have and put it to good use by really learning and crafting our code, we'll break less.

Kind of a crazy change, but I'd believe it. I thought a lot of things about The Kid when I met him a years ago, but I didn't think he was stupid. He grew and evolved as we all do. And he's probably not even done yet, wherever he is. But next time you need to move fast, take a deep breath before taking the dive. Remember The Kid in all of us.