Let’s take a look at some simple code on our Hamburger model, which inherits from ActiveRecord::Base and has a created_at column.

>> whopper = Hamburger.create!(:cheese => true)
=> #<Hamburger id: 1, cheese: true, created_at: "2009-06-12 07:44:48">

Cool, now we can eat. Let’s load up another copy of this hamburger instance because company is coming and physics is no barrier.

>> whopperjr = Hamburger.find 1
=> #<Hamburger id: 1, cheese: true, created_at: "2009-06-12 07:44:48">

Super. Our cheese is safe, and we still know how old it is, which we can use in should_i_eat_this? But something funny has happened. Let’s tinker a bit.

>> whopper.created_at == whopperjr.created_at
=> false
>> whopper.created_at > whopperjr.created_at
=> true

Huh? Now that’s weird. Time is fooling around on me, and I don’t trust that my sandwich is edible anymore. Let’s take a closer look.

>> whopper.created_at.to_f
=> 1244792688.91866
>> whopperjr.created_at.to_f
=> 1244792688.0

Now isn’t that something? Here’s what’s going on, in slow motion*:

>> whopper = Hamburger.new
>> whopper.cheese = true
>> whopper.created_at = Time.now  # 1244792688.91866
>> whopper.save!
=> #<Hamburger id: 1, cheese: true, created_at: "2009-06-12 07:44:48">
>> whopperjr = Hamburger.new
>> whopperjr.cheese = true
>> whopperjr.created_at = Time.parse("2009-06-12 07:44:48")  # 1244792688.0
=> #<Hamburger id: 1, cheese: true, created_at: "2009-06-12 07:44:48">

Our whopper has been assigned a Time object that represents right now, including all the fractions of a second you could want. Sadly, when the value is dumped into MySQL’s datetime column, the fractional portion is dropped on the floor. When loaded back into memory, then, whopperjr has forgotten exactly when it was pulled off the grill, and has to run with the less accurate representation, leaving us with an object that was actually created before it was created!

Now if only Doc Brown had known this, he could have saved a lot of trouble from those Libyans.

*No, it’s not entirely accurate, ActiveRecord is using integers, not strings to talk to MySQL. Let’s call it isomorphic.

Other days, the slightest passing thought or noise distracts me, and I’m constantly checking my email, opening news sites or blogs in new tabs, and getting up to get snacks or drinks.

Today was one of those distractible days. After watching the inauguration in the morning, my mind was abuzz with thoughts about politics, the economy, the future… pretty much anything but work.

I’ve tried a few mechanisms for dealing with days like this, before finally landing on one that seems to work and results in me still getting things done. I’ve tried to power through it, and work on exactly what I otherwise would have worked on, but distractions pop me out of my mental constructions, and I have difficulty solving big problems. I’ve tried leaving work for some time to allow myself to be distracted, but this almost never results in a quick return to productivity.

The final approach, which I used today, is to take advantage of the distractibility to deal with all of the small niggling tasks that have been building up over time. Tiny and annoying tasks lend themselves to distraction regardless of mood. There is a natural breath after the completion of any task, so even when feeling focused, a series of small tasks lends itself to more interruption and wasted time than a single larger task. When I’m in a distractible mood, I’m going to be wasting that time anyway, so its an ideal time to get rid of these annoyances without detracting from what I could be getting done.

So instead of making progress on my larger tasks, today I spent my time on a myriad of small tasks. I investigated a number of reports from our support team, fixed a few bugs I found with that, refactored some controller logic for our Birthday Cause feature to make it easier to reorder pages in various flows, merged in a lingering branch of cleanup from our last fixit day, and made a number of other small tweaks, fixes, etc.

None of these was very big, none of them very interesting, but all needed to get done at some point. By leaning into my distractibility instead of fighting with it, instead of a wasted day I’m going home with a list of things I no longer need to worry about.

Our whole engineering team uses Campfire to communicate. We have our git commits, our continuous integration testing (via CruiseControl), our deploy notices and our homegrown AI bot all in the room with us.

Whether one of our engineers is looking for a code review, some advice on a design decision or is logged in at 3am to deal with a server failure, Campfire provides a single point of contact that makes our team’s communication smooth, immediate and persistent. We can search back in the chat’s history, browse logs of conversations we missed and easily find files and images that our teammates have shared.

We’ve had a few people say something to the effect of, “isn’t this just a re-implementation of IRC?” To some extent, yes, it is a re-implementation of an instant chat mechanism. But Campfire’s strengths are in its universal accessibility (all you need is a web browser), its built-in transcript logging and searching, and its easy file and image sharing. This is one case where a commercial product found a niche in a market that was assumed to have already been satisfied.

If you’re using Campfire too, be sure to check out site-specific browsers like Fluid or Propane for Mac OS X, and Prism more generally. They can be a huge help, leaving your primary web browser for web browsing while you maintain a Campfire session on the side.

How might one go about that, you ask?

