Codeulate. » general

Just closed more funding? My condolences.

Ben Orenstein — Mon, 03 Oct 2011 04:12:10 +0000

When a popular company announces a new round of funding, the Hacker News comment threads are usually overwhelmingly congratulatory. This attitude is horribly misguided. In my eyes, announcing post-seed funding is a BAD thing, and should be close to a PR disaster. The HN threads should be full of condolences. Here’s why.

The company hasn’t figured out how to pay its bills

At the end of the day, a company exists to make money. Every round of funding (past, maybe, a seed round) is an admission that you still haven’t figured out a business model that will keep the damn lights on. Every startup should want each round of funding to be its last.

The founders have ceded control

Companies in very strong positions are sometimes able to take funding without losing much control of the company, but this is rare. In general, founders are turning over substantial control to professional gamblers with horrible succes rates. A VC will never love your company like you do; he’s there only to get paid. This will forever taint your relationship.

Part of the company was sold prematurely

People seem to forget that “getting funded” really means “selling part of the store”. If you think your company is going to be worth more in the future, why are you selling part of it now?

Here’s an announcement I’d love to congratulate: “we’ve recently reached profitability and know we can keep the lights on. We think we can make even more money in the future, so we’re going to hang on to as much precious equity as we can. Offers for outside funding are flattering but unnecessary.”

Let’s read some Rails code: with_options

Ben Orenstein — Sun, 05 Jun 2011 07:35:41 +0000

Did you know you can refactor this:

# Duplicated :dependent => :destroy option.
class Account < ActiveRecord::Base
has_many :customers, :dependent => :destroy
has_many :products, :dependent => :destroy
has_many :invoices, :dependent => :destroy
has_many :expenses, :dependent => :destroy
end

into this?

# Nice and DRY!
class Account < ActiveRecord::Base
with_options :dependent => :destroy do |assoc|
assoc.has_many :customers
assoc.has_many :products
assoc.has_many :invoices
assoc.has_many :expenses
end
end

The with_options method is a really cool chunk of code that lets you DRY up duplication that sometimes appear when passing the same options to a series of methods.

But the point of this post is how it works behind the scenes, so check out this 11-minute code walkthrough:

By the way, this is an excerpt of a longer screencast I’m working on about ActiveSupport internals. If you’d like to be notified when the full screencast is released, drop your email in this form. (One email, ever.)

You can also check out the other Rails-related screencasts I’ve already done.

Video: write code faster — expert-level vim

Ben Orenstein — Mon, 30 May 2011 23:40:12 +0000

In May of 2010 I gave a one-hour talk to the Boston Ruby Group titled ‘Write Code Faster: Expert-level Vim’.

I’d volunteered to give it as a test-run before delivering the same talk at RailsConf a month later.

Little did I know, someone recorded the Boston.rb talk and it recently surfaced on the presentations page.

If the title sounds interesting, go watch the talk!

Let’s read some Rails code: OrderedOptions

Ben Orenstein — Sat, 28 May 2011 23:55:12 +0000

Curious about Rails’ internals? In the screencast below, I take you on a 5-minute tour of the OrderedOptions and InheritedOptions classes in ActiveSupport. Check it out for a code-level tour of an interesting bit of Rails.

By the way, this is an excerpt of a longer screencast I’m creating of guided tour through the best parts of the Rails source. If you’d like to be notified when the full screencast is released, drop your email in this form. (One email, ever.)

UPDATE: Youtube’s compression isn’t looking so hot, so if you prefer, you can download the high quality version here. (43MB)

2011 Boston Rails Developer Salary Survey

Ben Orenstein — Fri, 29 Apr 2011 19:28:32 +0000

Summary: an anonymous survey with 50 responses indicates that the average salary for full-time, Boston-based Rails developers is $99,646

Several weeks ago I posted to the Boston Ruby Group mailing list asking people how much money they made. I asked people for their annual salary (including bonuses), how they’d rate their Rails skills from 1-10, whether they managed other developers, and whether they were freelancers.

See the original survey.

Results:
Average salary (non-freelancers): $99,646

Average salary (freelancers): $114,000

Average salary (no management of other devs): $88,340

Average salary (with management of other devs): $113,040

Average self-rating of Rails ability (1-10): 7

