Hello, my name is Taylor Hughes.

I’ve spent a lot of time thinking about what I like about programming for a living, what I like about my job in particular and what could make it all even better — and I’ve boiled it down to four dimensions that need to be satisfied by a workplace to make it truly rock. I’ll call them “Taylor’s Dimensions of Developer Happiness.”

If you’re firing on all four cylinders, congratulations — you’ve found a great place to work.

The code: writing good software

As software engineers, the product of our toil is essentially a pile of text files — but the quality and composition of them is vital. Even more important is the collaborative, thoughtful process that goes into creating a lasting set of reusable, maintainable components.

Gauging this category might mean answering questions from the Joel Test, but there’s even more. How about some of these:

• Do you believe in testing? Does someone on your team freak out if a code path is untestable (or untested)?
• Do you do code reviews? Have you been talked into refactoring a nasty bit of code recently?
• Do you have deep discussions about the merit of various source control systems?

All of these things individually are great — but the more that resonates with you, the more likely it is that there’s experience behind the process you’re following to build good code.

The coworkers: working with people you like

I am a strong believer that the people you spend eight hours a day with should be people you’d gladly spend the rest of the evening with at a bar or restaurant. If you can’t get along with them over drinks, you sure as hell won’t be able to build a quality product with them.

That isn’t to say you should be best friends with everyone you work with — just that you enjoy spending the majority of your daily life with them and that you trust in their ability to make decisions that impact you on a daily basis.

This is mostly something that goes without saying, but it’s easy to glaze over or forget the importance of the team’s social makeup when you’re interviewing or distracted by a job offer.

The mission: building a great product

I saw a talk recently by one of the co-founders of Alice.com talking about what has led to the success of his previous start-ups. He said something to this effect: Start-up employees are on a mission to change the world; they need to know the mission and be revved up about the product to make it all come together. In fact, he said the start-up employee is one of the only advantages start-ups have.

Whether or not you work for a start-up, however, the mission is extremely important: You need to be commuting to work every morning for a reason.

You should be able to delve into an exciting summary of the work you’re doing and talk my ear off for about a half hour without stopping. It should keep you up at night. The end result of your work is extremely important: You need to be proud and excited about what you’re doing.

The challenge: learning as you go

The last dimension to developer happiness: The environment you work in should push you with new challenges on a constant basis. This means learning new things and venturing into unknown territory every day.

Lots of different things can be challenging, and in a start-up environment especially, challenges will crop up out of nowhere all the time: technological nightmares, interpersonal conflicts and everythingelseinal challenges abound.

But I think it’s important to put yourself in an environment that breeds those challenges, and to avoid situations you know you can handle.

The… end

And that’s it. This is mostly the product of my working in a small start-up and evaluating the options out there in the rest of the world — so, take it with a grain of salt. I am fairly certain, however, that if you can cover those four bases, the job is a great fit.

I just finished migrating DNZO to run on the webapp framework, after running on Django 1.0 via app-engine-patch for the past several months. I learned a valuable lesson in the process of switching: The webapp framework is really nice and, perhaps more importantly, way faster than using a zipimported version of Django.

It makes sense that using a zipped up copy of Django would be slow: You’re making the webserver inflate a copy of a framework you’re using to serve requests before it can serve them. The most important thing to note here, however, is that App Engine aggressively kills off application instances, especially during the day (when overall system load is presumably higher) — so you don’t get the opportunity to reuse those inflated copies of Django very often.

As a result, I ended up being hit with the initial load penalty frequently: Almost every request during the day took upwards of two full seconds. And that totally sucks.

So, I started out the transition by building a new section of DNZO that uses the webapp framework. Obviously you lose a lot of goodies provided by Django, but the webapp framework provides a basic class structure, some URL mapping and resolution, and it’s generally really nice and easy to extend. It provides nothing I don’t want, and the stuff I do want that it doesn’t have (like straightforward cookie support — really?) is pretty easy to whip up. Before long, I had a basic structure that worked well and I was ready to migrate the rest of DNZO to the same framework.

A few subversion commits later and we have the new version of DNZO: Now with page loads that are about 5 to 10 times faster than when using the zipimport’d version of Django. Fresh page loads usually take between 300 and 500 milliseconds, down from two to three full seconds: the difference between feeling slow and feeling pretty snappy.

I launched a new feature for DNZO last week: fast, JavaScript-based task sorting. Instead of forcing a new page load, tasks are sorted near-instantly on the client side. In order to enable bookmarking and the back button, I used the PrototypeXtensions.js library’s history manager — after a bit of hackery to get it working as I expected.

This move to JavaScript for sorting mirrors a common theme I’ve experienced in developing DNZO: I’ve slowly moved a lot of things over to the client side to increase responsiveness, minimize server-side requests and keep the requests that do need to happen light.

Original plan: JavaScript as frosting

When I started building DNZO, I initially designed the JavaScript side of things as sort of a frosting on top of the server side logic.

For example, clicking “edit” on a task fired an Ajax.Request to the edit link’s href (e.g. /t/1234), whose server-side counterpart supplied the markup for editing that task. It was really nice, because I had less state to manage and didn’t have to know anything about the structure of the tasks table. Similarly, script.aculo.us’s Ajax.Autocompleter initially loaded autocomplete suggestions from the server side by requesting something like /projects/?q=DN…, and the script just displayed the suggestions once it got them. The App Engine datastore did most of the work for me, and since the suggestions were updated whenever tasks were saved, I didn’t have to worry about suggestions becoming out of date.

The frosting technique provided three primary advantages:

1. Less client-side logic. When you write your app this way, the client side is pretty dumb. My edit link just replaced something with an Ajax call and the autocompleter just asked somebody else for suggestions. Totally straightforward and less prone to cross-browser quirks.
2. Cleaner initial markup. In the case of the edit button, I didn’t have to include each task’s inline-editing markup (e.g. input fields, submit button, etc.), so the initial page size was smaller. There were also fewer hidden elements sitting around and nothing output as JSON for client-side consumption — there was no need for it.
3. Very DRY. Using Ajax.Autocompleter for autocomplete meant the JavaScript side of things knew nothing of how to generate suggestions or how to keep a list of things to suggest. Moving this all to the client side with InstantAutocompleter meant I had to duplicate some of that functionality: I had to both update the list of things to suggest on the client side and permanently store that list of suggestions on the server side.

Unfortunately, the typical workflow for a user (read: me) ended up looking like this:

1. Try to do something (e.g. click “edit”, type in part of a project name, etc.).
2. Wait for an ajaxy spinner to stop spinning. Tap foot during a brief pause until the display finally changes.
3. Complete the action.

Hitting the “edit” link and then waiting about a second for the request to complete was frustrating. Waiting for a list of suggestions to come back from an Ajax call reduced its utility to a point where I just didn’t use the autocomplete at all. And, similarly, waiting for an entire page load just to reverse your sort order just sucked.

Revised plan: JavaScript provides core functionality

So, I have a new strategy: Make things happen instantly in your web app if you can, even if you have to repeat yourself in JavaScript and even if you have to work a little harder on the client side. Things need to happen immediately, or the app will feel slow.

I think the main issue is that I originally thought of DNZO as a web site rather than a web application. I didn’t realize that I valued the app’s responsiveness over its code zen factor — especially when the web app purports to help people get things, er, done-zo.