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.

Continue reading “Rich clients: On mobile, and history management” »

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.

Continue reading “Should your web application be rich-client from day one?” »

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.

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