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).