all that eggnog caught up to him... the cocaine addiction didn't help either.

Here’s something unpleasant to think about, you are finite. Think about it deeply, drink it in, sit with it, feel like you’ve come to understand it, then wake up in a cold sweat thinking about it some more. There is only one certainty in this life, it will end. It gets worse, your time, your effort, your experiences, they are all finite. It’s one of those big huge things in life that is too inconvenient to think about, so we don’t. This is the core reason why most religions exist, coming to terms with one’s own limited nature is terrifying. I’ve always been an Atheist, intimately connected to this notion that one day the unique thing that is me will be no more, just as for billions of years before I popped into existence I wasn’t yet. It’s something I tell myself I have come to terms with, but it is a daunting challenge and one that must be revisited from time to time.

As an aside: although I’m more than happy to discuss my personal spiritual beliefs I attempt to keep such charged matters off of this blog, if you would like to chat about it just post a short comment indicating so and I will contact you. I am an Atheist but I respect others’ belief systems and don’t intend to offend anyone.

I was driving home the other day and an interesting story came up on the radio. The main point being that as we age we sense that time is moving faster and faster. This is the spark that has led me to revisit one of the least comfortable aspects of our shared humanity. I’ve been pondering it for the last few days, thinking about my very real finiteness and trying to evaluate if I’m acting like a man with an expiration date. It was a mixed evaluation, in some ways I am, in others I am not, not a terrible fate by any stretch.

In my personal life I feel like I’m running full steam ahead. It might be the last week or so of 14 hour days working on getting my new house ready to move into. (After years of snacking and typing my body isn’t as suited to the tasks of tearing up carpets and fixing walls as it once was). I’ve set real goals in terms of building skills, building relationships, and creating code I can be proud of, and I’m exceeding my expectations. I finally feel like my wheels have caught solid ground and aren’t just spinning anymore.

There are still some areas I’m not happy with, I’m taking stock and taking action to address these. On the whole though, I feel like I’m spending my limited time here the right way for now. There are a thousand and one clichés about this subject: live each day like it could be your last, what would you do if you knew you would die tomorrow, etc. The problem is that they all take an outlook that is far too limited. No one could live each day like it could be your last, that’s fucking stupid. If I knew I was going to die I’d spend all my money and live with complete abandon, you can’t do that everyday of your life. It is the routine of life that makes this so difficult.

Life is finite but there is also a whole big pile of it. We like to think that we can wait and do something next week, month, year, etc. This is where all that “I always thought we’d have more time together” thing comes from. Want to open a bakery, learn to play the drums, fight a bear, there’s no time like the present. If you are unhappy, you have to fix that. Other people that aren’t you are probably going to tell you that you are foolish for trying to fight a bear, well those people can waste their lives while you’re out punching Yogi in the mouth.

Don’t let anything stand in your way, take it personally because nothing could be more personal. This is your precious finite life and its ticking away. If you are unhappy or feel like it’s being wasted, do something about it. Nothing could be more important. It’s not comfortable, and it can be frightening, but take stock of your life today and the whole time keep in mind, I only have so many days left, is this how I want to spend them.

No caption needed

I want to be honest with you for a minute, I have lots of stupid ideas. I have them all day, in the shower, while eating a sandwich, while writing my blog posts, stupid ideas come streaming into my head. I used to just ignore them, “No one needs a peanut powered lawnmower” I would tell myself. The interesting turn was when I started writing these stupid ideas down.

Some stupid ideas will always remain stupid ideas, some though will change over time. That dumb idea might actually just be so brilliant it looks stupid. It might be so big and scary that you’ve convinced yourself it’s stupid. It might not be a bad idea at all, after some careful reflection. It might even be a wonderful idea.

Why do we throw away our stupid ideas? Is it because we don’t have time for them, bah, that can’t be it, you are currently wasting precious time reading the stupid things I have to say. Is it because we are so swamped with brilliant ideas that we have to prioritize, probably not, or else you’d be sipping margaritas next to your perpetual motion machine. No, the answer is much simpler, its because we are afraid or failing. Stupid ideas are failure babies, a dumb idea grows up to be a hairy ugly failure, and we have learned in the school of life that failures are bad, so we avoid them.

