home
events
synthetic zero
contact
   
about

 

October 28, 2007

One of the most difficult things is noticing the root causes of suffering --- oddly enough, though we experience suffering primarily as the result of a sort of frenzied form of desire, or fear, this comes not, as one might think, from an excess of attention (on the things that frighten us or we want), but from a sort of rushing past things, a lack of attention. We want to rush, either towards or away from things, and in the process get caught up in a self-defeating loop, by not fully appreciating either the object of our desire/fear, or the whole context of our situation at any moment. It's a lot like a dog who sees a bone on the other side of a picket fence and perpetually attempts to jump the fence to get the bone, without stopping to notice the open gate at the other end.

Why tie knots in the sky
Simply relax
In the natural state of being
First tighten loosely
Then loosen loosely
Hold onto nothing
Let it go as it goes
-Machig Lapdron, great Tibetan woman and yogini, inventor of the famous chud practice

permalink

October 27, 2007

Software is one of the most complex things human beings have ever built. Most software systems consist of thousands or millions of lines of code, each line potentially interacting with or affecting any of the others. Software is so complex to build that projects frequently fail --- over the years, software development methodology has evolved greatly, with many different techniques which have gone a long way to making software projects more predictable; but it's still a risky, complex business. Only recently, Microsoft's Vista operating system came out three years late, with many promised features omitted. Even well-known software veterans can create software projects that fail spectacularly. As Scott Rosenberg, author of Dreaming in Code, a book he wrote documenting the progress of such a project, says in the interview:

... Some of it is rooted in the industry's own history and rhetoric, the mythology of forced marches and death marches and Netscape Time---all these things that suggest that if only you push hard enough, you can do it faster. Managers get into saying: "I want it yesterday, the competition had it yesterday, why can't I have it yesterday?"

Another aspect is that, because software is so insubstantial and a lot of managers who are not programmers themselves don't really understand anything at all about it, they don't have the frame of reference that people have when they're building a bridge or a building. When someone is building a skyscraper, there is a gut-level understanding that you have to dig the hole before you can pour the concrete, then you can put up the beams. There's a natural sequence of dependencies in the physical world that you can imagine very easily, and you can see it's going to take time. Software is basically entirely abstract, except for the screens, and the screens are what business people always end up focusing on. The insubstantiality of the product promotes the idea that, hey, why should it take so long? There's nothing there.

However, progress has been made. Spectacular failures are less common than they once were, and new techniques and methodologies have made building software a less problematic pursuit. In many ways, driven by the necessity of finding ways to streamline something that has proven to be far more difficult than people might have at first expected, software teams have evolved many principles and best practices, some of which are not at all obvious at first, and some which are really very nonintuitive. Starting with The Mythical Man-Month, which illustrated why adding people to a late software project often made the project take longer, there are a lot of things successful software companies do which traditional management orthodoxy might have seen as strange, or highly counterintuitive, in the old days. In particular, however, I find it interesting that the most successful software companies tend to have a relatively playful working atmosphere --- ranging from flexible working hours to things like Google's famous "20 Percent Time" to having toys in the office, etc. It seems to me that this playful approach is more than a coincidence --- it's also a matter of practical necessity. Software is hard, and for that very reason you need to be able to step back at regular intervals and reevaluate what you're doing --- as an individual, as a team, and as a company. Engineers need the time to decompress so they can think more clearly --- working hard is part of the development process, but so is taking a break, seeing things fresh.
permalink

October 17, 2007

Please consider donating to aid the Burmese people.

Alyse Emdur sends me your personal moon.


permalink

October 12, 2007

Caroline sends me a softer world:

Khaela is writing again, a little!

Nadia has a new blog, Masters and Slaves, about social networking and virtual selves. She's just starting it but I'm eager to read how it evolves. It looks promising.
permalink

October 11, 2007

Trust, as I think of it, is not about blindly believing someone --- it's about giving the people you have decided to trust the benefit of the doubt, and thinking deeply about what might motivate them to say and do what they say and do. Of course I think you have to check what others say and have a critical mind --- but trust involves suspending final judgement long enough to consider carefully the possibility that while they might be wrong, they might in fact have a reason for their words or actions that is deeper than it first appears. That sort of trust requires at least two things --- the first is an active imagination and ability to imagine yourself in another person's position, and an ongoing critical engagement with the other person to find out what and why they do or say what they do, which may involve a lot of skepticism --- but underlying that skepticism is an openness to the possibility that you may not already know. Being open to and respectful of the unknown is crucial --- not to attempt to transform it all into the known, but rather to always acknowledge the unlimited nature of the unknown. These things are not mere attitudes, but in fact require considerable practice. In other words, trust is a skill; it has to be carefully cultivated, and it is not easy, but it can create an opening for much deeper communication than is otherwise possible. Naturally, you have to be careful who you trust, but even if you know who you want to trust, it is not at all easy to trust effectively. Blind belief is not trust --- it's merely a kind of subjugation which is both unhealthy and of little help to either party.

David sends me this terrible article about the current situation in Burma.

Jason Sinopoli sends me nonesensenyc, a mailing list about "independent art, weird events, strange happenings, unique parties, and senseless culture in new york city." He recommends it highly. Looks intriguing; I signed up.
permalink

October 4, 2007

Please check out and sign this petition in support of the Burmese monks who are being so brutally killed and suppressed. On the same page is information about various marches around the world on Saturday the 6th --- I will be heading to Washington DC to participate in a march starting at the Burmese Embassy at noon. Email me if you'd like to join us!
permalink
 

 

september