Since Ali posted 20 things I learned at FullCodePress, I thought I'd chime in with my own observations from the perspective of being programmer for the team:
<ol>
Working side by side is the best way for any design team to operate. It's unfortunate that sometimes programmers in the design industry end up sitting in the corner as the backstop for everything else going on in the studio. The most rewarding way to work is to be sitting next to the designers, coders, and analysts, and constantly firing ideas back and forward. Sitting right next to Zef, I could watch the evolution of the sitemap and wireframes as it was happing, and from this I could see particular implementation decisions I needed to make, at every step of the way. There was no second guessing, and no messing about. I can't think of many projects I've worked on where there was so much direct collaboration between the information architecture process and the technical solution.
Sketching a domain model simplifies programming effort. As Zef (with tons of help from everyone) developed the site-map and page architecture, I could immediately translate this into a paper sketch of domain objects and their attributes and relationships, from which it took literally seconds to transcribe into PHP model code. Having the ability to automatically update the database schema directly from edits to the PHP classes helped immensely.
I am my own worst enemy. Stress and adrenalin led to me making tons of silly typos and mistakes that I wouldn't normally do. Using a PHP syntax checker in Eclipse helped speed up the actual typing of code quite considerably, but I couldn't completely rise out of the muck and wasted probably almost 2 hours just tracking down silly bugs where I had forgotten to link up or mistyped something. One example - I had set the main content field to be a 255 character string instead of a standard text blob. Spent what seemed like hours wondering why posts were being truncated. Took 10 seconds to fix.
Unit tests save you from a huge amount of pain. I know this, because I only had time to write a couple of environment stub tests so nothing else in the whole app was covered. And I felt the pain.
Rich text editors suck. Let's not go into any more detail on this, as the editor I am writing this in right now is gobbling up memory and about to crash itself. How ironic. But to be fair, the YUI Editor is a fantastically useful component, and it was a joy to work with from a programming perspective.
Be ready (willing, and able) to make anything. The whole CMS vs Custom debate that came up was a total accident from my perspective. Going into the contest, I was all prepared to build a membership application with CSV exports and all that kinda stuff. But as it turned out, the primary audience for the site was so new to the internet that many of them wouldn't even have an email address. And the client already had an existing Access database - working that in with a time frame of 24 hours would have been completely ridiculous. So I ended up having to turn around and spend a lot more time on building a model for navigating and displaying chunks of content. A page based CMS. I wouldn't even want to use the term CMS, but that's how everyone interpreted it, and I'm not one to try and argue against others (entirely valid) perceptions. My initial plan was to throw together a contacts management app, and then shove in the page/news stuff with content in static HTML templates or Wordpress. What ended up happening was entirely different, but as it turned out, an elegant, simple, and clean solution.
</ol>