general « Codeulate.

RSS

Archive for the ‘general’ Category

How to Recruit Me

09 Feb

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.

No Comments

Posted in general

How to land your first patch in Rails

07 Feb

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!

1 Comment

Posted in general, rails

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

19 Nov

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.