Thank You Coimbatore

It’s difficult to put into words what a eye opening experience it’s been coaching our development team in Coimbatore, India over the last three weeks. As with anyone, my view of people and the world is largely limited by lack of experience. An interaction here or there with an India based development team has really been all that I have had to base my experiences on and with this limited experience I’ve come to realize I’ve developed some unrealistic beliefs about IT in India. I’m extremely thankful for the opportunity to dispel many of the myths that I’ve had about this gigantic and growing population of developers in India. Here are the top ones:

Myth #1: Indian Developers are  Subpar

I had assumed that the caliber of development with the team over here would be pretty substandard. I’ve worked with a couple of different offshoring teams and interacted with a number of people who have done the same. The common lessons learned across those interactions have been, don’t give the offshore team any challenging work and relentlessly review the code when it comes back in. Many people I know attribute this to a lack of technical knowledge with the offshore developers. People believe they are only a year or so out of school and that they don’t  have anywhere close to the amount of programming time that their counterparts in the US have.

Maybe this holds true for bigger segments of developers, but we were extremely fortunate to have six really talented developers on our team. Additionally, within the sixty developer company where they work they are more the norm than the exception. Each team member was extremely comfortable in C#, .NET, SQL, and a number of other technical skills. When technologies were new to the team, they were able to quickly and effectively pick up working knowledge of the tools with a little help from us. We quickly changed our plan from trying to teach technical skill to teaching craft and improving process within our first couple days here. In my opinion the difference between the developers I work with back home and the ones over here is mainly just experience with test driving development.

Myth #2: Communication Will be Easy

Everyone speaks English right? Well at least a country that was colonized by England speaks English, right? Uh, no. The difference between the Indians who have frequently interacted with Americans and those who haven’t was astounding. Communicating with our taxi driver was largely primitive grunting and pointing. There were two members of our group were fluent in English and had little trouble understanding us when we slowed our pace of speech down to a reasonable level. The other five members of the team had difficulty understanding us unless we were gesturing, speaking very slowly and enunciating very well. Neither Tim nor I were able to master speaking to this group effectively.

We did find however that everyone on our team was able to read English and all of their code is written in English so we were able to use that as a common denominator. With a little bit of translation help then we were off and running. We’d favor walking through code on a projector as a team and showing by example the practices that we were trying to teach. Ideas and concepts that we felt were extremely important were captured as reference in our wiki on GitHub. It’s a difficult problem to solve when so much of our success relies on frequent, open and honest communication. As we move forward with 8000 miles between us, we’ll leverage IM, shared living documents, and timely feedback with daily standups, weekly retrospectives and demos.

Myth #3: Cultural Differences are not that Wide

I knew that there would be cultural differences but I really had no idea how different the people are here from back home. I had brushed up on the differences with a great book, Speaking of India by Craig Storti, but to understand the impact they have they really must be experienced. The most challenging one to overcome was the rigid hierarchy in the workplace. When the owner of the company was in the room, no team member spoke except for the team lead and he would only reply with a “Yes” or “Yes, sir”. When the team was asked for feedback they would defer to the team lead every time. If he was out of the room, they would defer to the “secondary team lead”.

This rigid hierarchy was stifling communication which as I mentioned before must be open, direct and honest. We didn’t really try to overcome cultural standards that have been ingrained in this group since the beginning of their lives. Instead we picked our opportunities to have direct conversation with individuals and to solicit feedback from the group as much as possible when they were their most honest (bosses out of the room).

Myth #4: Little Effect can be had in Three Weeks

I’ve worked with a number of really good trainers, coaches, and teachers of Agile techniques and everyone routinely agrees that to get somewhat proficient at Test Driving, Refactoring, and Emergent Design takes months.  I have no intention of being in India, away from my family for months, so the question of how much change we could enact in three weeks was really concerning. I’m not foolish or egotistical enough to think that the developers we’ve worked with are now proficient at TDD, Refactoring, or anything else that we’ve tried to teach them. Further, I know that they will start to regress once we’ve returned to the states. I do believe, however, that these guys already had an inherent thirst for knowledge. We were able to show them the benefits of every practice we talked about and you could see in their eyes and hear in their conversations that they were excited and eager to continue the voyage. Will they become proficient in the same time as if we were with them? Probably not. Will they continue down the path? Definitely. These guys already had the spark of interest going, the most important thing that we were able to accomplish over here was to just fan the flame.

In all, this trip has taught me to question all of my preconceived notions about people. I am hopefully returning from India, humbled, grateful, and much more respectful of the great country and it’s people. Despite conditions that many Americans would find below standard, the people of India are as welcoming and hospitable as any I have ever met. I am thankful for the opportunity to learn more about their culture and I look forward to continuing to build some great software with this team.

Senthil, Antony, Chenthil, Perumal, Sathish, Govind, and Priya, you were all extremely gracious and patient with the boisterous Americans. You made us feel very much at home when we were in need and we will forever be thankful!

தங்க யு கோயம்புத்தூர்

Hire Craft over Technology

