So I switched to Vim, and now I love it.

For years, I was actually using jEdit, of all things, even in the face of continued mockery by other programmers. My reasoning was well-practiced: TextMate didn't support split-pane, all the multi-key control sequences in Emacs had helped give me RSI, and Vim was just too hard to learn. jEdit isn't very good at anything, but it's okay at lots of things, and for years it was fine.

But eventually, I took on a consulting gig where I was forced to learn Vim. And, as so many have promised, once I got over the immensely difficult beginning of the learning curve, I was hooked.

Beneath the text, a structure

I'm now one of those smug Vim partisans, and one of the cryptic things we like to say is that Insert mode is the weakest mode in Vim. So what the hell does that mean? It means that if you accept the (lunatic, counterintuitive) idea that you can't just insert the letter * by typing *, what you get is that every character on the keyboard becomes a way to manipulate text without having to prefix it with Control, Cmd, Option, etc. (In fact, the letter * searches for the next instance of the word that is currently under the cursor.)

When you edit source code, or any form of highly structured text, this matters, because over the course of your programming career you're far more likely to spend time navigating and editing existing text than inserting brand new text. So the promise of Vim is that if you optimize navigating and editing over inserting, your work will go faster. After months of practice, it does feel like I edit text far more quickly--that hitting Cmd/Ctrl/etc less often compensates for the up-front investment of learning these highly optimized keystroke sequences.

But it's definitely a strange mindset. In most text editors, you think of the document as a casual smear of characters on a screen, to be manipulated in a number of ways that are all okay but never extremely focused. But Vim assumes you're editing highly structured text for computers, and in some ways it pays more attention to the structure than the characters. So after a while it feels like you're operating an ancient, intricate machine that manipulates that structure, and that the text you see on the screen is just a side-effect of those manipulations.

Investments

Is it worth the time? To answer that question you have to get almost existential about your career: How many more decades of coding do you have in front of you? If you're planning on an IPO next year and then you're going to devote the rest of your life to your true passion of playing EVE Online, then maybe keep using your current text editor. But for most of us, a few weeks or more of hindered productivity might be worth the eventual gains.

As is often the case, it's not about raw, straight-line speed--it's about fewer chances to get distracted from the task at hand. Nobody ever codes at breakneck speed for 60 minutes straight. But when you're in the middle of a really thorny problem, maybe you'd be better off with a tool that's that much faster at finding/replacing/capitalizing/incrementing/etc, which might give you fewer chances to get distracted from the problem you're actually trying to solve.

As somebody who's used Vim for a little less than a year, that's what it feels like to me. Most of the time. I have to admit that once in a while the Vim part of my brain shuts down and I stare at the monitor for a few seconds. Those moments are happening less and less, though.

Beginner steps

When it came to learning Vim, here's what worked for me:

Practical Vim

Drew Neil's Practical Vim is, uh, the best book about a text editor I've ever read. It does a great job of explaining the concepts embedded inside of Vim. I skim through this every few months to try to remember even more tips, and can imagine myself doing that for years.

MacVim

As Yehuda recommends, I started in MacVim and not just raw Vim. At first you should let yourself use whatever crutches you need--mouse, arrow keys, Cmd-S--to help you feel like you can still do your work. I agree with Yehuda that tool dogmatism is going to be counterproductive if it makes the beginning of the learning process so painful that you give up.

And I still use the arrow keys, and don't really buy the argument that it's ever important to unlearn those.

Janus

As with Emacs, a lot of the power of Vim is in knowing which plugins & customizations to choose. Yehuda and Carl's Janus project is a pretty great place to start for this. I'd install it, and skim the README so you can at least know what sorts of features you're adding, even though you won't use them all for some time.

vim:essentials

Practical Vim is great for reading when you're on the subway or whatever, but you'll need something more boiled-down for day-to-day use. For a while I had this super-short vim:essentials page open all the time.

Extra credit: One intermediate step

After I got minimally familiar with Normal mode, I started hating the way that I would enter Insert mode, switch to my browser to look up something, and switch back to Vim forgetting which mode I was in. I entered the letter i into my code a lot.

I suspect many Vim users just get used to holding that state in their head, or never leaving the Vim window without hitting Esc first, but I decided to simply install a timeout which pulls out of Insert mode after 4 seconds of inactivity:

au CursorHoldI * stopinsert

