Shifting to the client again

This is my take on the current shift to rich, in-browser JavaScript apps.

Looking back over a few decades, this is the progression of how applications have been built:

  1. mainframes and dumb terminals
  2. minicomputers and smart terminals
  3. networked workstations
  4. workstations and shared code/data repositories
  5. web apps and static HTML
  6. web services and rich browser apps

Translation: The main body of the application code lives on the:

  1. server
  2. server + client
  3. client
  4. server + client
  5. server
  6. server + client

The server/client pendulum swings back and forth. The next logical step is apps that run on the client using standard services. Just give it a few more years…

Modularized Association Methods in Rails 3.2

Happy Friday! It’s Rails 3.2 day! The official release announcement mentions a few of the big changes, but I’d like to take a moment to highlight a relatively small change I was responsible for, one that I hope may make your life a little easier.

From the ActiveRecord CHANGELOG:

Generated association methods are created within a separate module to allow overriding and
composition using `super`. For a class named `MyModel`, the module is named
`MyModel::GeneratedFeatureMethods`. It is included into the model class immediately after
the `generated_attributes_methods` module defined in ActiveModel, so association methods
override attribute methods of the same name. *Josh Susser*

The point of this change is to allow more flexibility in working with associations in your model classes. When you define an association, ActiveRecord automagically generates some methods for you to work with the association. For example, a has_many :patches association generates the methods patches and patches= (and a few others).

Previously, those association methods were inserted directly into your model class. This change moves those methods into their own module which is then included in your model class. Your model gets the same methods through inheritance, but also gets to override those methods and still call them using super. Let’s take a look at two ways this makes things easier for you.

Sometimes you want to replace the standard generated association methods. That’s always been easy to do simply by defining new methods in your model class. The only wrinkle was that you had to make sure you defined your method after you set up the association, or calling has_many would overwrite your method, since last writer wins. That was usually not a problem, but sometimes plugins or other monkey patching extensions could add an association after your model’s class was defined, which wouldn’t give you a chance to add your method afterwards. With this change, you don’t have to worry about those order dependencies anymore. Since those methods are generated in their own module, the order doesn’t matter. This is a pretty small issue all told and I doubt it affected many people, but it’s still worth mentioning.

The real reason for this change is being able to compose your own methods with the standard generated methods. Before this change, you’d have to use alias_method_chain or some other fancy footwork to layer your own logic on top of the standard association functionality. Either that or you’d have to somehow duplicate the standard behavior in your own method. Ick. Now you can compose methods using inheritance and super, the way Alan Kay intended you to. Here’s the example from the docs:

class Car < ActiveRecord::Base
  belongs_to :owner
  belongs_to :old_owner

  def owner=(new_owner)
    self.old_owner = self.owner
    super
  end
end

If you’re familiar with ActiveRecord it’s probably fairly obvious what’s going on there, but I’ll spell it out for the new kids. When you define the belongs_to :owner association, that generates a standard owner= method, and puts it in the module named Car::GeneratedFeatureMethods, which is the closest ancestor of class Car. If you’re curious what this looks like, fire up the rails console and type Car.ancestors to see the class’s inheritance chain. (Or use your own app and model, since that will be much easier than making up a new app just to see that one thing.)

In this Car class, you can see that changing owners keeps track of the old owner, so the new owner knows who to call when he can’t figure out how to open the trunk. The generated owner= method does a fair amount of stuff including managing counter caches, running callbacks, setting inverse associations, etc. Skipping that could break a number of things, so after saving the old owner, you also want to run the generated method. Since it’s in a module that Car inherits from, you only have to call super to get that to run. No muss, no fuss!

One more step towards simpler OOP in Rails! Thanks to my fellow Ruby Rogues Avdi Grimm and James Edward Gray II for complaining about the old state of things enough to motivate me to finally go fix this.

Yak Shaving

