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

Blocked is a crappy place to be. It means you’re trying to get something done but can’t. Current velocity: zero.

I’ve noticed something about programmers I admire: they’re extremely good at not getting blocked.

Some time ago I spent three days trying to get a feature working. I was blocked, and bad. Finally, I took a break and went to work on something else. The next day at standup, a colleague mentioned implementing that same feature, and then then going on to do two more tasks with the other half of his day. Incredulous, I asked him how he solved the problem I’d run into. He happily admitted he hadn’t. He’d run into that problem, spent a half hour on it, and then changed direction.

Me: got blocked, pounded on the barrier. Great programmer: got blocked, tried something else that worked and moved on.

Like most programmers, I have an strong desire to solve problems. Put some broken code in front of me and I’ll wrestle with it ’til it works. There’s lots to do but I’ve got to start by fixing this problem.

The best programmers I know have a different mantra: don’t get blocked. They’re focused on moving things forward, not getting bogged down making everything perfect. They’ll duck and weave, leaping over obstacles or tunneling beneath them. They like problems too, but they like something else even more: shipping.

Don’t get blocked.

The interviews themselves will make great fodder for future posts, but I realized a startling fact the other day: I never once sent anyone at thoughtbot a resume.

Moreover, I was never asked about schools, degrees, nor much about my past experience. My “resume” took the form of links to this blog, some open source contributions, and access to a couple private github repos of Rails apps I’d built.

This experience confirms an idea that I’m glad to see gaining ground lately: resumes are deprecated. Code is king. Oh, and connections help a lot too.

A year ago I wrote that it was possible to land a Rails job with no experience, provided you had a portfolio application, some code on Github, and attended Ruby meetups to network. Some people were skeptical, but it was exactly those things that got me my first Rails job. Now, years later, the same set of things got me in the door at thoughtbot: code, more code, and the recommendation of thoughtbotter Dan Croak, who I got to know during the ’09 Rails Rumble (yet more coding!)

I’m starting to think this really is the secret sauce for professional programming success, regardless of experience level. Get some code out there for people to see, and get yourself out there to meet awesome programmers you might want to work with someday. Leave the bullshitty bullet points to the MBAs.

into this?

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.

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!

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)

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.

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:

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:

Commands mentioned:
nG – jump to line n
L – jump to the bottom of the screen (“low”)
H – jump to the top of the screen (“high”)
M – jump to the middle of the screen (“middle”)
C-o – jump back
C-i – jump forward
zt – move this line to the top of the screen (“top”)
zb – move this line to the bottom of the screen (“bottom”)
zz – move this line to the middle of the screen (“ziddle?”)

(You’ll want to open it on Youtube and watch in high-resolution.)

Commands used:
7G – jump to line 7
“td – delete into the t register
“tp – put from the t register
qq – start recording a macro (just a series of keystrokes) into register q
@q – execute the keystrokes stored in register q
vmap – set up a mapping active only when in visual mode