As explained in Practical Vim, the best way to think of Insert mode is as a precise, transactional operation: Enter Insert mode, edit text, exit Insert mode. The timeout helped me get into that mindset quickly, and live in Normal mode, which is the place to see most of the gains from Vim.

This is an intermediate step, and you shouldn't try it right away. If you're a beginner you're probably not going to benefit from being in Normal mode all the time--if anything the frustration would be likely to make you give up on it. But once Vim starts feeling less disorienting, and you're ready to really learn what Practical Vim has been telling you, I'd give this a try.

Hope that's helpful. And I hope that after a month or two of this, you become as smug and self-assured about your text editor as I am today.

Over time, technological progress makes it easier to write automated tests for familiar forms of technology.

Meanwhile, economic progress forces you to spend more time working with unfamiliar forms of technology.

Thus, the amount of hassle that automated testing causes you is constant.

Looks like your Twitter bots need to be better at quote-escaping:

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.

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.

And there's this, too: Ellipsifier is a Javascript library that truncates HTML. It will retain the tag structure, counting only visible characters in the resulting text.

new Ellipsifier("to be or not to be", 5).result
//              "to be …"
new Ellipsifier('to <strong>be or</strong> not to be', 20).result
//              "to <strong>be or</strong> not to be"
new Ellipsifier('to <strong>be or</strong> not to be', 5).result
//              "to <strong>be</strong>&nbsp;&hellip;"

Another chunk of code written with the good folks at HowAboutWe.

And there's this, too: Ellipsifier is a Javascript library that truncates HTML. It will retain the tag structure, counting only visible characters in the resulting text.

new Ellipsifier("to be or not to be", 5).result
//              "to be …"
new Ellipsifier('to <strong>be or</strong> not to be', 20).result
//              "to <strong>be or</strong> not to be"
new Ellipsifier('to <strong>be or</strong> not to be', 5).result
//              "to <strong>be</strong>&nbsp;&hellip;"

Another chunk of code written with the good folks at HowAboutWe.

The folks at HowAboutWe do a decent amount of HTML email, as you might expect for any site where people can send each other messages. Dissatisified with the tools for developing HTML email, I wrote EasyMailPreview, a Ruby gem that makes it very easy to see the results of an HTML email in development mode. It auto-discovers mail methods and method arguments, and lets you write them on the fly with in an admin-ish screen.

I've been using it for a while, and I find it eases the pain of developing HTML emails. Somewhat.

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.

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.

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.

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.

Awesome.

Last Friday, the bot went a bit crazy and started throwing ["That what she said"] into the conversation with no apparent rhyme or reason. Finally, I had had enough. And then it came to me: I would write my OWN bot, that responded to TWSS with a quotation from a notable woman. If they are so keen on what she said, why don’t we get educated about what she really had to say. And so the “whatshereallysaid” bot was born. It might annoy the guys into shutting off the TWSS bot, or we might all learn about notable women. It’s a win either way, in my books!

As a side note, I've always found "That what she said" to be annoying humor, not just because it can be sexist but because it's also just the dumbest, sloppiest humor you can think of. It's used by Michael Scott in "The Office" ironically, as an example of what a socially inept man-child might think of as funny. When and how it got stripped of that irony I'll never know.

But is it too much to ask people to be less stupid than Michael Scott?

This was surprisingly underdocumented out in the world. If you've got a Rails controller that ever uses request.body.read, you can set that in a functional test like so:

class ArticlesControllerTest < ActionController::TestCase
  test "creates a new article" do
    attributes = {
      :subject => "10 ways to get traffic by writing blog posts about arcane Rails tips",
      :body => "Just kidding, it's totally impossible"
    }
    @request.env['RAW_POST_DATA'] = attributes.to_json
    post(:create)
    assert Article.last
  end
end

@request is a local variable defined inside of ActionController::TestCase, and used when you make a test request by calling post, get, etc.

Martin Sutherland responds to my rich client thoughts with some insightful caveats:

Mobile browsers on devices not designed in Cupertino

First of all: mobile. If you're using an iPhone 4(S), you might not realize that a lot of web browsers on mobile devices are abominably slow. In terms of getting the first page of your app/site up and running on a mobile browser, an HTML page rendered on the server is going to beat a client-side JS application hands down in at least 90% of cases.

I agree that this is something worth considering. But, depending on your application and your audience's technical situation, you may not consider those mobile browsers worth trying to reach, or at least right away. Having recently been a BlackBerry user, I can attest that after a while, some users just stop using the mobile browser unless they're really in a pinch. So when your web site is only as broken as 50% of the rest of the web through that particular device & browser, you can probably get away with it.