1. Be yourself. The single most important component of your career search is you and your personality. You will never be thoroughly happy with a job that doesn’t fit your personality, so the best way to ensure that you find a fit is to never be fake. No “Dear Sir/Madam”, no “I greatly appreciate your time”, no nonsense. Be polite, but be honest, direct and confident.
2. Know what you want. – It’s crucial to decide what you want to pursue and stick with it, at least for a single round of job applications. A candidate who is direct and unambiguous is much more likely to get a quick response than one who is amorphous and uninspiring. Your mission when applying for a job is to be sure of what you want to do, for how much, for how long, and be memorable enough to achieve it.
3. Make a clean, strong résumé. – You have less than 30 seconds to make an impression with your résumé. If you’re applying for a chemical engineering job, don’t include your position as Manager of Taco Bell on your résumé. Your résumé is your chance to sell yourself for the position you’re applying for, so it should reflect you in the best possible light for that specific position. Don’t lie, but omit things that are irrelevant. Keep it short (one page), keep it clean and make sure only the most important pieces of information remain.
4. Know your mark. – Research the company and its products. If the products or services are publicly available, try them out and write up a quick critique. You don’t have to impress the company with your knowledge of their business, but you do need to build up enough mental ammunition to give you a fighting chance in any phone or on-site interviews. Further than that, you need to find out if this is really the type of place that you could be happy. Be vigilant about the details of your correspondences and conversations with the people who work there. Are they happy? Stressed? Candid? Are they your kind of people?
5. Ask hard questions. – When you do get a chance to speak with an interviewer and they ask you if you have any questions, make sure you have at least one good one ready. You’re not trying to confuse or impress the interviewer; your goal is to dive deeper into the company than you’ve previously been able. Ask about their revenue stream, their typical process for handling product crises or their adherence to their company vision. The question should give the interviewer pause, but they should feel obligated to respond frankly. Don’t ask about benefits or vacation—those just make you sound needy and are always incidental and up for negotiation at a later date. Instead, focus on the internal parts of the company that are most crucial to its long-term sustainability as an awesome employer. They are not doing you a favor by interviewing you, so behave as if they should actually want to hire you for your brilliance.

The gist of this seems like something that ought to be mostly common sense: be yourself, be good, be direct; but most people searching for a job are still busy taking résumé templating courses and filling out endless job applications for mindless corporations instead of finding the places that are actually worth working for. There are always jobs out there worth having—and don’t even think about protesting with an “in this economy…” cop-out; it just takes a bit of work to find them and show them your obvious genius.

Who knew?

Steve Randa Shave to Save

Jason Gramke Shave to Save

Jason Fortune Shave to Save

Andy McGinnis Shave to Save

A week ago, these four causes were created with an interesting idea. Each of these people put themselves in the running to have their head shaved bald in support of the American Cancer Society’s Shave to Save program. The two of them who get the most votes will be put under the razor, and the fun part is how you cast a vote: with a dollar. Each dollar donated to your cause gets you closer to a smooth, shiny, hopefully-not-sunburnt scalp.

This creates a dynamic that you don’t see in typical fundraising runs. Rather than getting your friends to support you while you walk/ jump rope/ juggle, you’re rallying your other friends to help you stick it to the ones involved in the competition. You activate four networks of people (though in this case there’s likely a lot of overlap) who can now feed off of each other in two ways:

• A Bidding War – If I convince my group of friends that it would be the most amusing to see Steve without hair, we’re all now interested in keeping his votes highest. And what does that mean? More donations to Steve’s cause. As other groups decide on other targets, we get into a classic bidding war, a concept that we otherwise haven’t seen yet in our application.
• Anyone but Me! – If I’m picked as a target, on the assumption that I’d actually prefer to keep my hair, I need to keep myself out of first (and in this case also second) place. So as more and more donations come my way, I have to take it out on whoever’s closest behind me with donations of my own. When everyone follows this strategy, you get another positive feedback loop, and the karma katamari keeps on rolling.

As of today, these causes have raised over $400 from just a few donors in only a week. Not bad at all, and if we were to work these ideas properly into the application somewhere, I have no doubt that we could get a solid donation machine running. And you know what I love most? We can employ game dynamics like this without concern for how people might try and play the system. So you used six different credit cards, created fake profiles and bribed people with pizza. What do I care? You just made the world a better place.

So kudos to Steve, Jason, and Andy for their clever strategy and support of the ACS. Thank you for making us a part of it and showing everyone else how Causes can make a difference, even among a small group of friends.

P.S. I hope you post pictures of your shaving party

Activism is an inherently social endeavor: the decision to begin donating or volunteering is one that historically has flowed through networks of friends. The practice of grassroots organizing is predicated on the idea of getting to know one person and having that person reach out through their friends. In fact, for most people, their entire engagement with a political campaign or nonprofit is through their friends and family.

There are many examples of this. Think of the grandmother making her first political donation ever to the Obama campaign because her grandson’s excitement inspires her; or the group of recent college grads helping Habitat for Humanity build a house as a social outing and a way to keep hanging out; or the parents who start conserving energy and reading about global warming because their daughter brings home a CFL (compact fluorescent lamp) from school. All of these are examples of social relationships leading to increased engagement and activism or contributions.

