I've been doing some work on my resume and my summary kept starting to sound like a manifesto. I decided it was better to just simplify the resume and turn this into a blog post.

Technology doesn't exist exist in a vacuum
People create it and use it. Taking time to understand the motivations and needs of clients and users lead to more informed decisions and ultimately make a project more successful.

The team owns the code
It should all follow a common coding standard. You shouldn't be able to tell Eric was editing this section because he left it littered with tabs, while everyone else uses spaces. It also means it's important for members of the team to review each other's code and give feedback. It's also important for people to listen to that feedback. Code review provides a good way to share knowledge: "oh, that trailing comma in your array will cause IE to blow up." Even if the review just points out a typo in a comment, it sets the expectation that other people will be reading and trying to understand your code.

Code needs to explain itself
If you're doing something that looks squirrely you need to say why so the next developer doesn't come along and "fix" your code. If you're putting in a quick hack to close a ticket, say so! Spend a few minutes to list the pros and cons that lead you to this solution so that when you're staring at the code a year from now you don't have to rediscover them.

Documentation is important
If people can't figure out how to use or maintain your product then it's not finished. The documentation also needs to be close at hand. This ties back to code needing to explain itself but also extends to UI, make the ramifications of a choice apparent.

It's worth spending the time to do something right the first time
Of course there are times when you need to just get it done and launch, but as layers of code accrete on top of it, you'll only find it harder to come back fix something.

You should play devil's advocate
I'm happy to take the other side and argue against each of these points.

The total number of hours I've worked in the last seven days has been hovering between 60 and 70. We're on a deadline so compromised must be made and corners must be cut. Sections of the site are basically large JPGs with image maps of links on top. It looks good but when I peek into .tpl.php my head swims and I feel faint at the though of the kludges in place. It's lead to some fun exchanges:

coworker: "do you ever get to do a project where you don't have to end up hacking it at the end of the day"
me: "yeah the ones that never got finished :)"

So back in April I started talking to Keiran at about doing a media and files sprint... well it's finally happening. aaronwinborn in in Portland and dopry is going to be helping remotely. Aaron posted a great writeup on what we're hoping to accomplish so I'll blockquote at length:

Andrew Morton (drewish), Darrel O'Pry (dopry, remotely), and I are heading up a Media Code Sprint in Portland this week! Come help, in person or remotely, if you're interested in multimedia and Drupal! It has now officially started, and as I've volunteered to help keep folks updated, here goes...

First the reasons.

Number One: Better Media Handling in Core

Dries conducted a survey prior to his State of Drupal presentation at Boston Drupalcon 2008, and number one on the top ten (or 11) list of what would make THE KILLER DRUPAL 7 Release was "Better media handling".

Let me repeat that. Better media handling.

People have done really amazing stuff in contrib, but it is difficult (if not impossible in many cases) for developers to coordinate the use of files, as there is no good means for file handling in the core of Drupal. Thus, we have several dozen (or more) media modules doing some small part, or even duplicating functionality, sometimes out of necessity.

I've finally made it into the Drupal gliterati! Robert interviewed me earlier this week for the Lullabot podcast. It's all part of my plan to become a Lullabot when I'm done and graduated. Topics included: Phlickr/Flickr, my Summer of Code project, brewing beer and my stumbling speech.

I put in two applications for this year's Google Summer of Code. The first was working on programming tools for Squeak and the second was creating a project_metrics module for Drupal. The Squeak proposal was definitely the weaker of the two, there were too many questions I wasn't able to answer to write a good proposal. In contrast, the Drupal proposal practically wrote itself. I've done enough work with Drupal that I already know how 90% of it will work out and I'll have enough time to figure out the other 10%.

I've got it on good authority—lets just say several little birds told me—that my Drupal proposal will be accepted when they announce the results tomorrow. I'm very excited to be in the Summer of Code and very excited to be able to give something back to Drupal.org

Update: it's official, my Drupal proposal has been accepted. I'll be having a Summer of Code.

Send your developer a 12 pack of local micro brew -- it'll do wonders! Big thanks to mattrock at WSUM, all your station module issues will be marked critical by default from now on ;)

Today I finally broke down and upgraded the KPSU site to Drupal 5.0. I wasn't too worried about core, I've been running 5.0 on this site since the feature freeze and I'd setup DeFordBailey.info and spannerbicycles.com a couple months back. My big concern was with the contrib modules. I'd done a couple of test upgrades over the last month and found plenty of bugs but today was the first one where most things seemed to work. So I made a back-up and said what the fuck. After the upgrade I only found one critical bug. There's plenty of tweaking to be done in the next few weeks but now I can start hacking away at access modules.