Have you ever talked to a 4 year old? I have on various occasions, interesting little buggers those 4 year olds. They will tell you every little thought that bounces into their overly energetic little brains, no matter how wrong or foolish. They don’t mind failing over and over again, they will insist the moon is made of mashed potatoes and not feel bad at all when you tell them the truth. And most importantly they learn a ton of information.

Now don’t take this the wrong way, I don’t think you should just go around like some half-cocked lunatic spouting off every little thing that pops into your head. There was a time for that and if you go into the board room now insisting the moon is made of mashed potatoes you will be roundly mocked and rightfully so. What I am advocating is the preservation and analysis of your stupid ideas. Let’s take a look at some stupid ideas quickly to see why this is useful.

• Idea #1: A blanket that has arm holes and you wear it backwards or something… yea like a backwards robe! Pretty fucking stupid, but better known as the Snuggie, which has become a huge success and sold tons.
• Idea #2: Instead of executing the code on this machine, let’s build another machine that doesn’t actually exist and have that fake machine live on the real machine and have code execute on the fake machine…. What? What are you rambling about Jenkins, get out of my office! Jenkins just invented the Virtual Machine architecture that power things like Java’s JVM and .Net’s CLR.
• Idea #3: Wouldn’t it be awesome if you could tape together 4 iPhones and have like a really big iPhone. I’m sorry, did you just smoke a bunch of peyote?! That’s dumb…. Or its the new iPad.

You get the picture I’m trying to paint here. A lot of the amazing things we take for granted and depend upon everyday, things that seem like great ideas now, all had a moment in time when they were some far-fetched pie-in-the-sky dream. Most ideas start off as stupid ideas. Stupid ideas are important and valuable, not all of them, but there will be some diamonds in those dirt clods. You just have to be smart enough to sift through them.

My advice to you is to jot down those stupid ideas you normally throw by the wayside. Revisit them every once and a while, re-evaluate their “stupidness.” Sometimes you will find a diamond in the rough, sometimes a stupid idea can be the spark needed to have a brilliant idea, and sometimes you will just get a good laugh out of the stupid things you think up.

oh creator of hot pockets, we praise thee!

I remember being a young lad preparing myself for university I was given a gift from my mother, “C++ for dummies.” The vote of confidence on my status as a “dummy” aside, I read the book with great interest. There was an analogy the author used to explain the idea of classes and what functions they should expose, I’m going to shamelessly steal it (paraphrasing as I don’t have the book with me).

Imagine your son comes up to you and says he wants to make some nachos. You tell him that its fine by you, just go cook them in the microwave, and there is nothing controversial about this statement. Microwaves are actually boxes full of high energy radiation being produced by cavity magnetrons or waveguides, to the end user, the microwave is just a magic warming box. It exposes a very simple interface, some buttons that allow you to enter the amount of time you want to cook something.

This is the essence of an API (Application Programming Interface), wrapping up something complex and possibly dangerous in something safe and easy to interact with. When building code that you intend other people to use someday, it is the part that is most important part, and the part that is easiest to overlook. The problem is that we are often too close to something and too concerned with our use case. If you want to design code for others to use, it requires significant time and effort, and even then you probably still won’t get it right.

Prosper is still undergoing active development, I’m currently agonizing over how I want to expose various execution modes. The solution, no matter what I pick, is trivial to implement, but the api is the most important part. A great api exposes a consistent concept, something that is easily grasped and allows the end user of the api to declare what they want to do without having to worry about how its going to get done. Since good programmers write good code and great programmers steal great code, I’ve modeled the api for prosper extensively off of jQuery. And why not, let’s take a look at two different APIs, the browser dom api and jquery.

  //Let's barber pole a list by coloring every other element blue
  var list = document.getElementById('the_list');
  var highlight = false;
  for(var i = 0; i < list.children.length; i++) {
    if(highlight) {
      list.children[i].style['backgroundColor'] = '#FF0000';
    }
    highlight = !highlight;
  }

Fairly straightforward implementation, but it concerns itself heavily with the “how” of what its doing. Manually traversing to pick the elements it wants, eww.

//Same thing using jquery
$("ul#the_list li:odd").css("background-color", "#FF0000");

jQuery is definitely magic, but this code is great because it let’s you focus on the “what” of what you are doing. How does jQuery go about selecting the right elements and all that? I don’t care, and the great thing is I don’t have to care, and if in the next version of jQuery they find a way to do it faster, I win without having to do anything.

