kschrader

Most of the good engineers I know are just as adept at hashing out a solution on a whiteboard as they are doing it quietly by themselves, and, given the sample set that I've seen over the years, I've found that the collaborative solutions tends to be better.

We work in an open work space, and I can't even count the number of times that someone has jumped into a discussion with a better idea of how to implement something. If that saves the original people a couple of hours (or days, etc) then we've immediately increased productivity.

I don't buy into the idea that being "more productive" means sitting by yourself in your home office cranking out code.

I still haven't come across a tool that allows telecommuters to replicate this process.

We're building an awesome new advertising platform for ecommerce companies, and we're already making money and growing.

We're in a giant loft in SoHo, work in an open, agile environment, and work in JRuby, Java, and pretty much any other language that will run in a JVM.

All of the regular start-up perks, and we're also projecting all of the World Cup games on our wall right now.

http://www.intentmedia.com

More job descriptions going up later this week, but feel free to email me directly at kurt@intentmedia.com

I lived in SF for a number of years, and the mix of impressive to unimpressive start-ups is fairly similar in both places.

If you can't find anything interesting it's just because you aren't looking.

I find it hard to believe that he's making this argument with a straight face. When someone pirates a game then you have two copies of the game online. When someone purchases a used copy of a game then, sure, the publisher doesn't get any more money, but the servers still have the same level of traffic on them.

This is like saying that selling a used car that's still under warranty is bad for the car manufacturers because they now need to maintain the car, even though it has a new owner.

If your original price can't cover the cost of the services that you've promised to provide then clearly you need to raise your prices.

If I incorporate a company one day and bring you on board the next day with half of the available founders equity then would you argue that you're "just an employee" because you weren't there on the day that the company was incorporated?

Small team right now. Ruby. Java. Agile. Well funded.

Hit me up directly (kurt@intentmedia.com) or work@intentmedia.com if you're interested.

Also, I'm not suggesting that you cut out the phone interview all-together, just keep it short and be ready to schedule an in-person interview them as soon as possible, preferably while you have them on the line.

When I'm looking at a company, I'm trying to determine if they're a good fit for me just as much as they're trying to determine if I'm a good fit for them. A big part of this is showing me that you have the ability as a company to recognize talent and execute accordingly.

The other key is to move fast. If you want one of these people, don't waste their time with phone interviews and things like that, just get them scheduled to come in as soon as possible.

At my last two companies we would bring people in for an afternoon of interviews and have an offer ready for them at the end of the day if things worked out. That's the kind of process you need to have to snag people like this.

As a simple case study, the last time I decided to get a job I had 3 offers within two weeks. All through my network.

Currently, I left my last startup in the middle of last week. I haven't started actively looking for something else to do yet, and I've already had one offer through my network.

Really??? He can't be serious here. I know a number of ex-VCs who have done this.

His page on the speech: http://uts.cc.utexas.edu/~varanus/Controversy.html

Wikipedia article: http://en.wikipedia.org/wiki/Mims-Pianka_controversy

Wait, what? How does that make sense?

When you get this extreme with your process you're filtering out a bunch of great people who won't put up with this all of this bullshit.

Your code coverage metrics are only going to cover what you've written, not the included jar files. If you don't cover something in there then there's no way to know if it breaks until the bug crops up in production.

When you're first starting a tech start-up you need to go through an intensely creative period to help you figure out what exactly you're going to do at the beginning. After that you need to put a ton of time into making things happen.

In my experience, your day job will suck so much life out of you that your start-up will pay a huge price during this crucial early period.

Up to you whether or not you're getting enough of a productivity gain to justify it.