Category Archives: Programming

I recently came across an article by Jeff Atwood (of Coding Horror) on how to be successful. It opened with a line of advice that I really liked: “Always Be Jabbing. Always Be Shipping. Always Be Firing.” The idea behind this advice is that as long as you keep moving forward, no matter how much you suck you’ll eventually be successful.

I’d like to add another word of advice along these same lines: Always Be Testing.

My problem (and I’m guessing there are many of you out there who share this problem) is that it can be very easy for me to trick myself into thinking that I’m making something when I’m really not.  The degenerate case of this is errands like doing laundry, taking the dog for a walk, writing thank-you notes, organizing your desk, etc.  These are all legitimate things to be doing and they can be fairly important, so it feels much less like procrastinating than just sitting around on your butt playing videogames or watching TV.  But if you’re doing them in order to avoid other, more important work, then it’s still procrastination–only worse, because you feel like you’re getting something done.

Unfortunately, there are even more subtle ways to procrastinate while still feeling productive.  Perhaps the most insidious of all is the type of procrastination where you’re producing like crazy, but you’re not doing any testing.  Maybe you’ve written a 500-page book but are afraid to read it (let alone give it to anyone else to read).  Maybe you’ve been practicing an instrument in your basement for months, but you won’t let anyone listen to you play.  Or maybe you’ve written a few hundred lines of code without once actually running your program.  There are a number of reasons people do this, but probably the most common is fear of failure or rejection.  Well, the bad news is that you will face failure and rejection.  Your writing will be torn apart, your playing criticized, and your code broken in a dozen different ways.  Here’s the problem, though: without testing, producing is just an errand.  It’s something that has to be done, of course, but it’s not the most important part of building something.  Just as the most important part of writing is reading what you’ve written, and the most important part of architecture is construction, the most important part of programming is testing your code to make sure it works.[1]

What I really like about the “Always Be Testing” aphorism is that (along with the other three Jeff mentions) it’s applicable not just to writing or programming, but to life in general.  If you’re not making things, you’re not improving and you will never be successful–and if there’s no chance of something going wrong, then you’re not really making things.  Anytime you suspect you may be procrastinating by doing something that feels like work but really isn’t, ask yourself “what will happen if I mess this up?”  If the answer is, “basically nothing”, then you are procrastinating.  When you make something, you introduce a permanent change to the world–which means mistakes are permanent, too.  This can be scary, but it’s a necessary tradeoff: without the possibility of failure there can be no such thing as success.

So what does that mean in practice?  It means you should always have something that’s ready for an audience, even if that audience is just your closest friend, or you as your program’s first user.  For writers, it means constantly getting feedback on new revisions.  For architects, it means making scale models at each stage of the design process.  And for programmers, it means always having some small program working and complete enough that you can run it and see if it does what it’s supposed to.  Again, this isn’t just good programming practice, it’s good practice for life: start small with something tangible, then work your way up from there.

In the end, that’s all success really is.

Notes:

[1] Obviously, you still have to write the code first, and buildings need to be planned before they’re built.  My point is not that planning and preparing aren’t important, my point is that until your code works or you have a standing building or your art has an audience, you have not actually made anything–you have merely prepared to make something.  A shoddy building that’s nevertheless standing is infinitely better than a building that never gets made, no matter how perfect its design.