We've been dealing with the same problem [of a lack of Ruby programmers] for a couple of years in Boston. We've iterated through a bunch of potential solutions so I figured I'd share those with you here in case there's some lessons learned you can apply.

Dan Croak of Thoughtbot kindly shares his experiences with trying to get more Ruby programmers in Boston. It's a detailed and thoughtful post, and definitely worth a read.

I found this especially interesting:

1) Convert Java/Perl/.NET/Python developers from big companies into Rubyists

Our main effort here was a VC-sponsored workshop ... I would not classify it as successful. I think the two reasons why were:

• the class wasn't 100% subsidized. It was still priced at $600.
• it's difficult to find this cohort in any significant numbers. You can't contact HR at Fidelity and say, "hey, I'd like to poach 50 of your developers, can I send an email to your mailing list?"

My guess would be that if you're going to try to convert engineers at big companies, that effort will be more top-down than bottom-up. Those programmers are generally more risk-averse and unlikely to devote a lot of time and money to a skill that might possibly help them change jobs.

But, there are definitely larger companies that are trying to make the switch internally, and they're having a tough time of it. (Ten months ago I wrote about a large company that was living this pain, and from what I hear, they're still having a hard time hiring.) I really do wonder what would happen if companies like Thoughtbot or Pragmatic Studio were to sell dedicated group classes directly to companies. Of course, then you're dealing with an enterprise sales cycle. Which pretty much everyone avoids if they can.

You know, the one that sparked all that discussion on NYC.rb^*? If you feel like reading the whole thread you can start here^**.

Some thoughts:

1. People learn in different ways. Some people can teach themselves Rails by locking themselves in a room with nothing but a laptop and the internet. Other need structure and individual attention. Accordingly, it's not that useful to say things like "I learned skill X by spending only $Y, so therefore if you try to teach other people skill X by charging them a dollar more than $Y, you're a fraud and a thief."

2. Thousands of dollars isn't unheard-of for Rails classes or other sorts of software courses. If this is something you do for a living and are going to keep doing for years, then spending $2800 on the right sort of knowledge can pay you back very quickly.

3. Have you heard me say before that New York needs more Ruby and Rails programmers? Oh, only like a thousand fucking times? Yeah, that's about how massive and chronic the problem is. Local Rails classes can only help, overpriced or not.

4. I don't believe I've met Dimitri, but I know Daniel from around and he seems like a sharp and conscientious guy. The two of them probably teach a decent Rails course.

5. Of course, a great programmer can be a terrible teacher, and vice versa. There's always a high degree of risk that the educational experience you get may not be what you were expecting, which is why people pay premiums for classes offered by organizations or instructors with a known track record, whether that's Harvard or Edward Tufte or Pragmatic Studio. I think it's safe to say that this course lacks such an imprimatur, and if I were a cost-conscious aspiring Rails coder (which I'm not in, like, a dozen ways) I'd expect this course to be priced a bit down accordingly.

6. And when you compare it to the PragStud Rails classes, it does seem a bit expensive. The local class is $2,800 for 24 hours, or $116.67/hour. The PragStud classes—which are considered by many to be the gold standard in Rails classes—are $2295 for 23 hours, or $99.78/hour.

7. No, nobody actually says "PragStud". It's more stupid than clever, I suppose.

8. On the other hand! The PragStuds never ever come to New York City so you have to take that into account. There's a significant premium you can charge for a service that is the exact same as somewhere else, only you don't have to leave New York City. My beloved Gotham Ruby Conference being one example. Because New Yorkers don't like the rest of the country. It scares and confuses us.

9. But after all that maybe you still think they're charging too much. If that's the case, the way to prove that point would be to offer your own local Rails course that is just as good and noticeably cheaper. Hell, it might even be as easy as nagging the PragStuds to try doing a course in NYC. I think there are many people who'd love to see more offerings of local techie courses, if only for what we'd learn about the local education marketplace in the context of a possibly bubblicious 2012.

^* I'm no longer an NYC.rb organizer and I don't speak for NYC.rb on this or any other subject. As if I ever did.

^** I'd link to the entire thread on the NYC.rb email list, instead of just the first message, if it weren't for the fact that Meetup.com's mailing list functionality is a giant steaming pile of shit. That's social media for you: You get what you pay for.

Jesse Chan-Norris on writing a techie job description for Indaba Music:

... what I realized was that we needed a job description that spent much more time explaining who we are, as a team, and as a company, and by extension, the kind of person you should want to be if you want to join that team and work with us. I wanted to construct a posting that would attract the right kind of people and get them interested in us, that would sell our company as much as the candidates were selling themselves to us.

So this time around, instead of talking about years of ruby experience and a working knowledge of mongodb, we tell people that “Every member of our team is involved in the product development process. We challenge our developers, and we expect people to contribute at every step along the way” and we talk about how “We are a small team, and everyone is expected to exhibit a fair amount of autonomy.” And more than anything else, we lead with our core philosophy, which is that we believe that “the music industry is more alive than ever.” Forget all of those people who think that this industry is in the shitter – we’re just getting started.

I'd sharpen this even more. There's that piece of pitch-deck wisdom about how you never say "this is a $10 billion market so if we only capture 1% of it that'll be $100 million!" -- instead, you say "this is how we're segmenting this $10 billion market into a more precise $100 million market, and we're going to shoot for getting 100% of it". The idea being that nobody ever sold a new product by being a tiny bit better than the other guys to everybody in the whole world.

Well, I think it makes sense to think of hiring programmers that way too. You should define what sort of a place your company is to work at, and then really emphasize that differentiation as you write job descriptions, hang out at meetups, etc. No good programmer ever switched jobs because the next job sounded 1% better than their current situation. (Well, some programmers do that, because some of us are seriously brain-dead when it comes to making career choices, but that's another topic.)

To take an example: When Profitably started looking to hire engineers, we explicitly positioned ourselves as not another social media site. We talked about "complex analytical problems" in our job description, and sometimes I'd send out job emails actually making fun of the idea of working in social media.

That might seem unnecessarily negative, but keep in mind that the NYC startup scene is full of social media companies, and I was willing to bet that I wasn't the only techie in town who was a little fatigued by that emphasis. And I figured the most important thing was this: Above all else, break through the noise.

And, hey, you know what? If you really love working in social media, you probably wouldn't want to work at a company like Profitably anyway. But in the meantime, those little jabs at social media serve as a cue to the small minority of people who are tired of that scene, and maybe they'll read more about the company, and maybe even get in touch.

The nice thing about being a small company is that your hiring needs are small, and you can craft a job description that's that precise. Maybe it excludes everyone but ten programmers in town--if you're only hiring three programmers this year, you're good. Until the day when your massive prowess at tech hiring, combined with some real product-market fit, makes you so big that you've got Google-size hiring problems, at which point, congratulations.

Chris Dixon:

It is true that new technologies often lead, in the short term, to lower wages and fewer jobs. Craigslist, for example, has about 30 employees yet, by replacing the classified ad industry, eliminated many thousands of jobs (local newspaper reporters, classified ad salespeople, etc). The same could be said for almost every popular website.

On the flip side, new technologies have driven down prices (Walmart and Amazon), led to massive increases in information productivity (Google and Wikipedia), and created new income sources (eBay and Craigslist). Greater productivity and lower prices at least partly compensate for part-time jobs and lower wages.

A few thoughts on this:

Continue reading “What we mean when we say disruption” »

So, I've left Profitably, as of last week. Early-stage startups involve as many subjective decisions as objective decisions, and if the gut instincts among the team are strongly out of sync, sometimes you won't be able to find a workable consensus no matter how long you try to talk it out. That's the situation we were finding ourselves in, and ultimately we decided that the best option was for me to move on.

It's been an amicable process, and everybody involved, from the other team members to our investors, has been extremely fair, understanding, and supportive. Not that they even have to be that supportive, really: I'm excited about the future, both for Profitably and for myself. The Profitably team is off to a solid start on offering strategic financial insights to small businesses, and I wish them all continued success in the future.

As for me? Now's as good a time as any to take a breather, so I'll be doing some of that. I may even find time to sit on a beach somewhere, so if you see me at some meetup with a wicked sunburn, that'll be why. But it won't be long before some other role piques my interest. I continue to love the challenges of managing top-notch programmers, of working closely on an evolving product vision, and of playing a bridging role between the techies and everyone else.

And, you know, this field never stops being interesting. There's a lot of talk about whether or not the tech scene is in a bubble: I'm happy to leave that question to the VCs. That cycle plays out over months or years, but in the truly macro sense, every time I see the problems that people are trying to solve, and the problems that people aren't even close to yet, I think to myself that we're just getting started. Line by line, we build the future. We're lucky to be paid for the privilege.

A bit of housekeeping: After the requisite amount of entirely excessive hemming and hawing, I've decided to separate my writing about tech & code from my writing about other things, such as film, TV, life in NYC, or videos of cats. The better I get at hacking, startup life, etc, the less accessible that becomes to non-techie readers, so I'm making a move.

So, the new site is fhwang.me, and I've taken the liberty of moving the last year's worth of non-code writing there. If you want to keep hearing me talk about such things, you should add that site to your RSS reader / Tumblr dashboard / bookmarks to check when you're procrastinating at work. The hardcore nerd shit will stay here, as always.

This is one of those Google-baiting posts that coders write for other coders in hopes of saving them hours of frustration. It's unlikely to be of interest to anybody else.

As we moved Profitably to Rails 3, we were having a strange problem upgrading PaperTrail. PaperTrail needs to be upgraded to 2.x for Rails 3, but as soon as we upgraded it, we couldn't even load the environment. The traceback we'd get looked like this:

$ ./script/rails runner "puts 'hello world'"
/Users/francis/.gem/gems/activerecord-3.0.7/lib/active_record/named_scope.rb:132:in `valid_scope_name?': private method `warn' called for nil:NilClass (NoMethodError)
  from /Users/francis/.gem/gems/activerecord-3.0.7/lib/active_record/named_scope.rb:102:in `scope'
  from /Users/francis/.gem/gems/paper_trail-2.5.0/lib/paper_trail/version.rb:18
  from /Users/francis/.gem/gems/activesupport-3.0.7/lib/active_support/dependencies.rb:239:in `require'
  from /Users/francis/.gem/gems/activesupport-3.0.7/lib/active_support/dependencies.rb:239:in `require'
  from /Users/francis/.gem/gems/activesupport-3.0.7/lib/active_support/dependencies.rb:225:in `load_dependency'
  from /Users/francis/.gem/gems/activesupport-3.0.7/lib/active_support/dependencies.rb:596:in `new_constants_in'
  from /Users/francis/.gem/gems/activesupport-3.0.7/lib/active_support/dependencies.rb:225:in `load_dependency'
  from /Users/francis/.gem/gems/activesupport-3.0.7/lib/active_support/dependencies.rb:239:in `require'
  from /Users/francis/.gem/gems/paper_trail-2.5.0/lib/paper_trail.rb:7
  from /Users/francis/.gem/gems/bundler-1.0.15/lib/bundler/runtime.rb:68:in `require'
  ...

If you're seeing this error, you may also have Sinatra in your Rails app for some strange reason (our strange reason is explained below). If that's the case, then the fix is to tweak your Gemfile with a require option:

gem 'sinatra', '1.0', :require => 'sinatra/base'

If the fix is simple, the actual cause was pretty gnarly. PaperTrail comes packaged with an ActiveRecord model called Version, with a scope called after. In ActiveRecord, the scope method will log a line if it's overwriting an existing method, though in this case ActiveRecord.logger isn't even defined yet, so you get a traceback from trying to call nil#after.

Why is Version.after defined? Because we're using Sinatra in our full-stack tests. Profitably supports authentication from a few external sources, and we got to the point where we wanted to test an external authentication source in combination with our Javascript and our Rails code. The best way we found to do that was to create a secondary server in Sinatra that our capybara test would spin up, for the purpose of simulating a POST from somebody else's website.

Sinatra, by default, writes a bunch of global methods like get, put, post, etc, which makes perfect sense if you're writing a quick Sinatra app, so you can do stuff like:

get '/hi' do
  "Hello World!"
end

Only problem being, in our case, that it also defines after, which is then defined on every Ruby object, including PaperTrail's Version class. (Yes, defining a method globally will define it on every single Ruby object, which is why you don't want to do it that often.)

Anyway, you can configure Sinatra not to create those methods globally, which is what the above Gemfile change will get you.

So, at Profitably we've been transitioning off our own custom CI build using Jenkins, to using a new service called Tddium. Tddium is a hosted, parallelized CI service that aims to run your test suite much faster than you likely could with your own CI setup. It took us a few weeks to get everything up and running, but now that we're using it as our main CI environment, allow me to offer my considered opinion as an engineer:

Holy crap this thing is fucking awesome.

Here, look:

Our 34-minute test suite is now down to 13 minutes. This was the most recent run of master, and at times I've seen it get down to around eight minutes. The two guys behind Tddium have a ton of work to do, but I have no doubt that as they build in more intelligence about managing their nodes they'll be able to give us five-minute test runs on a regular basis.

It's sort of amazing what this does to your productivity. We're just now making the switch to Rails 3, which of course broke a ton of tests at first, and it's really gratifying to make one low-level change to a model, commit it, and find out shortly afterwards that the fix resolved errors in five other test files.

It's not an exaggeration to say I've been waiting for this service for literally years: At RubyConf 2008, I talked about this in my Testing Heresies talk. Of course, getting setup on Tddium reminded of why this is hard in the first place. Any non-trivial app is going to have one binary gem or external dependency that's a hassle to get set up in an environment where the instances you used last time won't be the same as the ones you're using next time, and where you don't have SSH access regardless. For their part, the Tddium guys are overcoming that with tons of automation, documentation, and for the time being really great personal service. When we started getting our code base setup to work on Tddium I was pleasantly surprised to have them emailing me patches to use.

They're in limited release right now, so I don't even know if they can take on any more customers right now. But you should sign up anyway.

As seen on the General Assembly chalkboard.

And as far as that education goes, it really looks like you got your money’s worth, kid.

This is actually a few weeks old, but I’m bad at announcing things: admin_assistant 2 is now out. The big changes in it are support for Rails 3, and jQuery.

I’ve also updated the doc site, including retaining the old API for v1: Check it out here..

Happy 4th!