Raw data, and the brutally-complicated code I wrote for averaging a handful of numbers lives on github.

Thoughts on the results:
Based on conversations with those familiar with the local market and my own experience, these numbers seem a bit high. I have a hunch there is selection bias at work: perhaps developers that are proud of their salaries are more likely to respond. Additionally, I’d guess there’s a tendency for people to exaggerate slightly on these sorts of surveys. Naturally, you should treat these numbers as you would any drawn from an anonymous survey sent to a public mailing list.

Bundler’s got bash-fu

Ben Orenstein — Wed, 16 Mar 2011 04:13:34 +0000

Well, technically got it’s got POSIX-compliant-fu. But that’s even better; so no worries.

Check out this line from bundler’s gemspec. The goal of this line is to set s.test_files to an array of file located in testing-related directories:

s.test_files = `git ls-files -- {test,spec,features}/*`.split("\n")

There are a couple interesting things going on in this line:

git ls-files: by default, this command outputs all the files in the index, but we’re going to constrain it with a path supplied by…
{test,spec,features}: this is a “curly brace expansion”. In bash (and other POSIX shells), this will expand to “test spec features”, however notice that we’ve got a trailing…
/*: when you’ve got leading or trailing characters around expansions, they are included in the expansion. So the full command of {test,spec,features}/* expands to “test/* spec/* features/*”
Finally, git ls-files outputs the names of all the files in those directories, and we split them on newlines to get our array.

Finally, if you like the idea of curly brace expansions, but prefer to stay in Ruby-land, you can have the best of both worlds:

Dir.glob("{test,spec,features}/*") # This also works

How to Recruit Me

Ben Orenstein — Thu, 10 Feb 2011 00:35:58 +0000

I get emails from two to four recruiters per month. Sadly, most of their emails look like the following, received today:

Ben,

I am the lead technical recruiter at (Company Name). We are a social media technology company sitting atop the social media marketing revolution and are looking to grow our talented team. I came across your profile while doing some outreach. I was impressed by what I saw on your profile and your community contributions and would be very interested in speaking with you about our need for strong Ruby Developers and your career goals. There is no pressure if you are not in the market. I am more than happy to answer any questions that you might have as well.

I encourage you to look at our website (link) to check out our job postings, read about our story, and check out our awards!

Let me know a good time to connect. I look forward to speaking with you.

Thanks,

Kelly (Last Name)

This email sucks for several reasons, but by far its worst offense is that it’s not about ME. There’s nothing in here that indicates Kelly wants to hire ME, she just wants to hire SOMEONE: another notch in her bedpost. This does not give me the warm fuzzy feeling.

I have never responded to an email of this nature.

As a means of dramatic contrast, let’s look at an email from a different recruiter that’s so damn good it makes me giddy:

Hi Ben,

I hope you’re well. I’m rather certain that you know about Airbnb as you had replied to a thread on Hacker News that I had posted on our need for Rails engineers a couple of months back – (link). We’ve since added three engineers to the team, remaining selective and adding a couple of front-end talents to our crew.

I was wondering what your current situation is as I had noticed on your Codeulate About page and workingwithrails.com profile stated that you’re available. I’m interested in having a chat with you about what we’re doing here and whether you would be interested in joining us full time.

Another factor that you might be interested in knowing is that despite being based in Boston, if we thought we would be a great fit for each other, Airbnb would be more than happy in assist in relocating you to San Francisco.

Let me know what your thoughts are!
Barry

I didn’t anonymize this one because Barry and Airbnb deserve massive kudos–this is the best damn recruitment email I’ve ever received.

Barry has read my comments on Hacker News, found my profile on workingwithrails.com, read my blog, and knows where I live. I am physically incapable of disliking someone who strokes my ego so thoroughly. How can you be disinterested in someone so interested in you? Barry’s telling me that he’s done his research, liked what he saw, and thinks I’d be a good addition to his team. That is a damn good start with one email–if I were interested in moving out to SF, I’d be all over that.

I’d love to see more recruiters copying Barry’s approach. You’ll get better results and I’ll get less spam. I love when everybody wins.

How to land your first patch in Rails

Ben Orenstein — Tue, 08 Feb 2011 06:13:39 +0000

If you’re looking for a way to contribute back to Rails, the quickest way to get your first patch in is by improving its documentation.

Some people don’t find patching documentation as sexy as slinging code, but I’ve come to love the humble doc patch. Here’s why they’re so great:

It’s easy to get started. Your first patch can be as simple as fixing a typo in a Rails Guide. Later, when you’re feeling more at ease with the process, you can improve the documentation for a class or method right in the code. Find an undocumented class, dig into its guts, and write a good summary. Ever read the examples for a method and think they could be improved? Don’t grimace and move on; fix it!

Your patch will be merged in quickly. All patches to Rails’ documentation go into the docrails repository. This repo has an OPEN COMMIT POLICY: you simply message lifo on github and he’ll give you commit rights. You can make your patches at will, and the repo is regularly merged with the official Rails repository (here’s the most recent example of that happening). There’s no lengthy signoff process, so your commits will never languish while waiting for “+1s” or attention from a core member.

Most people don’t want to do it. It’s actually pretty tough to find bugs in Rails to fix. There are so many Rubyists crawling all over it that there’s just not that much low-hanging fruit to patch. However, most developers don’t really like writing prose, so there’s a lot of easily-improved or outright missing documentation out there.

Your commits count toward the Rails contributors leader board. If you’re into that sort of ladder-climbing, you can break into a top 200 spot with just 8 commits. With just a bit of effort I reached 267th, which gets me laid all the time.

It feels damn good to give back to projects you use every day, and seeing your name in the commit logs is a real trip at first. If you’ve been looking to start making some open-source contributions, you could do a lot worse than improving documentation used by thousands.

If I’ve inspired you, you should start here: the Contributing to Rails Guide has a section specifically for working on documentation. Good luck!

How to use Rails routes in Steak scenarios (and RSpec specs)

Ben Orenstein — Fri, 19 Nov 2010 23:22:09 +0000

Want to use Rails’ routes in your Steak scenarios (or any type of RSpec specs)? No problem. Here’s what you want:

# In spec_helper.rb

RSpec.configure do |config|
# Make the rails routes available in all specs
config.include Rails.application.routes.url_helpers

# or

# Make them available only in Steak scenarios
config.include Rails.application.routes.url_helpers, :type => :acceptance
end

Fair warning: I’ve seen some folks say that you shouldn’t do this, and instead should define your routes in paths.rb. This way testing your routes is part of your acceptance suite.

I see where they’re coming from, but this just doesn’t seem worth it to me. I don’t find routes to be a very bug-prone area in my apps, so keeping duplicate my routes in two files is too high a price to pay.

I’ve been using Rails’ built-in route helpers in my specs for several months now, and can’t think of a single routing issue that’s come up. YMMV.

How to teach programmers

Ben Orenstein — Sat, 16 Oct 2010 06:24:55 +0000

I just spent the last eight hours in a jQuery training class. I noticed that in some sections I was pretty bored, but in others I was completely engaged.

After a while, I realized I could easily predict whether a section would be interesting or boring with the following heuristic: slides suck, code rocks.

I think we need to get away from the idea that a bunch of code snippets on slides is a good way to teach programmers. Think about this: if you needed to pick up a new language over the next week, how would you do it? When programmers want to learn a new language, there’s really only one way we can really make progress: we play with it. We load up just a little bit of code, and we poke at it. A question pops into our heads and we find the answer with code. When we’ve got the basics, we start trying to build bigger things.

If this is the way programmers learn (and I claim that it is), why are we teaching them with snippets on a slide?

My favorite speaker of the day was Ben Alman. Ben’s talks were fantastic for two reasons: first, he was ridiculously knowledgeable about his subject matter. But almost as importantly, he spent a ton of time writing code for us. Everything he talked about was demonstrated on the fly with code running in the browser. Someone asked a question? Ben wrote some code to show him the answer.

After Ben spent five minutes refactoring two functions, I realized I’d learned more in those five minutes than I had in the hour leading up to it. An hour spent reading examples off slides.

I’m starting to think that this should be the go-to move when teaching programmers. Write code in front of us, live. You’re allow to screw up; in fact, I hope you do! I’ll learn something watching you fix it. This is how you’d teach a friend who’d come by your desk for help. Let’s just pretend we’re already buddies, and show me some code.