2011 in review: leaving Dreamweaver for a code editor

This is the year I stopped writing code that was mine, in two senses at once. In 2010 I had taken a full-time job as lead developer at an agency, running a team of four, and I stayed there through

2012. So everything I built in 2011 went into somebody else's system, on somebody else's server, under somebody else's conventions, and on somebody else's schedule.

By 2011 I was maintaining sites on four different content management systems at the same time, and the reason was simply that I had said yes four times. eZ Publish for the larger builds, Joomla and Drupal for inherited work, and hand-rolled PHP for the oldest sites.

This is the year that produced the rule I wrote about a year later, because it is the year the cost became impossible to ignore.

Four developers instead of one

The job is the thing that actually changed me that year. For seven years I had been the only person who touched my code, which means I had never once had to justify a decision, and every convention in every project was whatever I had felt like on the day.

With four of us, that stops working immediately. Somebody else has to read what I wrote and be able to continue it. Naming has to be predictable rather than clever. A branch has to mean something. A review is a conversation, not a formality.

It is the fastest I have ever improved, and none of it was about learning a technology. Most of my habits I could not explain out loud, and the ones I could not explain turned out to be the ones worth dropping.

I went back to working for myself in 2012, and kept the habits.

Out of Dreamweaver, into Komodo Edit

The change that actually altered my days: I stopped working in Dreamweaver and moved to Komodo Edit, a plain code editor.

That sounds small. It was not, because Dreamweaver had never really been an editor. It was the whole system: the site definition, the FTP credentials, the templates, and the sync file recording what it had already uploaded. Leaving meant giving all of that up at once and replacing it with nothing.

What I got back was a program that opens files and has no opinions about them. No sync database, no proprietary project format, no generated markup, no design view quietly rewriting my HTML because it thought it knew better.

The cost was real. Deployment and templating became my problem again, and for the better part of a year I was slower. I was also, for the first time, actually looking at every character that went into a page.

It was still the right move, and not only for the obvious reasons. Everything that had lived inside the editor was now in files I could read with any tool. That is the precondition for version control, for a build step, for a second person touching the project, and for every single thing I adopted in the fifteen years after it. You cannot put a sync database in a repository.

eZ Publish as the serious option

For anything with a real content model, eZ Publish was what I quoted. It took content types seriously in a way the lighter systems did not: you defined the structure, and the editing interface followed from it rather than being a pile of custom fields bolted onto a page.

I got far enough into it to sign a contributor agreement with the project and put work back upstream, which remains the first open source contribution I made that anyone else depended on.

What it cost was the learning curve. The template language, the configuration layering and the cache invalidation were all things you had to hold in your head, and none of it transferred to any other project. That is the trap with a powerful CMS: the expertise is worth a lot, and it is worth nothing anywhere else.

The other three

Joomla work is almost entirely updates. In April I was asked about a site still on 1.5.22, which is already end-of-life territory, and my answer was the one I always give: take a copy, upgrade it locally first, then do it live.

The reason I do not do that for everything is that setting up a local copy of somebody else's site costs half a day. If that were cheap, I would test every change that way.

Drupal appeared when a project needed PHP libraries the shared host did not have, which meant another support ticket, which meant another wait.

Meanwhile Flash was still being actively sold as a professional tool. I have the trial email for that year's release. It is genuinely strange to look at now.

Browsers did not agree about anything

Two threads from that summer, both from the same client, sum up the era. One: the site renders differently across Internet Explorer versions, plural, as though they were different browsers, which they effectively were. Two: the CMS editor is unusable in Safari, so the client boots into Windows on their Mac to update their own website.

The second one is the one that stings. The admin interface I had delivered worked on the browser I tested with, and my client's workaround was to change operating system. I fixed the alignment and added styling specifically for WebKit, and I remember thinking that testing in more browsers was a cost I would rather not carry.

Which is exactly backwards, and it is why "test with the thing the user actually has" is now non-negotiable for me.

In short

Spent the year employed as a lead developer with a team of four, left Dreamweaver for Komodo Edit, and maintained four content management systems at once.