Consider this blog post an open plea with hiring managers and recruiters. The vast majority of you focus on the wrong thing when trying to hire developers. Really good developers are exponentially more productive than mediocre ones, but you can’t tell the difference because you are looking at the wrong thing. If you disagree, please ask yourself: “What is the first thing you assess in a candidate when considering them for a project?” I’m sure a few will answer differently but by and large most will say that they are trying to make sure that someone has adequate experience with the technologies in use on the project. I’ve seen hundreds of good, bad and mediocre developers at work and I’m here to tell you that the focus on technical skill should be secondary. Focus instead on hiring developers who embrace quality, take pride in their work, and consistently practice their skill. These developers are craftsmen, not programmers.

Taken at a glance, it doesn’t seem to be a bad thing to focus on technology. Technical skill is mandatory for most development positions. Most hiring managers and recruiters couldn’t fathom bringing someone onto a project written in C# if they professed a novice or rudimentary knowledge of C#. The problem with this mentality however is that there are a number of C# developers who are proficient with the language, yet build very costly systems due to the quality of their code. A developer may know Java inside and out, but it doesn’t mean they know how to build software.

Put yourself in a different mindset, that of a person hiring potential carpenters to construct your new home. If you were interviewing the carpenters would you quiz them continually on their knowledge of a power nailer? No, you’d ask them more appropriately about the differences in constructing load bearing walls from non-load bearing. How to frame a doorway. What procedures they use for ensuring a square corner and flat walls. These questions are all striving to assess what level of quality the carpenter builds into their final product. Why do we not assess the same thing with developers?

I believe it namely boils down to either misperception or laziness.

Misperception

The main misperception in hiring managers is that technical skill equals speed. It may in fact equate to short term speed, but without an additional focus on quality the legacy codebase quickly becomes a giant time sink that is difficult to change. Studies have shown that the vast percentage of our project costs are in the maintenance phase, not the construction phase, yet how many dollars have been lost by companies emphasize saving time on the 20% at the expense of the 80%? Unless you are constructing throwaway code or something that will be extremely short lived, do not focus on the speed to build. Focus instead on the quality and your overall speed will increase. Focus on your speed and your overall quality will decrease.

Laziness

I actually think the misperception referenced above is being debunked more and more by hiring managers every day. Sadly though, many recruiters and hiring managers I know are in a rut where they still screen development candidates exactly as they did many years ago. They build simple quizzes to screen for technical knowledge, followed by phone interviews that screen for technical skill and the good ones even follow this up with a programming interview that again determines technical knowledge. Whether it’s ignorance, apathy, or laziness I’m not sure, but if these groups want to see an increase in overall quality (and therefore speed), they need to start asking the difficult questions focused on craft, not technology. I still do a decent number of pairing interviews and I never dictate that someone use a specific language in the interview process. I think my most memorable candidate actually used a language and editor that he wasn’t that familiar with and still you could tell that he had intimate knowledge of TDD and emergent design. I immediately wanted to hire him for any project that we had available and I knew he would be productive and successful regardless of the environment. Can you say the same for the C# developer who has 15 years of experience which are really 1 year projects repeated 15 times?

Craft is not something that is easily learned. K. Anders Ericsson noted that it takes 10,000 hours of targeted practice to reach mastery. If you happen to get one of those passionate developers who have 10,000 hours under their belt, then consider yourself lucky. If you can’t find those people then do the next best thing and hire someone who truly gives a shit and is practicing their craft. You’ll know you’ve found them when they talk much more about quality than technology.

Hammer photo courtesy of thefixer on flickr

Things I Have Learned About Driving in India

 

In our first few days over here in India, we’ve been privy to some of the most exhilarating car rides I’ve ever been a part of. By exhilarating, I mean that we have actually almost had 3 head on collisions and we’ve stopped in front of oncoming traffic to take pictures while we were passing an ox drawn cart. We really believe that our driver could have some success back in the states, so we’re actively recruiting him for NASCAR. Here are a few of the tidbits we’ve learned from this expert:

1. Lanes are merely a suggestion and should rarely be followed. Instead, find the best opening in the road to position you for massive future  acceleration.
2. If you are behind a bus with 230 people in it, pass carefully. They always have the right away.
3. If you are behind an elephant in the road, pass carefully. They always have the right away. Also, do not tailgate.
4. Horns are by far the best means to communicate that you are on someone’s left, on someone’s right, are about to hit someone, are going to pass someone, are going to ram someone if they don’t let you pass, or that you are sorry for accidentally running into someone.
5. If horns are not conveying your intent properly, resort to flipping your headlights at them.
6. Motorcycles are by far the easiest way to get around. And they can safely transport a family of four. And they can transport 18 month old children.
7. If you are not simultaneously pressing the gas and the break at some point during your drive, then you are doing it wrong.
8. When encountering a traffic light which counts down until you can go, do not be a loser and wait for 0. Go at 5 at a minimum, 10 if you are feeling lucky.

Wish us luck for the next few weeks. I’ll have the unbridled joy of this little guy for every ride…