Sunday, October 26, 2014

Never talk to strangers


People as species have evolved in social groups, cooperating and competing. Simply sharing a space helps to build trust, create a body of shared knowledge, establish social customs. Patriotism, love and pride for one’s land, interest in tails of the forefathers are all feelings that knit together a community of people that live and interact in close proximity.

But when it comes to interacting with people from far away, the situation is different. Historically, people living afar have been perceived as either villains or gods. People who are not participating in every day events in person, if they are not completely disregarded, appear weird, scary, and are ascribed bad thoughts and behaviors. Tribes everywhere are known to have fought long-lasting wars with neighbors living just far enough to not be part of the community.

The entire human history has prepared us to like and trust those close to us, and expect bad things from people who we cannot see, hear, touch and smell. We may not be consciously aware of this bias, but it is impossible not to notice its consequences. Long-distance relationships have a dramatically lower rate of survival, compared with relationships where partners see each other regularly. Most business activity still happens locally, within a single geographic area. Despite the televised debates and online advertising, politicians still fight and win elections by talking to voters on the campaign trail, and building organizations of supporters to do that on candidates’ behalf.

When an organization is working with a remote team, the people on that team are outsiders, not part of the tribe. Remote team members, unable to participate in daily face to face interactions, are subject to all the suspicions and biases outsiders have suffered throughout the human history. To create trust and build good working relationships all sides must work against their natural instincts of distrust toward outsiders.

There are many things that could help make the remote team a part of the inner circle. It could be as simple as giving a voice on the phone a benefit of the doubt – and a chance to explain in greater details how they came up with the ideas being presented. Or as complicated as organizing regular trips to a common location, to let people spend time together, working face to face. Whichever way is chosen, it is still hard work, requiring intelligence, an open mind, and willingness to learn.  


Monday, October 20, 2014

The "family" objection


We recently held a panel titled “Software development is a team sport: Women In Technology” at Houston TechFest in Houston and Austin CodeCamp in Austin, Texas.  The goal was to have a conversation about men and women working together in IT and software development industry. Research shows that we are more productive because of our differences, not in spite of our differences, when we manage to work together. We had great participation: men and women shared stories, concerns from their experience, concerns they have for their daughters, difficult situations and techniques that worked in different environments.

Each time, there surfaced an old-time objection to hiring women:
-          Why hire a woman, who may get pregnant and go on leave for weeks, and then perhaps be somewhat distracted for a few more months, when one can perfectly well hire a man, who is not in any danger of ever bearing a child?
This entire line of reasoning strikes me as odd.

Fertility rate in the US is 1.9 children per woman, i.e. over a lifetime an average woman is expected to have 1.9 kids. Women with more education tend to have fewer children, so for women with a college degree the average is just 1.1 children

A college graduate typically has a 45+ year career, male or female, first entering the workforce at age 22 and working at least until his or her late 60s.  Today’s typical tenure in IT at a given position, job or company is 2-5 years.

So, a woman interviewing for a job today, has an approximately 2-in-45 chance to have a child while working at this job.  If she already has a child, that chance falls to 2-in-450. 

In order to get this interview, this woman has shown herself to be a stronger candidate than, typically, 2 to 100+ other people, who also applied for this position.  She still has to beat 2+ other candidates, also invited to interview for this position. Overall, her chances of becoming the top candidate are between 1-in-4 and 1-in-100, which makes her (or anyone reaching that point) quite awesome!

Now, consider another angle. Productivity among mediocre, good and great developers varies by orders of magnitude.  Hiring the best person for the team makes a significant difference in bottom-line productivity, quality, time-to-market and maintainability of the project.  A woman who is x10 as productive as the next candidate, even if she takes 2-4 months (over her 2–5 year tenure in a particular job) to take care of her family, is still a net win for the team with a realized productivity gain of 90%+.  And this is the worst-case scenario!  In a typical case, your best candidate will deliver an even better value, regardless of her gender.

The argument about women's propensity to take time off to have children makes no sense in the context of hiring the best person for a software development job. Any organization's best bet is to identify and hire the best person they can get, and then make sure that person stays with them as long as possible. Regardless of their gender.


Saturday, October 11, 2014

Discussion about good code at DallasTechFest 2014

Many programmers are dedicated, or even obsessed, with writing “good” code.

Often we follow certain patterns and practices because we believe they are the best solution for the problem, or because the experts tell us so. There are many quasi-religious wars about proper ways to write code; those wars last years, inflame the most peaceful communities, and make many heads spin.

While it is easy to argue whether a particular piece of code is good, it is hard to come up with an overall idea of what makes code good. We had an interesting discussion about good code at Dallas TechFest, with a great crowd of fellow developers.