With regards to the senior thing, what about the following example. Say there's an engineer with 6 years experience delivering projects, but not in the language you're working in. You bring them on and they pick up your language. Is this person senior when they come in? How about after 6 months? I think they're senior the entire time. They just need a little ramp up time to pick up the language specifics. Having this person pair with one of your existing programmers probably won't reduce your velocity. They may ask basic questions, but those are quickly answered. Most of the pairing time is spent discussing the solution anyway. If you think it will significantly reduce velocity, I'm curious to hear why. Or how about this. You have a single pair with two good programmers. Call them either mid-level or senior. You hire two green people. So now you have two pairs with one mid/senior and one green. I'm willing to bet that your velocity will increase immediately and go up even more as the green programmers become more proficient. You're still talking about two pairs vs. one pair. And given that you have a proficient programmer in each of the pairs they'll offset the junior person. Besides, some of the value of pairing is simply having someone to talk through a solution with, regardless of their experience level. Regardless of all this, my overall point is that there are engineers out there that are perfectly able to pick up a project and help build it, it's just that expectations can sometimes be too high on the side of the startups. You either have the money and/or the clout to recruit the best or you have to make a compromise. Most startups fall into the having to make a compromise category. They need to seriously think about how to ensure that they build talent in the organization.

Luke, while I agree that your velocity may take a little bit of a hit, I don't think it will be that bad. I also disagree that it's a bad idea for seed stage startups to hire inexperienced people. I'll give early stage Facebook as an example. The only engineers involved in Facebook at the seed stage were students who were either only half way through their CS degree or weren't even in CS to begin with. They picked up what they needed on the job and went on to become well regarded, experienced engineers. Zuckerberg was more than willing to hire inexperienced engineers because he was inexperienced himself. Running out of runway will kill any startup, regardless of the experience level of engineers. Experienced engineers may be able to turn out more features, but it doesn't mean that they'll turn out the right ones.

I haven't seen that before, but my first commit predates that project by about 30 days.

Hey Kim, that's an extreme case for sure. Mark's definition of job hoppers included people that stayed at a position for 1-2 years and moved on. He wasn't even talking about people that are making obviously unethical moves. That's why it's important to check references and find out what kind of people you are hiring. Again, that has nothing to do with filtering a stack of resumes. The truth is that you won't be able to catch everything. You can't plan as though you'll never make a bad hire and you can't let the possibility deter you from getting things done. It's kind of like sacrificing freedom and liberty for security... you'll get and deserve neither.

Hey Rich, I agree that staff churn is bad and should be avoided. However, I don't agree with your thought that my goal to create a fantastic work place equates to "Bill and Ted" thinking. Look at Fog Creek Software. Joel has written and spoken publicly about creating the most excellent workplace for developers. The result? Zero churn. None. And this is to create bug tracking/project management software (something that most devs find uninspiring). Seeing a bunch of jobs on someone's resume is certainly a signal of something. It's a signal that they haven't found the right job yet. It's a stretch to say that it's a signal of character flaws that make the person a miserable hire. You could find someone with only one job of 10 years on their resume. Is it because they found the perfect job or because they're a lazy piker that will stay in whatever position that won't fire them and asks the least of them for a paycheck? You just don't know until you talk to them more (and even then you're still making a guess, but with more information).

Thanks Mark. Just posted a comment on your post.

Hey Ryan, I have a couple of counter-points. First, on this: "one of the things I've heard before for startups is: "At my startup, we could do everything right in creating a perfect atmosphere for a new employee... and it could still be struggling". One thing I've heard before is that you should be quick to fire. The wrong hire can completely ruin your chances of success. If you're giving someone every chance for success and they're still struggling, it's time to have some serious discussions. Of course, that has nothing to do with the resume filter. The second thing: you're right that I haven't had to sift through 1,000 resumes. At my last job we had a full time recruiter that piped candidates to me. I probably did about 70 interviews over the course of a year to help identify people for a team that added 10 people. A directed recruiting effort is much better than putting a bunch of job posts out there and getting thousands of resumes. That means searching through LinkedIn, looking on Github (probably the best for developers), and hitting more targeted sites (like WorkingWithRails for Rails devs). Basically, be more proactive in your recruiting effort. Don't post to a job board and get back 1k anonymous resumes. Finding talent is hard. It should be a core competency for startup founders. Of course, get back to me in a year and I'll be able to give a more experienced opinion. :)

