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
permalinkOctober 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.
permalinkOctober 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