Geeks With Blogs
Bob Palmer's Developer Blog .NET, SQL, and Silverlight Development
Today I'm working on some absolutely horrible code.  And I'm completely ok with that.
As a professional app developer, I've always felt that it's our responsibility to keep up with changes in technology, learn new things, and always focus on improving our skillset.  And I'll add to that the caveat that the best place to learn these new technologies is not when you're trying to use them to save a floundering project, and certainly not when you're pressed to deploy a world class application for your employer.
Let's step back a bit, and talk about a fundamental truth.  I don't care if it's .Net, Ruby, Silverlight or Assembler.  The first real application you write in any new language or framework is going to contain more tentacled horrors than an H.P. Lovecraft novel.  And once you accept that you're not going to write the next Twitter on your first try out, then it's time to get to business and knock out some horrible code.
So here are a few tips I'd toss to folks who are looking at picking up a new language or framework.
Get a good book, and blow through it - and use their examples (even the toy ones).
This one is hard, because if you're like me, the first thing you do when you get to that first example is decide that you're a heck of a lot smarter than the book authors, and you try to start working on your own apps instead.  Seriously.  Don't do this.  Suck it up, build the toy aps, and really make sure you have a good grounding before you move on.  This helps you better understand the material, and keeps you focused on learning and not trying to twiddle with your app.  On a side note, I'm a huge fan of the Head First books for some initial language exposure.
Don't try to conquer the world with your first app.
This one's tough because all of us probably have a dozen great ideas for applications - ones that we could knock out easily in our framework or language of choice.  Don't fall into this trap, because writing stuff in a new framework is tough.  Epicly tough.  And again, if you're like me you probably have about half a dozen projects still in that 70% done phase.  And there's nothing more demoralizing to learning a new framework than to struggle for months trying to build this wonderful, amazing thing that ends up being a giant ball of dissapointment and frustration.
Pick something simple, then figure out how to make it even more simple.  Get the absolute most basic walking skeleton out there.  I'd rather have a fully functional 'Hunt the Wumpus' in my new language than a 70% done dream project.  And if Hunt the Wumpus is too difficult, accept this and go further down.  The bottom line is that you need to select something you can actually build and ship.
Accept the fact that it's going to be a crappy app.
And by crappy, I mean an app that looks like the code was fingerpainted by a three year old, and with a knot of tangled tentacles of horribleness.  And all of this is absolutely ok.  your job the first time out is not to write the best code, your job is to ship some code that actually works.  And the less you spend twiddling and the more you spend just slugging it out, the sooner you can get to the next bit of advice.
Refactor, Refactor, Refactor.
Once your little nugget of code horror is done (and technically working), it's time to take a hard look and think of all of the things you could refactor.  you already have a working app, and you should have a good idea of what pieces seem breaky to you.  So now is a good time to expand to some more books, and begin polishing your Hunt the Wumpus game into the most amazing game ever, with realtime multiplayer action, 3D graphics, and a soundtrack with voiceovers by Patrick Stewart. 
Continue to broaden your horizons.
For my own professional development, this is a practice I repeat on a regular basis.  I pick up a new framework or language, build my first app in it, refactor it into something brimming with awesomeness, then move onto something new.  It's something we just have to do in our field, especially as we see more languages and frameworks come out, and we have to determine which ones can help us professionaly, and which of the latest and greatest tools will actually last the test of time.
I hope this has been helpful, and as always, feel free to post any feedback!

Posted on Sunday, February 21, 2010 1:58 PM | Back to top

Comments on this post: How I came to embrace horrible code...

# re: How I came to embrace horrible code...
Requesting Gravatar...
Nice write up, succinct and to the point. On many of the projects I have worked, this is exactly how they start out and fortunately, more people know that the first round will be a mess.

This is even more true with green field, first build applications. Trying to dig up enough knowledge in the first attempt is asinine at best. :)

Enjoyed the post, thanks.
Left by Adron on Feb 21, 2010 2:17 PM

Your comment:
 (will show your gravatar)

Copyright © BobPalmer | Powered by: