fhwang.net

nyc

The Front-End Future

My Goruco 2012 talk, "The Front-End Future", is now up. In it, I talk about thick-client development from a fairly macro point-of-view: Significant long-term benefits and drawbacks, the gains in fully embracing REST, etc.

I also talk a fair amount about the cultural issues facing Ruby and Rails programmers who may be spending more and more of their time in Javascript-land going forward. Programmers are people too: They have their own anxieties, desires, and values. Any look at this shift in web engineering has to treat programmers as people, not just as resources.

Francis Hwang - The Front-End Future from Gotham Ruby Conference on Vimeo.

As always, comments are welcome.

Goruco 2012 is over

This isn't just the event New York Rubyists want. It's the event they deserve.

Thanks so much to all the co-organizers for pulling this off. Everybody else: See you next year, if not sooner.

Goruco: Six years on

I wrote a little something about Goruco on the Goruco site:

Let me make a confession: Before we hosted the first GORUCO, I kind of didn’t want to be bothered. NYC.rb had been a successful Meetup for years, and people would occasionally say “you know, we could have a great regional conference here.” Which made sense in theory, but just thinking about the work involved gave me a headache. I usually smiled politely and tried to change the subject.

It's worth a read if you're not already convinced this year will be the best Goruco evar. And if you have yet to buy your ticket.

Speaking at Goruco

So, I'm speaking at Goruco this year. On The Front-End Future:

With the rise of Javascript MVC frameworks like Ember and Backbone, web programmers find themselves at a fork in the road. If they keep doing server-side web programming, they'll benefit from tried-and-true tools and techniques. If they jump into Javascript MVC, they may be able to offer a more responsive web experience, but at significant added development cost. Which should they choose?

This talk will address the strategic costs and benefits of using Javascript MVC today. I will touch on subjects such as development speed, usability, conceptual similarities with desktop and mobile applications, the decoupling of rendering and routing from server logic, and the state of the emerging Javascript MVC community. I will also discuss the impact of this seismic change on Ruby, Rails, and your career as a software engineer.

Nobody should confuse me with a Javascript expert, and that's not why I'm giving this talk. There are many talks you can see that focus on the specifics of implementation that are being hashed out today. With my talk, I will be drawing out the macro trends in our field that affect the products we build, and the careers we craft.

In particular, I feel like the move to thick-client web apps is giving the Ruby and Rails community a bit of existential paralysis--we should be talking about this far more, and meeting this change head-on. The future is uncertain, but it is also bright.

Goruco is on Saturday, June 23. This is our sixth year, and without giving away the rest of the speakers, I think this might quite possibly be our best program yet. If you want to join us, tickets are still available.

Moar Rubyists: Boston's experiences

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.

That $2800 Rails class

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.

So, just so I've got this straight, you're saying you're NOT dumb.

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.

Hiring Rubyists at a large company

A few months ago, at an NYC.rb happy hour, I had an interesting conversation with a technical recruiter. He was trying to hire Ruby and Rails programmers for a large company in the city, and was asking my advice because their goal was in the double digits and the company had been trying for some time with little success. This is sort of the inevitable result of the Railsification of the web programming business: As Ruby and Rails move from super-cutting-edge to comfortably middling, bigger and bigger companies decide to make the switch. And, for their efforts, they’re rewarded with the same recruiting pain that small startups have been living with for years.

It’s tough for a large company to hire in a technology like Ruby. Sure, you can proclaim loudly that you pay above market rates—but to work for a larger company, your typical senior Rubyist is going to need not just good money, but ludicrous, eye-watering money. Because no matter what happens, you’re not giving that programmer a chance to build the next Twitter or Facebook. And that opportunity is key to what a cutting-edge programmer gets psyched about.

It isn’t really about the equity, though that’s a nice bonus: It’s about the chance to learn. We know that the best way to be part of technological progress is to be thrown into a situation where you have to solve a million-dollar problem with way less than a million dollars, which forces you to try with some unproven set of tools and techniques. We read blog posts and listen to talks by the people who’ve been through that sort of trial by fire, and we wonder how well we’d do at it. And then we go look for somebody to hire us to try.

Larger companies rarely do this. They’re more likely to avoid the hard problems, or solve them in ways that risk less but cost more. That’s their prerogative, of course, but if that describes your company, and you’re trying to hire Ruby programmers, you’re going to run into this issue a lot.

Unless you look in a different place. That night at the bar, another Rubyist pointed out that there are plenty of .NET and Java web programmers who would love to get into the Rails game, but don’t see a good way in. For one thing, there’s the issue of experience: Most Rails teams are small, and accordingly there aren’t many entry-level Rails jobs in the world. And another issue is of risk: There are plenty of smart, curious programmers in the world who aren’t at the point in their lives where they can take on the risk of being the fifth employee at a seed-funded startup. (But if instead you get excited by that sort of opportunity, Profitably is hiring.)

So we suggested to the recruiter that they try to find those candidates—who largely don’t come to Meetups, and thus are harder to reach—and tie Ruby and Rails training into the final job offer. Of course, it’s a risky move for a company to hire somebody who doesn’t know Ruby yet, and I don’t think anything came of our suggestion. But it seems like there’s a match here that can be made. On one side, you have a large company that can’t easily hire Ruby programmers but has cash and can offer stable employment. On the other side, you have programmers who want to transfer their skills to Ruby, but need a stable employer and maybe some help with cash. There should be a way to connect the two sides.

I’m not sure who exactly this is an opportunity for. Maybe it’s an opportunity for a recruiting firm, which could find people with raw talent and experience in other technologies, and get them a sort of transitional offer which involves training and a job offer at the end. Or maybe it’s an opportunity for a consulting shop like Pivotal Labs, which already offers recruiting + training services as part of what it can do for clients, but would probably have to tweak the offering a bit for a different recruitment base.

But it’s got to be an opportunity for somebody. The severe pinch of technical talent in NYC isn’t getting better—if anything, it feels like it’s getting worse. It’s time to get creative with our solutions.

In which your author manages to make others who are probably about as old as him totally freaked about being old

Also, who’s this Tupac guy you keep talking about? Is he, like, Lil Jon’s cousin or something?

The most painful line of the day: “To most everyone, AOL was the company that mailed you all those CDs so you could get on a 56K modem when you were in grade school.” Most everyone! Grade school! OMG I’m going back to bed!

Millenials Rule The Land, at The Awl

AOL HQ

I’m quoted using “like” a lot in this New York Observer article about AOL:

The machine learning guys, some of New York’s most ambitious technologists, have been coming to AOL since last spring, when the company agreed to donate space in its massive office complex for the group’s monthly meet-ups. That act of goodwill was part of an aggressive ongoing effort to improve AOL’s reputation in the New York tech community, a campaign being mounted by Mike Brown, the co-founder of the company’s year-old venture arm, AOL Ventures. Mr. Brown’s hope is to change the way AOL is seen by entrepreneurs and engineers—to erase its reputation as a moribund dial-up dinosaur and thereby neutralize the biggest obstacle he and his partners, Jon Brod and Brad Garlinghouse, face as they look for start-ups in which to invest the changing company’s money.

I co-host two different groups at the AOL space, and all I can say is that they’re a godsend for the local tech scene. Whatever happens to AOL in the long-term, there are a lot of people there who clearly understand the importance of being a tech-focused organization.