Throwaway Projects

A big obstacle in my learning of new technologies, patterns and methods, has been my reluctance to do throwaway projects. I have a really hard time with them. Always have, in all their many forms. At times I have even actively disdained them as a useful way to learn, for various reasons.

There have been a lot of things I've been curious about and wanted to learn. I'm a programmer, so that really goes without saying. And goodness knows that, relatively unencumbered from social obligations, as geeks tend to be, I've had enough free time in my life that I could have dedicated some of it to working on some little test or toy projects to get a handle on these things. But I've always managed to convince myself it wasn't necessary, or even that it was a waste of time. Usually I accomplish this by claiming that I learn more and better from doing "useful things". Throwaway projects don't impress real constraints on you, and so they let you take liberties or make compromises that wouldn't fly when trying to actually get something done. And I was convinced that this meant the knowledge gained would be less useful or applicable to real problems.

Today I had the revelation that I couldn't possibly have been more wrong.

I was faced very recently with a number of opportunities to work on some new things, to "get stuff done", involving some technologies I'm not really at all familiar with. I initially thought to myself that this is a great opportunity to finally ramp up on some things I've been wanting to learn. But after a bit more thinking, I found myself in one case completely unsure whether I could accomplish the goal on the necessary timeline, and in the others quite certain there was no way that I could.

That's when it hit me. I realized what teachers of all stripes have known for centuries. While I've learned an awful lot about programming on the job, those fundamental lessons that my knowledge are rooted in were very rarely learned in the active pursuit of an important functional goal.

Let's first acknowledge the obvious and ubiquitous example of homework. Homework is nothing but throwaway problems. I learned the value of homework (finally) when I moved from high school, where I breezed through on in-class osmosis, to college, where info came so fast and furious that I couldn't absorb it in the desk.

In grade school, I did rote program transcription in Apple Basic. In middle school I messed around for hours, daily, in QBasic on my parents' desktop. There I played with graphics and sounds. I poked and prodded at parts of the QBasic games that were packaged with DOS. In high school I moved on to trigonometry, large-number math, a text-based RPG in the vein of LORD, 3D wireframing, and even created a graphing calculator that would automatically scale to fit one cycle of a sinusoidal function.

One useful thing I did do in QBasic was to write a file chunker that would split a file into either a particular number of pieces, or pieces of a particular size. The goal of that was to more easily share games that wouldn't fit on a single floppy, or that would take several hours to transfer over 14.4kbps modem. So, okay that was functional, and I learned a bit about file access in QBasic from it, but nothing much. Until I started to learn C++ in college, when the very first thing I did was to port my file-splitter from QBasic. I did this knowing that not only was it not very useful, but there were many freeware apps that did it better than mine. But I learned about the fundamentals of C++ syntax, style, and common pitfalls. It gave me a starting point and saved me from what would have otherwise been embarrassingly slow, trial-and-error progress on the first project of my internship.

What I missed was the now-obvious truth that being free to take liberties and make compromises that you wouldn't do in production is the perfect sandbox for making mistakes, which is a crucial part of the learning process. I had it just plain backwards.

So here I sit. Mind blown. Feeling like an idiot. I still hate doing throwaway projects, but now I know I can't afford not to. I just need to man up and fight that voice in my head that nags at me saying, "why are you writing the world's millionth blog engine when you could be working on real problems that are actually still in need of better solutions?" Because the truth is that before I can reinvent banking, for example, there are a few things I need to learn before I'll even know where to start. And the best way to do that is to play in the sandbox for a while.

On the Dimensions of My Ignorance

Yesterday I posted what some may view as a rant, on how troublesome it is to get started with REST web services in .NET. It wasn't intended to be a rant so much as a cathartic walk through the research I had done and the decisions I had made, over several hours of trying to find an easy on-ramp to REST on .NET.

One of the things I mentioned was the fact that I downloaded the OpenRasta source, but was unable to build it due to a couple compiler errors. I had been in loose contact with Sebastien Lambla, the author of OpenRasta, about this situation over Twitter. Yesterday he read my post and, not undeservedly, jabbed me about not trying to fix the bug myself, instead opting to waste time "touring frameworks" to find what I need.

I got defensive, of course. I felt like I clearly conveyed my situation, and why I went "touring", rather than just settling on one and pushing through the hurdles. But looking back I can see that information is distributed throughout the post, and a skimmer would likely see only that I had looked at, and whiningly dismissed, each option in turn. Which is factual, though not really complete.

So here I will reiterate that I am:
  1. A REST noob
  2. A web services noob
  3. An ASP.NET noob
  4. An OSS noob
  5. A Git noob

And that doesn't even consider Sinatra, which brings to bear the additional facts that I am:
  1. A Ruby noob
  2. A Linux noob

I know my limitations. Or rather, I know where my knowledge ends. The reason I went "touring" is because I have ideas and I want to start to make them real. I didn't want to go burrowing into some rabbit hole not knowing if it was even the right one. I want to find a framework that minimizes the number of dimensions of my ignorance that are likely to limit or undermine my ability to produce something minimally functional.

There are a lot of things I am experienced with and good at, but the list above consists of things that I don't know enough about to know when I am making a mess for myself. Without guidance, I don't even know where to start. When OpenRasta wouldn't build, I didn't even bother to look at the code, because I didn't want to get lost in the weeds due to my multiple dimensions of ignorance. It turned out to be something that I probably could have handled, so shame on me for not at least taking a closer look. I'll take responsibility for that and tuck the critique away for future growth potential.

It's tough enough to be a noob about one thing. But ignorance compounds and grows exponentially. So it's downright painful and demoralizing to be on a path where, every time you hit a roadblock, you don't even know which of the multiple gaping holes in your experience is the culprit. It's far too easy to end up chasing down red herrings or just plain make matters worse for yourself in that situation. And I just want to get stuff done.

Fortunately for me, Sebastien says that the OpenRasta stable branch is actually stable now, so I can take another bash at that. I also learned just an hour after my last post went up that there are two more .NET REST frameworks to check out. RestPoint appears to be a young, attribute-based framework. And Nina claims to be a mature, Sinatra-inspired, lambda-based framework.

I'll admit that I really don't like attribute-based APIs, but compared to the challenges I'd face with all the other options I've looked at, I can probably stomach it. But I am a big fan of lambda-based APIs, and I'm still stoked about the Sinatra approach, so I'm pretty excited to take a look at Nina. It looks like it might just be what I was hoping Nancy would be.

And on a parallel track, I plan to start filling in at least one of my other knowledge gaps: Git. I have the PragProg book on Git, but I think I may also invest in the TekPub videos on Git to get started.