Are programmers in India as good as programmers in the USA ?

Anant (names have been changed to protect the privacy) is a punctual, hardworking NET programmer located in India. Sam is a punctual, hard-working .NET programmer located in the USA . Anant has the usual and customary degrees expected from an Indian programmer and is consistently striving to improve his skills. So does Sam. Anant’s work day starts at 9:30 am and ends at 6:30 pm. Sam’s starts at 8:00 am and ends at 5:00 pm.

On my recent visit to India, I had an opportunity to observe, document and infer programming abilities and the impact on employers and managers.

As an outside non-involved party, it was easy to observe the workings and the styles of Indian programmers and their managers. While in the past, when I had managed teams in India, I was an involved party and could not see the trees for the forest.

When talking about the quality of Indian programmers either people are in awe or in utter disgust. There appears to be no middle ground in that. Either they are supposed to be absolutely brilliant or clueless idiots. Like other places in the world, Indian programmers are spread across the spectrum. You find really brilliant people with and without formal education and really dumb programmers who think C# is a musical note.

If we ignore the two extremities we are faced with rather a large pool of mediocre programmers who can become a cost effective force for you. This pool like the American workforce likes to go home on time, do not like to work on weekends and generally thinks there is life outside programming. The challenge then is to mold them into our work and communication practices.

The biggest challenge though is communication – the accent to ungrammatical English to technical domain to conceptual understanding to the time difference. Your success (or failure) will entirely depend on your ability to communicate effectively to the programming team. This is solely YOUR responsibility – just as it would be with Sam.

The other challenge would be to convey your sense of quality and deliverability. Quality of your finished product will depend on how well it is defined. Again something you will need to define.

More on how to address these issues in the future blog.

Ram.