Three Simple Rules for Career Satisfaction

Inspired by some serious honestly and introspection I've recently witnessed, I thought I'd take stock of my career in its present state. Here are three simple rules for my own career satisfaction with a score (out of 10) to indicate how I'm doing currently on each of them.

1. I want to rarely if ever be bored. (3/10)
2. I want to make a comfortable living. (9/10)
3. I want to continue to live near my hometown. (10/10)

I'm convinced that I can score at least 9/10 on #1 and #2, but I'm too chickenshit to compromise #3. Am I screwed?

Great Hackers and Boring Work

If it is possible to make yourself into a great hacker, the way to do it may be to make the following deal with yourself: you never have to work on boring projects (unless your family will starve otherwise), and in return, you'll never allow yourself to do a half-assed job. All the great hackers I know seem to have made that deal...

- Paul Graham

Firefox Tip: Get Spell Checking on All Form Fields

This tip is so useful that I just had to share it with my fellow Firefox addicts.

We all love Firefox's built-in spell checking feature, but we're all annoyed that it only works on multi-line text boxes, right?

If you want spell checking to work everywhere like I do, then today's your lucky day.

(via Josh Giese)

1. type this in the browser address bar “about:config”
2. look for “layout.spellcheckDefault”
3. change the value to “2″
4. restart firefox

Corollaries to Blodgett's First Law

When I originally wrote down Blodgett's First Law of Software Development, I also wrote down, stream-of-consciousness style, a bunch of related thoughts as they came to me.  Here they are in all their raw, rambling, pretentious glory:

• Any step in a process that could be automated must be automated.
• Any code that could be generated must be generated.
• A good developer has a built-in tedium detector that's extremely sensitive.
• Great developers feel a moral obligation to eliminate tedium.
• Tedium indicates a flaw in your process.
• A good developer will refuse to do boring work.
• A good developer is lazy.
• It's foolish to force your best developers to do boring work.
• Prefer unit tests over comments.
• Dynamic languages will eventually win.
• Ruby on Rails is popular because it ruthlessly eliminates tedium from web development.
• "Don't Repeat Yourself" might be the most important and fundamental principle in software development.

Paul Graham on Office Space for Hackers

While re-reading Paul Graham's classic essay, Great Hackers, in preparation for a previous blog post, I took note of a few quotations that I wanted to include in a separate blog post.  I recently committed publicly to writing them up, so here they are.

Big companies think the function of office space is to express rank. But hackers use their offices for more than that: they use their office as a place to think in. And if you're a technology company, their thoughts are your product. So making hackers work in a noisy, distracting environment is like having a paint factory where the air is full of soot.

...

Maybe the people in charge of facilities, not having any concentration to shatter, have no idea that working in a cubicle feels to a hacker like having one's brain in a blender.

If Something Seems Boring, Skip It

...I tried two tactics to increase the amount of money I could charge for my programming services. One of them failed spectacularly, and one of them succeeded wonderfully. The failure was learning the skills that had the most job posts; the success was learning the skills that most engaged my own curiosity. I learned Java and got nothing out of it; I studied Bayesian filtering for fun and did consulting work in Bayesian filtering through my activity on a Ruby mailing list.

...

The moral here is that if something seems boring, skip it. Trust your intuition.

- Giles Bowkett

^\d+ ?[A-Za-z]+s$ is Officially Played Out

Can we all please agree that the ^\d+ ?[A-Za-z]+s$ pattern for naming your web thing is officially played out, and just move on?

( I can't wait for the pedants to pick apart that regex. :-) )

Matt Blodgett's First Law of Software Development

A development process that involves any amount of tedium will eventually be done poorly or not at all.

Code Samples From "Programming Ruby" That Made Me Stop, Look Up At the Ceiling, and Sigh Longingly (Part 2)

CHAPTER 4. CONTAINERS, BLOCKS, AND ITERATORS

PAGE 49

def with_title(title)

  @songs.find {|song| title == song.name }

end

Code Samples From "Programming Ruby" That Made Me Stop, Look Up At the Ceiling, and Sigh Longingly (Part 1)

CHAPTER 4. CONTAINERS, BLOCKS, AND ITERATORS

PAGE 44

a = [ 1, 3, 5, 7, 9]

a[-1]    ->  9

a[-2]    ->  7

a[-99]   ->  nil

IronRuby Caveats

Here are a couple caveats to keep in mind if you're following along with the "How do I get started?" screencast from the official IronRuby site.

 

1. Use Debug, not ExternalDebug

Near the 1:50 mark, the presenter switches the build configuration to "ExternalDebug" before (re)building the solution.  This didn't work for me, as all six projects were skipped every time.  I tried a few different build configurations and eventually discovered that the "Debug" configuration worked just fine.

 

2. No local variables in the console

At around the 2:40 mark, the presenter executes a few simple lines of code in the IronRuby console (rbx) just to show that the build is functional.  The only important thing to note in those lines of code is that they're using local variables.  It turns out this capability was a temporary hack that the IronRuby team removed shortly before RubyConf 2007.  If you're playing around in the console, just use instance variables (like @x) or global variables (like $x).