Stop me if you've heard this one.

"Have you worked in <shiny> yet? It's completely amazeballs. In version <next>.1, it even lets you <shinier>!"

"Man, I've really been meaning to, but <Initech> has me super super busy with <green-screen nightmare> work. Maybe if I get assigned to the <legendary unicorn> project next year."

I don't know about you, but that exchange—which I've witnessed more than once—just makes my stomach sad. Life is too short to sit clutching the edge of your desk day in and day out, crossing your fingers that you will get put on a project that is nowhere near a COM object.

If you only ever work on the code you're assigned to by your employer, your entire skillset is at the mercy of your employer. And your employer's motivation is not exactly to See The World using an IDE.

I mean, sure. You can try to convince { the other devs | your client | your boss } that that component needs to be a WCF Service written in C# 4, hitting the database with Massive, and that you ought to look into slapping ELMAH in there to help with those late-night support calls.

But { the servers are only running .NET 2.0 | we don't use Open Source here | we're a VB shop }. And there isn't a thing you can do about it.

So. What can we do to reconcile this gaping void between your fire-breathing potential as a software god and your boss's to do list? Not long ago, my colleague Dan Fischer posted here extolling the virtues of maintaining an app that has nothing to do with your day job. I'm here to second Dan's approach—perhaps even to third and fourth it. Because there is nothing like one hundred percent ownership of a codebase to learn you up a thing or two about writing software.

You Need A Pet

Let's call it a pet application. A website, a mobile app, a windows service, whatever. Some solid chunk of code with your surname as the root namespace that makes you talk to yourself in the middle of the night.

If you already keep one, you know what I'm talking about. If yours is a little crusty around the edges, go unpack it and give it some love. If you don't have one yet?

For the love of Turing. Build one.

I have a pet web app named Check Fu! that I use to track my spending. You can see it here and read more about it here.


Figure 1. My wittle snookums. Whoosa goodboy?

In its latest incarnation, Check Fu! is an ASP.NET MVC 3 site using the new Razor view engine, a generous helping of jQuery (1.5, with templates—shiny!), the aforementioned ELMAH for logging, all perched upon an Entity Framework 4 / SQL Server 2008 stack. It also interacts with the Twitter API via Twitterizer, reads iCalendar feeds with help from Douglas Day's iCal library, parses email using OpenPop.NET, and does its business out back with the Enterprise Library Logging block.

You know, now that I list it out, it sort of looks like a monster. But that's real software—a totally different animal from the adorable sample code typically packaged with the latest thing ScottGu is posting about. One is designed to get you totally frisked about "look how simple it is to boilerplate your database table now", and one is designed to do work. Sample code is nice. But guess which one you will learn lasting lessons from.

I have put in hundreds of spare hours over the last several years designing, building, refining, refactoring, even abandoning and starting over with this application. Here's a sampling of the trinkets in its wake:

  • Active Server Pages ("Classic")
  • VBScript
  • Access
  • ASP.NET WebForms
  • AJAX Control Toolkit
  • SQL Server Reporting Services
  • LINQ to SQL

All relegated to the Check Fu! scrap heap. But—and here is my point—they're all in my utility belt, too. Tech I can wield gracefully and recommend/not recommend with confidence. And I didn't have to wait on my job to get me there. Whether I'm ever paid penny one for the time I've invested in the 'Fu, that is priceless.

Also, if you are into professional blogging, presentations, or mentoring, your pet code will be a deep river of material for you to drink from. My blog posts here, here, here, here, and here were all spawned from Check Fu! code, and there's more where that came from.

I'm Also A Client

I'm not just the sole developer on my pet app, I am also its number one user.

Now that we're finished having a laugh about my skills as a marketer, having a similar relationship with your own software is pretty key to the whole experience—you are made of meat and emotion, and there are shortcuts that you as a developer will take that you as a user will not tolerate. It's a loop you should close, because eating your own dog food is the most straightforward way to enforce quality in your app.

In or Out, Boy?

You don't have to publish your app to the world—some people like to keep their pets in the house. It's better to keep a pet cooped up and safe than to not have a pet at all.

You don't have to publish. But you should.

Check Fu! was an indoor pet until just last year. When I made up my mind to share it with the world, I saw it in a completely different light. I mean, there is a mind-blowing gap between usable to the developer and usable to the developer's mother.

Reaching for the latter, you will not let yourself get away with nearly as much. I carved off hundreds of lines of code and functionality that didn't serve the app's core purpose. Relatively speaking, before going public, Check Fu! was a little cross-eyed, had five legs, and rocked some adorable love handles. By the time I hit the Publish button, it had back abs, shook hands real nice, and cleaned its own turds from the sidewalk.

Make A Wish

A solid idea is foundational to starting your pet application. If, at its core, your app serves a real purpose, it will stand up to years of refactoring and porting. And usage by your mother.

Fresh out of killer app ideas? Funny you should mention it—Amrit Richard used that problem as her idea. Now we have her Internet Wishlist site, and that excuse is a lot harder to make.

Figure 2. Wishing for more wishes, IRL.

Mission Control

Your { employer | client } may use tried and true legacy tech to accomplish their mission, and if that works for them, Godspeed. You may have a symbiosis with them in the present tense. But you are not them, and you have an additional mission to consider.

In a field where your marketability is dependent upon the freshness of the alphabet soup on your résumé, you're going to need more than the diet your boss, however hip he or she may be, has you on. Keeping a real app for a pet gives you a solid sandbox where you can quickly learn and evaluate new technologies and techniques. So you can be the dev who starts that conversation from the top of this post, instead of the Eeyore who bums the room out with his job from the nineties.

So what's your pet application?