Writing a great api is difficult, you have to divorce yourself from the concrete problem you are solving and look at it in the abstract. Put yourself into the shoes of someone trying to figure out how the api works, and then ask the questions they are going to ask.

• Why do I need to build up this context thing and pass it in?
• How come there isn’t a sensible default for these arguments?
• What dumbass made this thing?

Answer those questions, and keep working at it, strive for elegance and consistency, because then it will be easy for people to learn and use. If your code is easy to learn and use, people are going to want to use it more, and they are going to want to tell their friends about it. Then you can get some lucrative ad campaigns with Nike because of the boffo library you write in FoxPro.

There is a more subtle lesson in all of this though. Any code you write is exposing an api to someone else. “But only I am ever going to use this code!” I hear the naysayers warming up their keyboards for the comments section. This may be true now, but the six-months-from-now-you is going to look back at the you-of-today and wonder what the hell he was thinking.

Get in the habit of making your code easy to use, and expose a nice api. This will endear you to your fellow programmers and help make maintenance easy. Strive to be that guy on the team that writes functions and classes people want to use. Make life easier for your fellow developers and even if they don’t return the favor, maybe they will take you out for a beer. People notice over time that your code is the best to work with, they internalize it, and they start to think of you as a great programmer. That’s a pretty great api to expose to the world.

That time was so much more glamorous

A realization has been dawning on me as of late, one that I’ve always known, but that is easy to forget, easy to misplace, easy to neglect. The best way to learn anything is to do it, to struggle through, to forge on, to fight and gnash teeth and curse at. There is no knowledge as highly regarded as that which you have to work for.

I’m not even particularly certain how this all came about, it seems to have been a culmination of things. I didn’t intend to but somehow I ended up putting on my plate a bunch of new stuff to learn around the same time. Git, ruby, rails, blogging, prosper, hosting my own domain, and testing (Testing being a decidedly late addition). This blog was the genesis of a lot of it, that and just being curious.

I had my first post back on October 2nd of last year, as of writing this 112 days ago. At that point I didn’t really know anything about the 7 topics above, I started the blog using Google’s Blogger platform, it was an easy onramp.

After a month or so, I was encourage by some friends to move the blog to my own domain, which you are now at. I also kicked off the prosper project around the same time as starting this blog. I played around with ruby and a crazy friend convinced me to try out rails. I moved prosper to GitHub and began learning git. Now prosper supports 19 backends and has gained over 100 unit tests in the last few days.

Here’s the kicker though, I don’t know what I’m doing. I never really did, I just started doing stuff, and have been running ever since. There have been days when I’ve gotten 5,000+ hits on this site, several days with several hundreds of hits and I’ve been steadily increasing the daily reader count. I don’t know how I did that, I just kept writing, I liked it, I promoted it over twitter and hacker news if I thought I had written something insightful, and I guess that is working. The same thing with prosper, I saw a need for something that didn’t exist, I had a vague idea of how to make it, and I started coding. I’ve rewritten and refactored it piece by piece to the point that it supports all kinds of things I never thought it would. It’s due for another architectural change after I finish these unit tests.

If there is one key thing I could convey to anyone reading this is to hustle. You will never be prepared for the things you are capable of doing. You will achieve your greatest accomplishments not by building up a grand framework of skill and then deftly creating something glorious, but by starting small and persevering in making it better and better. It is never an easy road and you will gain a grand framework of skills, but you have to push your boundaries to grow.

This came together for me last night, I was working on a rather tricky bit of rails and broke something. I hadn’t gone too far into it and so I typed rake db:rollback and git reset head --hard and was back to a working application. I stopped myself for a second and thought about what I had just done, how improbable it all was from where I was just a month ago. I then thought about what I was doing in rails, and thought about how earlier in the day I was wrapping up prosper functionality in unit tests and finding regressions, and how I would have to write some cucumber tests for what I was doing, and I realized that 112 days ago I didn’t have the vaguest idea of any of this.

I would love to put a triumphant “I’m just so damned smart and talented and handsome” paragraph here, but that’s not the case. I just steeped myself in this stuff, I worked in git daily, I read about it, watched screencasts, I bought agile web development in rails, I got design patterns in ruby, I hustled. And you can do it too, take the first step today.