As coders, most of us are not only familiar with the term yak shaving, but spend many of our days doing nothing but. I often struggle to explain to non-technical folks what I actually spend my time doing when I’m working and what it feels like. This is the most accessible explanation I can come up with.

Say you want to go see a movie with your friend Joe. You can’t get away with leaving the house when the kitchen is such a mess, so you have to load and run the dishwasher before you go. Unfortunately you’re out of detergent, which means you have to run to the store to pick some up. You want to ride your bike or it will take too long to get to the store. But your bike’s front tire is kind of low, so you have to pump it up first. However, your roommate borrowed your tire pump and you don’t know where it is, so you have to go find your roommate and ask him about it. He’s over at a neighbor’s place having band practice, but it’s just a short walk. When you get there they are in the middle of practice so you have to wait for a few minutes. The only place to sit is on that ratty old sofa, right next to the drummer’s sister, Monica, who will only let you sit there on the condition you smoke a joint with her. But before you can do that you have to dig around in the seat cushions to find the lighter she just realized she lost. You manage to find the lighter, and before too long you are smoking out with Monica. The band finishes the number and your roommate comes over to see what’s up. You take another hit off the joint and say “Hey, we should order a pizza.”

I heard you liked files

I was going to try and be clever and do a funny riff on this whole subject, but I just can’t manage it. Here’s the thing. Makefile was a dumb name for a file when Stuart Feldman wrote the make utility in 1977, but you have to forgive him because file systems were quite limited back then and filenames could only be a few characters long. The pattern was <filename.ext> – 8 chars for the name, 3 for the extension. I guess config.make wouldn’t fit, config.mak looked weird, so Makefile it was.

Now we have no excuse. At all.

I respect and adore Jim Weirich, but I hope he feels at least a little shame for inflicting “Rakefile” on us all. That name choice seems to have set the stage for a proliferation of copycats. Now we have an ever-growing assortment of files that helpfully tell us they are files right there in the file name. Because something siting in a directory in the file system might be something else, like maybe a turnip or a bad hair day. Capfile, Gemfile, Assetfile, Vagrantfile, Guardfile…

You may ask: What’s the problem? Why should anyone care about a cute little naming convention that continues a tradition going back over 30 years?

It may not be a huge deal, but there are a couple issues with this. All of these file formats are actually a variation on a well-accepted language: Ruby. But with a name that omits the standard .rb extension, language-aware tools have no chance to help us out. Syntax highlighting? Nope. Will awk search those files for you? No way. Will RubyMine figure out the structure of the code in those files? Forget it. OK, you can add those files to all your tools’ configurations, then you’re good to go. Until someone creates a new Crapfile and you have to go through and update all those configurations again.

Just because your configuration file’s contents are written in a DSL does not mean you should pretend it’s not Ruby anymore.

I urge every maintainer of a project that uses a name like Crapfile for the configuration file to move toward using a name that is compatible with language-aware tools. If you can’t think of a name yourself, allow me to suggest this:

filename.sub(/file$/, '_config.rb').downcase

UPDATE: It has been pointed out to me that RubyMine actually does a pretty good job of dealing with these file names. Not perfect, but pretty good. Anyway, I don’t want to come off as bashing RubyMine (I’m spending more time with it now and it’s starting to grow on me), so substitute vim or emacs or TextMate or your most-hated editor instead.

Refactoring: be eager, not reckless

The illustrious Chris Eppstein recently tweeted:

If some code should be refactored, stop what you are doing and refactor it.

I was about to respond, but realized I had more to say than would fit in a tweet. (Waiting for someone to fix that problem!) (Then I got distracted and didn’t finish this article for a few days, oops.)

Now, Chris is really smart and probably doesn’t mean exactly what he said, but it’s easy to misinterpret his advice. I’ll agree with him that you should be eager to refactor code when you discover the need. Don’t let that technical debt accrue interest longer than necessary! However, you shouldn’t be reckless about it.

Please keep this in mind:

Don’t do a refactoring in the middle of making another change.

