I recently joined Urban Influence as an Interactive Developer after spending years writing software for pure technology companies.  Since it's my first foray into the design industry, many differences strike me, from the number of PhotoShop and Javascript tricks I learn per day to the average number of programming languages open in my text editor simultaneously.  But one of the most striking differences for me, coming most recently from a scrappy startup with a nondescript office sans decor, is the context in which I work.  I am in a converted warehouse with old-Seattle charm sitting in an airy, well-designed office space at a well-designed desk in a well-designed chair working on a well-designed computer.  When one of our hotshot designers hands me a well-designed mockup with cleverly crafted copy, how am I going to respond to that?  What kind of software does this user experience warrant?  It's hard to conceive of answering that call with hastily written software riddled with hacks or based on a poorly-conceived structure.  Beautiful code has its own merits, of course, but I get a strong sense that working in the design industry uniquely compels a developer to write cleanly composed, state of the art, and craftsmanlike software.  There seems no other way to respond.  Anecdotally, having worked for both big companies and small, this is the first organization where I've seen a development team routinely adhere to coding standards regardless of the pace of the project.  The design of the code just…matters.  Period.

I'm mostly a Rails hacker these days.  Chatter about the Ruby language and the Rails framework routinely includes concepts like code elegance and syntactical sugar – all those kinds of geek-specific-design topics.  But I'd never before considered how many Rails hotshots (from the Rails guy to the PeepCode guy) have their roots, or at least extensive experience, in formal design.  When beauty is a fundamental facet of your work, when you focus on leveraging visual and logical order to create great experiences, that attitude can't help but filter into the tools you use and the way that you use them.  If it's true that projects can be only two of three options – cheap, great, or fast – then it seems the design industry is where you can find the “cheap” option missing as a standard requirement, leaving us as developers to write great software fast.  Nice work, if you can find it.