The first step that you should take is to invest yourself in something non-trivially. Want to learn rails, then go buy agile web development in rails, want to learn github, move an active project out there, want to learn linux, reformat your machine so that’s all you have. You have to invest yourself, it plays a trick on your brain that makes it want to not waste that “investment” by quitting. If you can burn your boats (Hernán Cortés reference) all the better. I had no choice but to learn git or else I couldn’t keep working on my project, and as a side bonus I got the joy (and frustration) of working in git everyday.

Get out there and hustle, learn something new, do something that scares you, reach beyond your grasp.

Stratego... similar to strategic

Then my boss told me that I would be working on a new project. Huzzah! I’m leaving behind .Net back to the land of Java, thus keeping my streak alive of never working in the same language 2 projects in a row. The project position has been described to me as a strategic technical challenge. Let’s break that down real quick.

Strategic – That’s a fun word, what does it mean, dictionary.com defines it (after a great deal of military definitions) as

Highly important to an intended objective

So this is an important position, one which is necessary for intended objectives. From what I’ve gathered of the work I’ll be doing, this is an apt definition

Technical – Nothing touchy feely here, no user interaction, no pretty style sheets, no fancy jQuery magic, just straight CS4xx type algorithms and number crunching. I’m have a feeling I’m going to have to dust off that Math degree sitting in the corner.

Challenge – This is the word I love, the thing I live for, a good challenge. I’ve been working on enough quick one week, one off, hit-it and quit-it projects as of late, I’ve missed the thrill of a good challenge.

I don’t know how much I’m at liberty to share about the project which is why this post so far has sounded a little bit like a riddle. The one point of information I’ll share is that the task I’m going to be taking on was sent out for quotes and the number that came back was… 10,000+ man-hours. You aren’t misreading, and I triple checked that I wasn’t mistyping. In case you aren’t familiar with what 10,000 man-hours means I’ll take a quick detour to explain it.

The Mythical Man-Month

In one day, one programmer puts in 8 hours of work, that is 8 man-hours. One week is 40 man-hours. Assuming you get two weeks vacation, one year of development is 2,000 man-hours. That means that 10,000 man-hours of work is 5 straight years of development, half a decade of work. Of course, throwing some more resources at it you could hit 10000 man-hours with a 5 man team in just 1 year, more or less. The problem though is that this reduction in time is non-linear, you can’t just throw 10,000 developers at the problem for an hour, this is pretty well discussed in The Mythical Man-Month.

In less technical terms that means that there is approximately a metric shit ton of work to do. And not grunt work mind you, complex problem solving work. This is a mountain of work. There are a few things that you can do when a mountain blocks your path.

1. You can turn around and go home
2. You can rent a helicopter
3. You can ready your climbing gear

Going home isn’t an option in this case, the task can’t be overlooked and other things can’t happen until we are up and over the mountain. The outside quote was a helicopter, it costs some cash but is easy and relatively painless for you. Well we can’t wait around a year to get this thing done. So that only leaves us with one option, so I’m gathering up some rope and pitons. I’m dusting off the part of my brain that remembers how Java works, remembering that strings can only be compared with .equals(), and fondly remembering the joy that is Eclipse after the ghetto of Visual Studio (holy war can begin now, be sure to insult my mother).

I’m preparing myself for what will be the biggest technical challenge of my career, and it fills me with happiness. It reminds me that I love this profession, that I’m stupid lucky to get paid to do it, and that I’m going to go in there and climb that mountain. From the little information I have, I’m sure the climb is going to be arduous, but I’m determined to plant my flag at the top, and I know that that will be amazing.

I want to challenge you to look around for your own personal mountains, its easy to avoid them, to walk away, go home, or rent a copter. You should instead commit yourself to the climb, because when you are at the top of a mountain, all the other problems are pretty small.

• First Dev: I want this new project to seamlessly integrate with eBay, digg, and amazon
• Second Dev: Those seem arbitrary, maybe we should define some sort of data import protocol
• First Dev: Yea, then we just need a scraper piece that uses the adapter pattern to translate various websites into the standard import protocol and feed the project
• Second Dev: I’ll start defining a dtd and you can start writing up some xslt for eBay and digg and amazon as a proof-of-concept
• First Dev: Great, then we just need to get the exchange support and the poor man’s cron jobs running, to send out the periodic updates
• Second Dev: Should we integrate with Twitter?
• First Dev: I don’t see why not
• Third Dev (interrupting): Wait, what are we developing?
• First Dev: Todo list
• Third Dev: Maybe we should get it to store and delete todo list items first
• Second Dev: That’s the easy part, the multitouch integration is going to be the hard part
• Third Dev: …

the dream

Before we get the product to do something simple, something any moron could code up, we want to start slapping on features and bells and whistles and whizbangs. This is all fun, because whizbangs are fun things to think about and code and its all well and good until you realize you have coded up a great feed reader, but one hell of a lousy todo list. Focusing on least viable product in the beginning gives you a concrete base to start applying whizbangs, based off of real world feedback and grounded in reality. Incrementally building up value off of an existing product is easier and makes more sense than building a giant all-in-one application that can do everything but butter your toast that no one wants to use.

So this leads me to the best way forward in my estimation and experience, nothing. Nothing is incredibly powerful, tremendously liberating, and allows you to get something up and running in least viability mode or to solve a complex issue.

I can hear it already, what the hell are you talking about you mentally unstable person?! Let’s look at some tools that exemplify nothing and how you can go from nothing to something quickly and incrementally, but only if you start with nothing.

Mock-ups. What is a mock-up, nothing really, just a fancy picture of what you want an interface to look like. There are many great tools for making mock-ups, a new one that just hit beta is mockingbird, a more seasoned veteran in this game is the excellent Balsamiq. These shouldn’t help, we all know what a todo-list looks like, why would mocking one up help us? Because, even though we are capable of abstract thinking it is much easier if we have a concrete model to wrap our heads around. Like I said in tool roundup

[talking about a sweet visualization I made] …but it is a much better reference when working with this particular part of the system than looking at the database table and trying to assemble parts of it in my brain as the situation demands.

If we don’t have a concrete model we force our brains to construct one on the fly, taking us out of our work and into a conceptualization, having a concrete model frees up precious processor cycles in our brain. A mock-up is also great because it allows us to take nothing, a simple functionless mockup, and quickly turn it into an actual interface. What does that button do? Nothing! What about that one? Nothing!!! Then we can slowly but surely add functionality to our interface until we have a functional least viable product. The way we got there was by understanding that we start with nothing and work our way gradually to something. Sure we could have sat down at the keyboard and pounded away code for a day or two and then run the thing, but the faster we can get it on the screen and start iterating over it, the better.

The second way that nothing can be useful is when tackling a huge problem, lets look at the contrived feed reader problem from up above. How in the world do we go about solving that?! Well we employ are good friend nothing, and we build from there. What’s would the simplest possible solution be?

$feed = FeedReader::read("http://www.digg.com");

We can throw that in our program, now we need to deal with the FeedReader class

class FeedReader {
  static function read($url) {
    return '';
  }
}

Nothing to the rescue, we just defined our super simple API, but we aren’t quite to functional yet, but we have a foothold now to iterate from.

class FeedReader {
  static $readers = array('http://www.ebay.com' => new EbayReader(),
    'http://www.digg.com' => new DiggReader(),
    'http://www.amazon.com' => new AmazonReader)); 

  static function read($url) {
    $reader = self::get_reader($url);
    if($reader) {
      return $reader->process();
    }
  }

  static function get_reader($url) {
    return self::$readers[$url];
  }
}

Wow look we are almost all the way to functionality, amazing!!! Thank you nothing (that’s what EbayReader, DiggReader, and AmazonReader do). Now its the simple task of implementing those, which each by themselves is a somewhat complicated task and outside the scope of this blog post.

This sort of top down design though can be very helpful, you need to solve a problem, just pretend that you have an API that already solves it and start calling it, stub out those functions (stub is a fancy computer science term for “make it do nothing”), and watch the power of nothing first hand. Then you fill in the blanks, allowing yourself to have more nothing functions, you successfully break up your huge monster task into simple solvable tasks.

When we combine the first technique with the second we can get truly awesome results, we normally call this Rapid Application Development (or the much cooler 1980′s name, RAD). RAD can get us to something faster than almost anything, using the power of nothing.