If you are working on a story and in the middle of making a code change when you discover the need to refactor something, make a note of it (I usually create a chore in Pivotal Tracker) and forget about it until you’re done with the change in progress. After you complete the change, come back and do the refactoring. Make sure all tests are green before starting to refactor, and are green when done. The refactoring change should be a separate commit in git (separate checkin in SVN, etc).

OK, I’m pragmatic and realize that that approach doesn’t work all the time, but it’s a good ideal to shoot for. I considered discussing cases where it would be OK to refactor something in the middle of another change, but on second thought I think I’ll leave that be for now. You’ll learn that for yourself better than by following someone else’s advice on the subject.

Fifteen Protips for Conference Speakers

Do you dream of someday speaking at a technical conference? Have you spoken at a conference but felt like your journey to the podium wasn’t as smooth as it might have been? Well here are a couple tips to make things go smoothly and endear you to your conference organizers.

I’m writing this from the perspective of a conference organizer where my main focus is the technical program. I’ve run into a lot of these issues when putting together Golden Gate Ruby Conference, and also seen things from the other side when speaking at other conferences.

A lot of this list is about not being a problem for the conference organizers. I hope that doesn’t come off as too negative, but I figure most speakers don’t realize the potential impact of seemingly little things. Making things easier for the organizers makes for a better conference for everyone, and your presentation will be even more awesome.

  1. Respect your conference organizer’s time. Organizing a conference is far more work than you realize, and for small, regional conferences it’s usually volunteer work. Managing the program is extra fun because dealing with a bunch of speakers makes herding cats look as easy as napping on the beach. There are speakers I’ll never have speak at my conference again because they are too hard to manage, even though they are awesome on stage. A good organizer will respect your time, and you should do the same in return.

  2. Respond to all emails promptly. Read the whole email, and answer every question asked of you. This may seem like kid’s stuff, but you’d be amazed at how many times I email a speaker and they never reply, reply without answering important questions, or miss the point of the email entirely. Then I have to send another email or two. Multiply that by a dozen or two speakers and you can see how that can create a lot of extra work. (also see #1)

  3. Get a good headshot. Any conference will probably want a photo of you for the website. Some confs want “professional” (i.e. boring) photos, while others like shots that show more personality, so maybe you want to have more than one handy. Either way, you want a photo that shows your face well.

  4. Have someone else write your bio. Most confs want a short bio of you for the website/program. Most people hate writing those things about themselves, so get someone who knows you to write one for you. Remember, this isn’t a resume to get a job. The point is to tell people why they should care about what you have to say.

  5. Don’t announce that you are speaking until after the conference does. Alright, some conferences won’t care about this at all, but most will want to manage their own publicity and control the timing of announcements. And sometimes speakers aren’t all informed at the same time whether their talk was accepted, so making your own announcement can confuse things.

  6. Do announce you are speaking! Once you know it’s cool to announce, do it! Conferences love the publicity, and you will too. Tweet it, blog it, Facebook it…

  7. Proactively communicate any special requirements you may have for your talk, scheduling, etc. It’s usually simple to deal with requests if they come early enough, but can be impossible if they come the day of the conference. Things that might require special attention:

    • you can only speak on one of the days of a two-day conference
    • you need an uncommon connector for your laptop
    • you need the house lighting dimmed during your talk
    • you will have extra people on stage who also need microphones
    • you need a table on stage with power strips for your science experiment
    • you need a wireless microphone so you can stroll around the audience
    • you need a bar stool because you can’t stand for 45 minutes
    • you need wheelchair access to the stage
    • your talk requires network access
    • you need a lot of network bandwidth for your talk
  8. Prepare your talk in advance. You don’t want to be that guy who gets up on stage and says, “Sorry I didn’t have time to prepare my talk, so I’m just winging it.” Hundreds of people are giving you their valuable time to see your talk. The least you can do is respect them enough to prepare in advance. You’re also better off preparing your talk before the conference starts. Take it from someone who spent most of a RailsConf working on his talk instead of seeing other talks and enjoying the conference.

  9. Have awesome, readable slides. You can read up on how to make readable, attention-grabbing slides that effectively support your presentation. Please do. You can start with Shane Becker’s Better Presentation Slides lightning talk from GoGaRuCo 2010 (at the 45:05 timecode).

  10. Send your slides to the organizer. PDF is usually a good common denominator format, but including the original helps if your presentation has builds, video, etc. Sending multiple formats is great to cover all your bases. Some confs ask for your slides in advance, but that seems far less common these days when you don’t have an A/V team running your slides for you, so don’t forget to email your slides when you’re done with your talk. Even if you are posting your own slides online, send the PDF/originals to the conf as well so they don’t have to find them online to get them.

  11. Practice your talk. Run through it several times. Do it facing yourself in a mirror. If you can video yourself and watch it, that’s really helpful too. If you don’t have a lot of experience speaking, try out your talk with coworkers or friends who can give good feedback. And don’t be afraid to modify your talk based on feedback – that’s why they do previews for theatrical productions.

  12. Get some sleep. Don’t stay up to all hours partying the night before your talk. Nobody wants to be that guy who drunkenly fell off a fire escape and has to wear giant sunglasses to hide the black eye. You want to show up on time, rested, and raring to go.

  13. Don’t flake out. There’s nothing worse than not showing up. Canceling at the last minute is nearly as bad. If you think it’s likely you’ll have to cancel, don’t commit to doing it. If something comes up and you can’t make it, let the conference know as soon as you can.

  14. Look your best. For many conferences (GoGaRuCo included) wearing jeans and a geek t-shirt is great, while others want something a bit more formal. But even if you just do jeans and a t-shirt, you want something that you feel great wearing. A good rule of thumb is to dress one level up from how you’d dress as an attendee. Also, take off your conference badge when on stage – it’s distracting and looks bad.

  15. Have fun! Odds are you aren’t getting paid to speak, so you might as well enjoy yourself! Seriously, you’ll do a better job and be a more effective speaker if you are enjoying what you’re doing.

just a thought

We live our modern, high-tech lives immersed in a sea of devices and systems powered at least in part by open source software. It’s amazing how much of our lifestyle we owe to the generosity of geeks. I wonder how many non-technical folks appreciate that.

Slightly more readable Ruby

A simple coding style for slightly more readable Ruby: symbols as flag arguments.

Use a symbol with a meaningful name instead of true. This makes it clear what you’re doing and is just as terse. For example:

def run(log_it = false)
  log_action if log_it
  run_action
end

command.run(true)           # mysterious use of `true`
command.run(:with_logging)  # obvious

The second call to #run is functionally equivalent to the first, because every symbol is a truthy value. But it’s a lot easier to read the code with the symbol and understand what the argument means.

The other common pattern I see in Rails is to use an options hash. That call would look like

command.run(:with_logging => true)

If you have a bunch of options, that’s fine. When it’s just a single optional flag, I prefer passing a symbol with a meaningful name.

Limitless Strings for PostgreSQL

We all love ActiveRecord migrations and the sexy DSL for declaring fields. OK, I don’t know if you do, but I sure do.
But life isn’t perfect (don’t get me started), and there’s various details that make using the migration DSL a bit of
a pain.

The one thing that has annoyed me for ages is how string (VARCHAR) fields are handled for PostgreSQL. While the standard for SQL
requires you specify a limit for the length, PostgreSQL is more flexible. From the PostgreSQL docs at http://www.postgresql.org/docs/current/static/datatype-character.html:

If character varying is used without length specifier, the type accepts strings of any size. The latter is a PostgreSQL extension.

Unless your string field needs a limited length for semantics (like a SSN or ZIP code), it’s better not to specify
a limit for VARCHAR fields.

The problem is that ActiveRecord follows the SQL standard and insists on Continue reading “Limitless Strings for PostgreSQL”

Limitless Strings for PostgreSQL

We all love ActiveRecord migrations and the sexy DSL for declaring fields. OK, I don’t know if you do, but I sure do.
But life isn’t perfect (don’t get me started), and there’s various details that make using the migration DSL a bit of
a pain.

The one thing that has annoyed me for ages is how string (VARCHAR) fields are handled for PostgreSQL. While the standard for SQL
requires you specify a limit for the length, PostgreSQL is more flexible. From the PostgreSQL docs at http://www.postgresql.org/docs/current/static/datatype-character.html:

If character varying is used without length specifier, the type accepts strings of any size. The latter is a PostgreSQL extension.

Unless your string field needs a limited length for semantics (like a SSN or ZIP code), it’s better not to specify
a limit for VARCHAR fields.

The problem is that ActiveRecord follows the SQL standard and insists on a limit of 255 if none is specified.
So if you define a field thusly:

create_table "users" do |t|
  t.string "name"
end

That is equivalent to

CREATE TABLE users (
  name character varying(255)
);

OK, you think, I know what to do. I’ll specify a limit of nil!

create_table "users" do |t|
  t.string "name", :limit => nil
end

But no, that doesn’t work. A nil limit is ignored and the default 255 is used anyway. There’s a tiny patch for that I
might pursue, but in the mean time there is a pretty simple workaround.

Drop these lines into application.rb (assuming you are on Rails 3.0 or greater) within the Application class definition:

initializer "postgresql.no_default_string_limit" do
  ActiveSupport.on_load(:active_record) do
    ActiveRecord::ConnectionAdapters::PostgreSQLAdapter::NATIVE_DATABASE_TYPES[:string].delete(:limit)
  end
end

That removes the default limit for string fields. Problem solved. And that’s even nicer than saying :limit => nil anyway.

And also, this is pretty cool. I got to use one of those fancy ActiveSupport initializer hooks. Let me explain in case you haven’t
used one before. What that’s doing is waiting until the active_record library is done loading, then running some code to
act on the initialized library. That ensures that the default value is removed after it’s been created, but before anyone gets
a chance to use it.

Limitless Strings for PostgreSQL

We all love ActiveRecord migrations and the sexy DSL for declaring fields. OK, I don’t know if you do, but I sure do.
But life isn’t perfect (don’t get me started), and there’s various details that make using the migration DSL a bit of
a pain.

The one thing that has annoyed me for ages is how string (VARCHAR) fields are handled for PostgreSQL. While the standard for SQL
requires you specify a limit for the length, PostgreSQL is more flexible. From the PostgreSQL docs at http://www.postgresql.org/docs/current/static/datatype-character.html:

If character varying is used without length specifier, the type accepts strings of any size. The latter is a PostgreSQL extension.

Unless your string field needs a limited length for semantics (like a SSN or ZIP code), it’s better not to specify
a limit for VARCHAR fields.

The problem is that ActiveRecord follows the SQL standard and insists on a limit of 255 if none is specified.
So if you define a field thusly:

create_table "users" do |t|
  t.string "name"
end

That is equivalent to

CREATE TABLE users (
  name character varying(255)
);

OK, you think, I know what to do. I’ll specify a limit of nil!

create_table "users" do |t|
  t.string "name", :limit => nil
end

But no, that doesn’t work. A nil limit is ignored and the default 255 is used anyway. There’s a tiny patch for that I
might pursue, but in the mean time there is a pretty simple workaround.

Drop these lines into application.rb (assuming you are on Rails 3.0 or greater) within the Application class definition:

initializer "postgresql.no_default_string_limit" do
  ActiveSupport.on_load(:active_record) do
    ActiveRecord::ConnectionAdapters::PostgreSQLAdapter::NATIVE_DATABASE_TYPES[:string].delete(:limit)
  end
end

That removes the default limit for string fields. Problem solved. And that’s even nicer than saying :limit => nil anyway.

And also, this is pretty cool. I got to use one of those fancy ActiveSupport initializer hooks. Let me explain in case you haven’t
used one before. What that’s doing is waiting until the active_record library is done loading, then running some code to
act on the initialized library. That ensures that the default value is removed after it’s been created, but before anyone gets
a chance to use it.

GoGaRuCo 2010

Hi readers, long time! I’ve been meaning to post but you know how things get with work and yoga and all that. Also, I’ve been kind of busy working on organizing Golden Gate RubyConf 2010 for a while. The great news is that we’re on!

It took us longer than we wanted to find a venue good enough to do justice to such a great group of people, but we finally found an awesome spot. The conference will be at the UCSF Mission Bay conference center on September 17-18. Registration is now open! We’ll have more room than last year but space is still finite, so don’t delay. Early bird pricing is available through next week.

We’ve announced an initial group of speakers and have more on the way. Right now we’re focusing on invited talks, but we may have some room for people to submit talk proposals – we’ll pretty know soon and will let you know. Follow @gogaruco on Twitter for announcements and new speaker updates.

Just like last year it will be a single-track conference on a Friday and Saturday. Moving the conference to September means that we’ll have great weather too. The venue is really top-notch with great facilities.

We did kind of spaz by doing the conference on Yom Kippur (what would my mother say?), and I’m sorry if that is a conflict for people who would like to be there. There are only so many weekends in a year and none of them are perfect…

Go check out the site for info and to register: http://gogaruco.com/

No returns

Chris Wanstrath makes a good point about an ugly way to initialize a variable, but I don’t agree that an explicit return is the best style to use.

The original ugly:

def logger
  unless @logger
    @logger = Logger.new(STDOUT)
    @logger.level = Logger::WARN
  end
  @logger
end

Chris’ improvement:

def logger
  return @logger if defined? @logger
  @logger = Logger.new(STDOUT)
  @logger.level = Logger::WARN
  @logger
end

I prefer a functional style:

def logger
  @logger || begin
    @logger = Logger.new(STDOUT)
    @logger.level = Logger::WARN
    @logger
  end
end

This is actually slightly awkward. I’d usually do @logger ||=, but that’s hard to do gracefully since here you have to combine a few statements to create the new logger. A better constructor or a #level method that returned self would be so much nicer. A small refactoring seems a bit more readable.

def logger
  @logger ||= default_logger
end

def default_logger
  logger = Logger.new(STDOUT)
  logger.level = Logger::WARN
  logger
end

And if you really like functional style and are a fan of the K combinator:

def logger
  @logger ||= Logger.new(STDOUT).tap {|l| l.level = Logger::WARN}
end

I am almost always opposed to using an explicit return in Ruby code. Whenever I see one I cringe. You can sometimes make a case for one as a top guard in a medium-sized method, but here’s where I invoke the slippery-slope argument. It’s too easy for those things to snowball into a handful of return statements, and then someday you’ll have to wonder if they have to be in that order or not. And when your method gets long enough, you can easily miss that there was a return at the top and mess up a refactoring; using an if/then/else makes it clearer and harder to miss.

By the way, using if defined? @logger the way Chris does is not the same thing as if @logger.

>> defined?(@logger)
=> nil
>> @logger
=> nil
>> @logger = nil
=> nil
>> defined?(@logger)
=> "instance-variable"

If you’re trying to make sure @logger is not nil, defined? is unlikely to be the way you want to test the variable was initialized. Be careful out there, kids…

UPDATE: Oh awesome, it turns out that Logger.new takes a 2nd arg, the level. So this could all be done with:

def logger
  @logger ||= Logger.new(STDOUT, Logger::WARN)
end

Just pretend this whole thing was about some other class where this actually mattered.

RubyConf 2009 Lightning Talks

Last night it was my great pleasure to host the Lightning Talks session at RubyConf 2009. We had an amazing series of 20 talks that took just over 2 hours. The tech gremlins seemed to be off drinking somewhere and none of the presentations failed.

Here’s a list of all the speakers and links to their stuff.

RubyConf Schedule

The RubyConf 2009 schedule was just posted. As a public service, I have fixed it to be readable and to use, you know, hyperlinks and stuff. Enjoy.

http://hasmanythrough.com/rubyconf2009/schedule.html

(Apparently my planning for GoGaRuCo 2010 has me thinking it’s 2010 already. Fixed the year. Sorry about that. Sigh.)

Pair programming isn’t right for all projects

My hat’s off to Obie Fernandez for his recent article 10 Reasons Pair Programming Is Not For the Masses. I don’t actually agree that only the elite are cut out for pair programming, but I do think he’s on target with his list of obstacles to effective pairing.

There’s another axis to consider for fit, however, and that’s the suitability of the work itself for pair programming. I don’t mean the product domain or the kind of application being written, but rather the technology and tools used to build it.

I started pair programming when I was a freshman in college. My CS10 lab section had 20 students and only 10 computers, so we had to pair up. No one told us anything about how to pair; we just did it. It wasn’t really a big deal since students are used to helping each other with class assignments. I think the pairing was valuable for learning, but there was a problem. The problem was Pascal. Specifically, the length of time spent compiling the code every time we made a change. We’d write some code, then fire up the compiler and play Pascal (the game of seeing how many dots you can generate before you get a compiler error). Compiling took a long time, anywhere from 5 to 20 minutes, depending on how big the program was. So what do you do with your pair during that time?

There are all sorts of reasons we hate long wait times during development, whether from compiling, running tests, deployment, or whatever. While it can be nice to take an enforced break now and then, the disruption to flow is a significant obstacle to productivity and quality of work. A five minute interrupt to your flow is murder to your mindset and caustic to your collaborative bond.

After college I worked at Xerox, programming in Smalltalk on a team of about 8 developers. We tended to pair a fair amount, maybe a quarter to half of our time on average. But at other places I worked, we paired a lot less. I’m sure some of that was cultural, but I think a lot of it was because of the technology. Programming in the Smalltalk environment really good for keeping the flow going. Do some coding in a method and save the code, and a second or three later you can see the results. This made pairing so much easier because we could keep our focus on the coding. It’s hard enough to keep the pair in a good mode when things are going well, but to have to stop for a few minutes every few minutes adds too much frustration, and the easiest place to direct that frustration is onto your pair.

So if your project is not amenable to a rapid, incremental development cycle, it’s going to be a lot harder to keep people pairing on it. I guess that leaves two options. You can punt on pairing, or you can fix the technology so that you get the fast development cycle necessary for maintaining flow. Can you guess which one is going to be better for you?

Discipline and creativity

I was chatting with a friend over dinner this weekend about the impact of work environment on one’s ability to excel as a software developer. We’ve both worked for companies where we’ve had to work far more than 40 hours each week for extended periods of time. We both agreed that’s a good way to burn out your staff and, more importantly, a bad way to get stuff done faster. Sure, you can do an intense sprint now and then, but you don’t win a marathon by running full out the whole way.

The comparison I came up with was that writing software is a lot like writing literature. It takes both discipline and creativity. Having either of those attributes will only get you so far (though it will probably put you ahead of most of the pack). To truly excel you must have both.

Discipline is not about putting in long hours (well sometimes it is, but that’s not what I’m talking about). Discipline is about consistency. It’s like playing blackjack and counting cards – your system won’t pay off on every hand, but over time you will reap the rewards. Agile development is very much about that kind of discipline. You write your tests, go red, go green, refactor. This aspect of software is craftwork. It’s methodical. It’s not very exciting, but it gets you from point A to point B, and for the most part it’s predictable.

Putting in 60+ hours a week is not good for your creative output. Being creative requires a brain that is rested and energized. It also takes mixing things up, changing perspective frequently. Burnout is the enemy! Sometimes when I’m stuck I’ll get up and walk around the office, have a 5 minute chat with someone about something random. When I get back to my desk I can deal with the issue much better. Or if my pair and I get stuck, we’ll put the story on hold for a little bit and tackle something tiny that lets us reset our perspective. That sort of thing usually helps a lot. We know enough not to try something really tough late in the day, and sometimes we save doing a fun story as a reward for finishing something that’s no fun at all. Our brains naturally have attention spans that are too short to keep up with what we ask of them. Learn how to work with your brain instead of forcing it to do something it’s not suited for.

There is a balance, and a way that discipline and working creatively mesh. Find a rhythm that works and that you can sustain, then stick with it. Back when I was trying to write science fiction, I got to talk to Cory Doctorow about his practice of writing. His advice was to write a page every day, then send it to people to get feedback. Pretty simple, eh? Cory produces a lot of fiction and I find it shocking that he only does a page a day. But a page a day lets him do a novel and a few short stories in a year, which is a lot more than I ever wrote when I was trying. I think he can probably keep that pace up forever. Sustainable pace wins.

One of the things I like best about working at Pivotal is that we consistently work at a sustainable pace. I can’t believe how many startups advertise jobs where they say that they expect you to work “startup hours”. I won’t even consider working at a place like that ever again. It’s not just because I don’t like working that way myself, but because I think companies that expect and require that kind of pace from their developers are just going to screw themselves and burn out their developers. They’ll either get real about what they can sustain, fail, or figure out how to deal with a high attrition/turnover rate.

Then there are companies that have no discipline and rely only on their “rock star” developers being able to come up with one inspired solution after another. Now, inspiration is great, but it doesn’t get you even halfway there. People don’t pay you for your ideas; they pay you for how you execute on them. If all you ever did was sit around and think up great solutions for difficult problems, you wouldn’t ever get anything done. And if all you ever did was play Rock Band, you might be very inspired but you’d never finish writing Duke Nukem Forever.

As an ENTP (the personality type, not the company), working in a team is the only way I can consistently get things done over a long period. I can be super productive working with other people, but working on my own can be very challenging for more than a short time. It’s much easier to keep up my discipline when I’m pairing since that helps me stay focused, and I can be very creative too, since I think better out loud. I know that way doesn’t work for everyone, but it sure does for me. I also love tools like Pivotal Tracker that let me easily see what I have to work on next so I don’t have to keep figuring it out every time I finish a task and need something else to do. On the other hand, I’m not a Calendar-About-Nothing kind of guy.

That’s enough philosophy for the evening. But I’m curious to hear what other people feel about the interaction of discipline and creativity.

It’s a wrap!

We’re finally getting all our after-conference activities completed. The most exciting thing is that we just got our conference media online. We have video and audio recordings of the Golden Gate Ruby Conference technical sessions! Pivotal Labs sponsored the recordings, and is hosting them at pivotallabs.com/gogaruco – you can watch them there or download the files to watch later, or get them from the iTunes podcasts.

We also are trying something new (for Ruby confs, at least). We have put together a 42 page PDF zine, the Golden Gate Ruby Wrap, in order to document the conference, the speakers, the sessions, and the attendees. There are a lot of photos of the event, speaker bios, talk write-ups, and even interviews with attendees. It’s the official record of the conference (as official as we get, anyway), and it’s free.

Just because people have been asking, I’ll say that Matt Aimonetti’s talk on CouchDB is not included in the talk videos. Matt didn’t want to offend anyone else, so he asked the talk recording not be released. Please don’t ask for a copy privately, as I can’t help you out. However, there is a great write-up of Matt’s talk in the Wrap.

I’d also encourage you to check out the gogaruco blog posts at Pivotal Labs – there are articles for every session at the conference. Sarah Allen also blogged many of the sessions at her site. Know of any other good posts about sessions? Let us know in the comments.

And if you want to see how things looked, there are a lot of good photos up on flickr.