There are no doubt sites that are specialized enough on those benighted platforms, and/or just big enough, that mobile non-JS support should be addressed. In this cases, perhaps one option would be to build a thin intermediary site that consumes the REST API and offers a stripped-down web interface. May I suggest redirecting to a subdomain like noniphone4mobilebrowsers.mywebapp.com?

This scenario exposes the fact that you can always have two different ways to access the data on the server, with one piggy-backing off of the other, but choosing which method is the canonical form of access has pretty big implications for how you architect everything. It used to be that you made a thin-client web app with mostly HTML pages, and then wrote the API later. But it may be time to write web apps with the API at the core, and then add non-JS support later, as an edge case.

And it's probably worth noting that to a large extent, this is a discussion about a tradeoff between two constrained resources: mobile device capability (CPU, memory, browser optimizations) and mobile network quality. So is it a cop-out to point to the rate of change here? Mobile device capability is improving at a much faster rate than mobile network quality. So maybe it makes sense to lean into that by building a web app for the idealized high-power mobile browser from the start.

URLs for humans and for others

Secondly, there's the small matter of linkability and history management. If there is any part of your application that you want people to jump to directly, either as a bookmark for their own benefit, or as a link to hand out to others, it has to be have a URL. Using hash fragments for navigation may be a well-established pattern, but it's still a hack. So long as you're using hash fragments, that URL can only be run on the client. pushState() and replaceState() can fix this, but we're still a little while away from these methods being universally available (IE10).

It's probably worth noting that there are really two primary audiences for URLs: Humans, and search engines. And I think the problem is far smaller for the first than the second.

Humans use URLs--in emails, bookmarks, and the back button, but the endpoint of all that link manipulation is the same: Eventually it gets entered into a browser with decent JS support and rendered into something you read with your eyes. In my (admittedly limited) experience using Backbone, the Router and History objects handled these use cases, including the back button, fairly well, and without a lot of engineering. I'd have to believe they're handled easily enough in the other frameworks as well. Yes, there are the still-in-flux UX conventions of what actions are significant enough to create a new point in the history, but this feels like an acceptable speed bump.

(And yes, navigation through hash fragments is a regrettable hack and hopefully will be behind us all soon enough. But is it really a worse hack than using a Microsoft browser in the first place?)

Search engines are a harder case. I haven't been able to find up-to-date info about how much Javascript the Googlebot uses, but I'd have to believe that you'd be a little reluctant to run a full browser environment if you were trying to crawl every URL in the entire universe. I suspect there are going to be some non-trivial stumbles over this one, especially from an engineering productivity point of view. It's not super-hard to imagine how you'd have one master route on the server that figured out how to render the page first server-side, and then do some work to boot the rich client into that state right from the start. But does this mean we're have to support two versions of each view forever--a server-side version and a client-side version? I guess that's one more argument for using server-side JS, but for a lot of people (including myself) that's going to be a non-starter for some time.

One more cop-out might apply here: A lot of pages in web applications are access-restricted, and thus not visible to Googlebot anyway. So that reduces the pain. It certainly doesn't eliminate it, though. I've been starting to wonder if there's a need for, say, a stripped-down Node.js proxy that can 1) share JS views and templates with a rich client and 2) render the full HTML as a response to a single HTTP GET. But, uh, I'm pretty sure I'm not going to write that. For the time being, I think I'll just keep toying around with access-restricted web applications and try not to worry too much about the Googlebots.

