This is a really excellent post on the topic, rebutting Paul Graham’s Bay-Area-centric thoughts on the topic very effectively. I’ve worked in both distributed and non-distributed, as well as effective and ineffective teams ;), and Avleen’s thoughts are very much on target.
I’ve been involved in the New York start up scene since I joined Etsy in 2010. Since that time, I’ve seen more and more companies there embrace having distributed teams. Two companies I know which have risen to the top while doing this have been Etsy and DigitalOcean. Both have exceptional engineering teams working on high profile products used by many, many people around the world. There are certainly others outside New York, including Automattic, GitHub, Chef Inc, Puppet… the list goes on. So how did this happen? And why do people continue to insist that distributed teams lower performance, and are a bad idea? Partly because we’ve done a poor job of showing our industry how to be successful at it, and partly because it’s hard. Having successful distributed teams requires special skills from management, which arent’t easily learned until you have to manage a distributed team. Catch 22.
As used in Cassandra ( http://grokbase.com/t/hbase/dev/13bf9kezes/about-xx-threadprioritypolicy-42 )!
if you just set the “ThreadPriorityPolicy” to something else than the legal values 0 or 1, […] a slight logic bug in Sun’s JVM code kicks in, and thus sets the policy to be as if running with root – thus you get exactly what one desire. The operating system, Linux, won’t allow priorities to be heightened above “Normal” (negative nice value), and thus just ignores those requests (setting it to normal instead, nice value 0) – but it lets through the requests to set it lower (setting the nice value to some positive value).