These relationships are exactly what social networks like Facebook and MySpace are trying to capture. They’re not trying to replace real-life social networks, but rather provide a virtual overlay on top of them that can be used to extend, facilitate, and enrich those relationships. Their success may be arguable, but the goal is clear: they want to grease the wheels of social interaction.

This social networking information provides us a window into these age-old friend networks and allows us to bring activism to the online sphere in a way that has not been done before. Because the underlying social relationships are the core of individual engagement and activism, the better we can understand and facilitate them going forward, the more successful we will be in engaging people on a large scale.

With this in mind, the decision to build social networking applications becomes more intuitive. We’re trying to help people motivate and recruit their friends to causes they care about, so we need to be in the places where friends are interacting and expressing themselves. Online, those places are the social networking sites.

Working in the business world though, whether it be at a startup or for a larger organization, the tradeoffs are less obvious. There is no longer a simple dichotomy between working “lazier but smarter” or “harder but easier”. Instead, there seems to be a choice between “lazier but smarter” and “harder and smarter”. There’s a common thought process that follows this observation: “If you can get X units of work done in 6, why not get 1.5X units done in 9 hours?”

The issue with that line of reasoning is that productivity does not scale linearly. It may be that some people accomplish more work by stretching their hours, but it also depends on factors like the type of work, amount of sleep, and individual characteristics. This goes all the way back to the original Factory Acts in the United Kingdom at the beginning of the 1800s, when hours were reduced and conditions improved to better both the lives of the workers and the quality of their output. The pace for our modern working life was set by the struggle of many labor unions and workers’ strikes, including Henry Ford’s implementation the 8-hour workday in 1914, citing increased productivity and higher quality. More recently, David Heinemeier Hansson has written about this subject as it pertains specifically to startups and the software industry.

All said, the most important factor to consider when gauging productivity is personal performance. For example, I find that some of the times I am most productive are after taking some time away from working, either on vacation or even just a weekend. Despite the stereotype, Monday mornings are often one of my most productive times. On the other hand, while spending 12-14 hours in one day on a hackathon can be exhilarating, the next day I can barely focus at all. Others on our team and around the industry have other working schedules, going all the way into the wee hours of the morning, but no single schedule works for everyone.

In the end, productivity is a very personal thing and instead of there being one best approach (“lazier but smarter” or “harder and smarter”), you need to get to know your own rhythms and work to optimize those times. For some, it will be hacking on a project far into the night; for me, it’s letting that problem stew overnight, thinking about it on my train ride, getting myself a nice cup of tea, and attacking it first thing in the morning.

Example:

>>> a = [1, 2, 3]
>>> repr(a)
'[1, 2, 3]'

Ruby, however, has no such function built in. After running into a couple of problems where we wished we could use repr (more on those later), we decided to roll our own.

We chose the name rrepr (Ruby repr) and started defining it as an instance method on classes of interest. In some cases this is very simple.

class String
  def rrepr; inspect end
end

In others it’s a little more complex.

class Hash
  def rrepr
    '{' + map{|k,v| k.rrepr + '=>' + v.rrepr}.join(', ') + '}'
  end
end

In the end though, all of the basic classes end up being pretty easy to define. What about more complex classes?

The general problem is very hard; Python’s repr only really works for basic types like strings and arrays. However, it turns out that in Rails, an extremely large percentage of the objects we care about are ActiveRecord objects, and for those the find method makes it dirt simple:

class ActiveRecord::Base
  def rrepr; "#{self.class.rrepr}.find(#{id.rrepr})" end
end

Its surprising how often this comes in handy. Stay tuned for some examples.

With the name coming from C, this practice of sprinkling printf (or moral equivalent) statements throughout your code can be used to form a picture of what’s going on behind the scenes. While this approach doesn’t have the flexibility or panache of using a formal debugger, it’s intuitive, fast, and in most cases good enough.

When I first started coding for Rails, I translated my printf debugging into puts debugging with little difficulty. Unfortunately, this often left me digging through hundreds of lines of server logs, most of which were not useful for the problem I was trying to solve. Luckily, Jimmy had also encountered this problem and while pair programming one day I saw his simple and elegant solution. Throughout his code he had putd statements, which instead of writing to stdout and getting lost in the server logs, wrote debug statements to a separate file.

Now instead of digging through server logs when I’m debugging, I just have a console open running tail -f tmp/debug.log showing me exactly what I want to see. This simple insight often speeds up my debugging by a factor of five or ten. The implementation cost of this timesaver? 9 lines of code:

if ['development', 'test'].include?(ENV['RAILS_ENV'])
  DEVELOPMENT_DEBUG_LOG_FILE_NAME = "#{RAILS_ROOT}/tmp/debug.log"
  DEVELOPMENT_DEBUG_LOGGER = Logger.new(DEVELOPMENT_DEBUG_LOG_FILE_NAME)

  def putd(*args)
    DEVELOPMENT_DEBUG_LOGGER.info(*args)
  end
else
  def putd(*args); end
end

It still amazes me how much this tiny function has improved my productivity. It makes me wonder how many other small workflow modifications with disproportionate returns there are out there to discover. Any readers with special tools or tricks of their own? What do you use?