(I guess there's a third audience here that I can't speak to at all: Vision-impaired humans. Do rich client apps make accessibility prohibitively difficult? I guess this could be an issue for, say, government sites, but to be honest I can't remember the last time I heard this issue raised for a commercial web app.)

Let's see if I know the ledge, or if anybody else does for that matter

One reason I had for writing yesterday's post was because I sort of wanted to be convinced that I was wrong. I've been having these rich-client thoughts for a while, but holding off from making that jump because of how much work would be involved. So I wrote my thoughts down, hoping that friends and colleagues could help me focus my thinking.

But you know what? There have been a few people (such as Martin) voicing nuanced concerns, but there hasn't been anybody telling me, publically or privately, that it's a terrible idea. And, uh, I know a lot of server-side web programmers.

For the sake of discussion, I'm going to make a recommendation about the state of web application development today:

If you are writing a new web application, you should make it a rich-client application from the start. Your servers should not generate any HTML. You should do all that work in the browser with a Javascript framework such as Backbone.js or Ember.js, and the server should only talk to the browser via a REST API.

I'm not saying I believe this idea 100%, mind you. But I feel like we may be reaching some sort of specific tipping point, and I'm interested in teasing out why this would or wouldn't be a good idea.

There's bad news, and there's good news

There are plenty of good reasons to avoid jumping on this particular bandwagon:

• Many of the tools, patterns, and practices are immature, and your development speed will be significantly slower than if you build your web app using more traditional techniques.
• There are way fewer serious front-end engineers than there are serious Rails/PHP/Python/.NET engineers, and if you have to hire into this codebase you're going to either pay more for those engineers or hire other engineers and expect some non-trivial ramp-up time.
• The Javascript framework space is new, and some significant churn is to be expected. I've used (and like) Backbone.js, but should I be concerned about the possibility of choosing the wrong horse, and then being faced with a massive amount of legacy code to port years down the road?
• Although the Architects among us love nothing more than defining an API, I'm a firm believer that decoupling isn't free: When the code is brand new and the requirements poorly understood, it can waste engineering time and inhibit agility to have to make changes across architectural boundaries. Yes, passing an instance variable from a Rails controller to a view is sort of sloppy and will probably be insufficient one day, but when you're just getting started with a small codebase, that sloppiness works in your favor.

But no matter how rickety the wheels look, there are some good reasons to jump on this bandwagon right now:

• One day, you'll want all those APIs defined anyway, for iPhone apps, Android apps, mobile-optimized sites, partners, power users, etc. In fact, those of you starting mobile-centric products have the moral clarity of needing an API from day one, so this decision might already be made for you ...
• If you write both a traditional web app and an API, then you have two places where the business logic could end up living, which of course is a petri dish for code repetition. Yes, I know you are a smart and diligent enough programmer that you'd never copy and paste anything from one side to another when you're feeling rushed. But please spare a thought for your fellow coders, who aren't so blessed with your work ethic or your mighty intellect.
• Very soon, your customers will expect your web site to be responsive and interactive like Gmail. And the only way you can do this in a web app is going to be lots of Javascript, and a lot of Javascript without a proper framework is way worse than with a proper framework.
• Right this minute, there are successful, serious web applications whose teams are thinking "God, it would be awesome if we could rewrite this in Backbone/Ember/etc." But they might never do it, because they know the pain of that transition will be massive. So, it might make sense for your brand new site to future-proof itself by starting as a rich-client app from day one.

"You Aren't Gonna Need It" vs. "It's Gonna Suck To Get It Later"

A lot of this comes down to cost of change. If it were the case that you could make this transition incrementally, without stress, and without a ton of work, then maybe you could make the argument that going rich-client early on is just gilding the lily. But is that possible? Every time I've ever had the transition discussion with someone it ends up being vaguely stressy until we decide not to talk about it ever again.

Then again, there are probably teams taking this on right now, and they may discover good patterns to help the rest of us. Maybe we'll see a burst of blog posts titled "how we moved our traditional web app to Backbone.js without losing our hair or our money" in the near future. But if I had to bet, I'd guess that it will always be a tough nut to crack.

Nobody ever said "I like it, but I wish it involved more waiting around"

This all stems from my entirely subjective, unprovable opinion that rich-client applications are just better. Responsiveness doesn't just mean that the user can do things faster. It means that she'll like using the application more. It means she can can push ahead to her goal with fewer chances to lose focus. It means that the data and the interactions will feel more concrete and reliable. It means, fairly or unfairly, that she's going to trust the site more, and maybe even be more likely to pay for something.

This isn't some pie-in-the-sky futurism: Users are being trained to expect this right now. They don't even know what to call it, but applications like Gmail are feeding them the expectation that web sites should all be this responsive.

It wasn't long ago that making these apps was insanely difficult, so most of us shrugged our shoulders at Gmail and figured those sorts of problems were above our pay grade. But frameworks like Backbone and Ember are steadily pushing the cost of implementation downward. Your competitor may not have a rich-client app today, but maybe they'll have one tomorrow. When that happens, how many of your users do you think you'll lose?

I could just be jumping the gun here. But allow me a prediction (and feel free to tease me when it doesn't happen): In five years, the vast majority of significant web applications will be rich-client. I can't see any reason that the web wouldn't move forward in this way.

If that prediction is right, then right this minute we're in an uncomfortable position: We can see the future, but we can't see an easy path to it yet. Maybe it's on us to build it, or maybe we'd be better off to grit our teeth and stay back from the fray.

I'm not 100% sure what I think myself, but it's a topic worth discussing now. Thoughts?

Developed for the good folks at HowAboutWe.

If you start an early stage tech company today, it's kind of crazy how many hosted services there are out there, trying to help you build your product for a monthly fee. You can get a service for support tickets, and hosted outgoing email, and error logging, and managed Wordpress hosting, and private IRC servers, and continuous integration, and reporting dashboards, and automated billing, and almost everything else. Of course, if you whip out your credit card and sign up for twenty different services right off the bat, you've set yourself down the path of paying a meaningful chunk of cash every month. You might be reluctant to do that. But I think, if anything, you should err on the side of spending a little too much money on hosted services to help you focus on your product.

For a lot of good programmers, these kinds of decisions aren't really natural. They got into the business in part because they love building, and they pride themselves on being able to handle whatever technical challenge they come across. The last thing they want to do is morph into some middle manager who's so out of touch that he only knows how to throw money at problems.

But here's the thing: If you're an early stage startup, you absolutely do not have the time to solve most problems well. As the saying goes: Startups don't starve, they drown. In a typical day you'll have to take care of 20 things, and you'll only be able to do one or two pretty well. So pick which ones are the most important, and for the other things, you should seriously consider paying a hosted service. Even if the solution isn't exactly what you would've built. Even if it's a bit more expensive than seems reasonable.

The only reason that an early stage company has for existing is to prove that customers want the product that it's building. That's what investors will be looking at when you try to raise--not whether you saved $100 a month by managing your own brochure site. If you pay a little too much for a customer tracking service, that's not going to kill your startup. But you know what will kill your startup? Being too busy fiddling around with half-assed DIY solutions to figure out what your customers want in the first place.

And, in a related note: You will never be able to hire all the programmers you need. The hiring arms race marches on, and will probably only get worse, for, say, the next decade or two? Yeah, there may be little bubble burstings here and there, but generally speaking you should thank the heavens for every great programmer you can get to be an employee of your company. You should know that you might not get to hire another person that great for a long time.

So--to compare programmers to servers--try to scale your team up, not out. Meaning, it's actually going to be very hard to just turn on a switch and hire more engineers of the same caliber. It's easier to make the same engineers more productive by enhancing their work. One way to do that is with a judicious mix of the right hosted services--which are just a complicated way of paying the other engineers who work for those services. (Often living in cheaper cities, so you get some nice wage arbitrage too.)

By now you might be saying "that sounds nice, but I just don't have the cash." If that's the case, repeat after me, about a thousand times: The biggest expense for a startup is your time. Not your laptop, not your hosting bill, not your office, but the hours in your day. Even if you're living on ramen and not taking any wages, your time is still expensive in terms of the wages you are giving up from another company. It is also expensive in terms of the giant ticking alarm clock floating over your head. Because if you fuck around for too long, one day that alarm is going to go off and you're going to realize you're sick of living in poverty, and you're going to go back to working full-time for somebody else.

Of course, this isn't to say that every hosted service is a slam-dunk. There are many times when you should build it yourself. Some hosted services are actually way too expensive, and some products do actually suck. There's the non-trivial problem of startup SaaS vendors going bankrupt or getting talent-acquired. Some business logic is so core that you need to change it all the time, or it's so specific that nobody else will ever build a product that does what you need.

But there are many times when you're going to have to look at somebody's product, and think "I would've built a better product and charged less for it, but I don't have the time to prove that. So instead I'm going to pay you money for doing it worse than I would've done it." And when that happens, it's your responsibility to hold your nose and pull out your credit card.

I'm starting to think that building an early-stage product is an exercise in intentional, selective perfectionism. You have to pick the 1% of the problem that will make your product stand out from the competition, and then polish it until it positively gleams. But if you look one inch to the left of that, you'll see some substandard ticketing system or error reporting system, and maybe it'll drive you absolutely up the wall. And I guess the best you can do in those times and to take a deep breath and tell yourself that you'll get to that one day.

And to some extent, even our own inspirations can be a bit misleading. It's easy to walk into the Apple store and see how beautifully they designed everything, and then think that the way to be the next Apple is to be completely perfectionistic about everything all the time. But Apple is a 35-year-old company. For a very long time, they had to put up with their beautiful products being sold in other people's crappy stores.

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.