Sure, I can add that in. The disease you're thinking of is either typhus or typhoid fever, neither of which have a relation to each other or the source of the name for this library. The name is a reference to a greek god of the same name that was the father of Hydra. He's more commonly known as Typhon.

Hey Pete, I haven't tried that before. As for handing it off to ruby and then going over to nginx, it seems like you wouldn't get the speed improvement. Once you've hit the Ruby process you've already lost. I'm sure you could keep it inside an nginx module. The easiest way I can think of (although probably not totally secure) is to store the session in memcached with some sensible timeout. That session id would get passed around in the cookie. That way when a request comes in you can check to see if its there inside nginx and if it is then hit memcached again for the resource. Just an idea, not sure if that will work. I'd be interested in hearing what you come up with.

Hi Alexander, Getting the tld is actually trickier than that. Have a look at the public suffix list. Sometimes the known suffix is two or three dots deep (co.uk, *.*.jp, etc). As for adding to Ruby, I'd be more than happy if ruby-core took it, I just don't see that happening. Easier to write my own library. Finally, I don't like monkey patching other people's code for public release. If it's something in my own code base, fine, but not if it's something I'm going to share with the world. The beauty of gems sand OSS is that I can write something really small that has use for other people and easily distribute it.

I wasn't familiar with Addressable::URI, but at a glance it seems as though it presents the same basic functionality as the standard library URI. The problem I needed to solve with this library was identifying subdomain, domain, and tld (not just the full host). I also needed something that could create a canonical representation of URLs. This is helpful if you're indexing off this and want to do a site search or something. If I index a bunch of pages and key off the canonical URL the query to show everything from this site would be two starts with queries like this: net.pauldix.* net.pauldix/* That doesn't seem to be something that Addressable::URI supports. As for names, I'm a big fan of coming up with memorable and searchable library names (since they're not part of a standard lib). However, I generally try to use descriptive class names within the libraries I write.

The main Hydra, Request interface doesn't, but using the basic Easy object should work for HEAD requests.

I'm pretty sure it does that. At least, I think libcurl does that automagically.

I didn't. However, doing the GET is exactly what I didn't want. I don't want my parsing code mixed in with the HTTP code. I probably would have used something else if I could find it. I just didn't turn anything up on a search.

Hey Chris, I assume this was you that posted on the Typhoeus list, but just in case it wasn't, you can join in on the thread about this issue here: http://groups.google.com/group/typhoeus/browse_thread/thread/924d460ebbb240ac

Hi John, I don't know what the requirements are. To be honest, I used very little from curb. I definitely used a few pieces in the multi code, but almost everything is completely new. With open source, everyone builds on everyone else. Neither of these libraries could have been written without libcurl. That couldn't have been written without gcc. I think it's just best efforts to give credit where it is due and not to rip off blatantly. Have a look at the c code in both libraries. I think you'll find that they are quite different. However, I definitely couldn't have made typhoeus without the help of looking at the curb code.

BigLove, I suppose I should probably put together a comparison. What would be the proper ones to do? I can think of: * EMHttpClient * 1.8.6 Threaded * 1.8.7 Threaded * 1.9.1 Fibers Running all those would be a pretty big pain in the ass though. If I have time I'd love to do that, but the real point of the benchmarks was to showcase the difference of running parallel vs. serial execution.

ehsanul, I didnt' run a comparison against the multi because of it lacking many of these features. julien, em-http-request is probably as fast. However, I wasn't able to get it to support everything that libcurl does. Glenn, I tested against 1.8.7. Even in 1.9 I doubt it would compare. The problem would be with blocking IO. Although it would be interesting to test against a NET::HTTP Fibers implementation for parallelism. Sean, I want to update Feedzirra to use this. I'll hopefully get to that in the next week or so.