Why I Will Never Feel Threatened by Programmers in India

Outsourcing or not, if you want cheap, you will get cheap.

Another is the fact that the culture within a lot of contract shops isn't exactly innovation-driven. I really don't understand how you could get an engineer/coder passionate enough to be interested in some stranger's project.

Net net I agree with the author: you can still make a career out of tech. The doomsayers from ~10 years ago who predicted the end of the US programmer were wrong. I don't think however that big companies (Cisco/Microsoft: any company with a big India development center) will ever hire legions of US programmers again though. That train has long since left the station.

The crux of the problem is that working with a remote team is a very different proposition than working with people onsite - a fact that is obvious but that people generally fail to act on.

Quite often at my company we're contacted by clients want to hire folks in a foreign country and expect them to work like remote employees, but cheaper, and with fewer legal responsibilities. They think that through the wonders of Skype and email, people in India (or South America) can work just like on-site employees.

The reality is that outsourced development to remote teams only works when the client is willing to adapt their own work patterns to it. As a client, you need to:

* Have a crystal clear idea of what you want built. The less communication overhead you have with the remote team, the easier your life will be, and the more likely it will be that stuff gets implemented the way you want to.

* Have frequent and early deliverable dates. Don't start a project that will take 6 months to get a first release out with a remote team. Shoot for as early a release as possible, followed by frequent small releases. This lets you pull out almost whenever you want and also reduces the likelihood of burning out the developers on the other side.

* If you already have a company with a bunch of people, have the remote developers work outside your regular dev cycle. Don't expect to plug in a couple of guys located 5 times zones away into your regular team, unless your regular team is already distributed.

* Be linguistically very compatible with the folks you're outsourcing to. If you have any difficulties understanding or being understood by the folks you're hiring, then you're significantly increasing your risk.

The well known Ruby consultancies like Pivotal, Thoughtbot and Hashrocket will all tell you, that outsourcing to foreign countries is a mistake, and that developers need to be on-site. This, of course, while basing a huge amount of their business on Rails and a bunch of other open source libraries and frameworks which are developed almost entirely by distributed teams. These companies have an economic incentive to lead people away from outsourcing to cheaper countries, so follow the money.

It just also happens to be the case that since many clients don't understand how much their own workflow needs to change, many outsourced projects fail and reinforce the idea that outsourcing doesn't work.

There exists good developers in India, but they are harder to find than good programmers locally, because of the distance.

It really is the case that 50% of everybody is below median — doctors, programmers, judges, …!

> Have frequent and early deliverable dates.

Both of these things are extremely difficult (if not impossible) for experienced software consultancies to know up front, let alone the crowd looking to outsource. More importantly both figuring out what to build and knowing when those things are deliverable have, in my experience, required the involvement and input of the developer.