Things I Wish I Said
Making group decisions
Wednesday, February 17, 2010
There's a huge amount of advice available for decision-making, well-being, spiritual development, and the like at the personal or individual level. It's far from a solved problem. More attention needs to be paid to the problem of figuring out what larger groups of people ought to do, though. Just a for-instance, the Bible has quite a bit of material on how to behave personally, but the best known group governance advice is treated as uniform individual admonishments ("Noone should kill other people.")
This seems to be a common feature of thinking aimed at the governance of groups -- "if everyone would just follow these uniform mores, everything would work out well!" Well perhaps so, but if you haven't noticed, that's not happening. Exhortation would appear to be fruitless. Making group decisions and deciding on group governance is not a process well modeled by gas laws (treating all the individuals as interchangeable and with simple inter-personal mechanics), even, perhaps surprisingly, for quite large groups of people.
I'm not sure what the technical terms are, but I even wonder how applicable lessons from smaller groups are to larger ones. For instance, countries are heterogeneous groups of people with largely involuntary memberships. (You can't just declare that you're not bound by a country's decision-making process, and conversely, the country can almost never just kick you out.) The sanctions available to countries, then, are radically different from those available to smaller groups which are more homogeneous (at least in some dimension) and have voluntary memberships, and from small groups like families which are genetically related. Do many lessons from families apply to corporations, clubs, or churches? Do the principles of organization of these kinds of communities apply well to countries? At first glance, it sure doesn't seem so. Even if there are principles of human psychology which apply to all these regimes, it seems more than just plausible that they manifest quite differently in different types of organizations.
Informally, quite a bit of the thinking on this topic that I'm aware of without digging in very deeply seems to be aimed at figuring out how to make country-level governance operate as an extension of smaller homogenous-and-partial group dynamics. That is, the idea is that there should be some kind of proper subset of the country, which is easier to think about in terms of the dynamics of voluntary and partial group processes, and which should be in charge of making decisions that bind the whole country. The thinking is mostly about establishing the composition and selection and size constraints on this group. That is, the theory is that if you can figure out how to specify "the perfect ruling elite" with just the right rules of behavior on it, then it will be appropriate to vest governance of the whole in that body.
Whether you are a royalist who thinks direct personal ownership of the country by a bloodline of monarchs is the optimal elite, or a republican who thinks that a set of rules specifying the operation of some sort of legislative body is correct, I wonder why we seem to be so drawn to this way of thinking. What evidence is there that this is the best (or even a good) way to do governance at the level of a country?
¶ 11:55 PM 0 Comments
Having a Title and Description
The idea is to answer the question, "So, what are you doing?" or "What is your project about?" Here's a stab at a necessary and sufficient list of constraints on the answer to that question.
1. It has to be short. That is, think about it as the title and paragraph description on SourceForge, or the title and a snippet in a search result or in an RSS reader. The canonical 140 characters is a good upper limit.
2. It has to be written. Written like *written*. Like writers do writing. Not like "I put a bunch of ascii characters in a row."
3. It has to be concise and descriptive. More nouns and verbs than adjectives.
How come? First of all, it should be short because it should be easy to explain. It should be easy to explain because it should fit into the world in a way that is easy to explain. If it isn't, it is probably a waste of time.
It should be written in order to solve two problems. One is communicating it to people who aren't in the elevator with you. This also puts a proper scope threshold on the project. A project which isn't worth titling and describing is not a software project. It is something you should do with awk or grep.
The description should be mostly nouns and not many adjectives. This makes sure that you know what it is you are trying to do. The writing of this description commits you to some thinking. Fine. You may be wrong, but fortunately this needn't be your last project. You can change the description and try again.
These constraints imply a certain level of thinking and iterating and refining about what it is you are doing. That's fine. That's basically writing like writers do. ¶ 10:20 PM 0 Comments
I was listening to the Stack Overflow podcast today. I was struck by something that seems like an obvious procedural thing that is so often missing from software projects: having a title and description. This is often called the 'elevator pitch.' Or, as the podcast calls it, a 'vision statement.'
The idea is to answer the question, "So, what are you doing?" or "What is your project about?" Here's a stab at a necessary and sufficient list of constraints on the answer to that question.
1. It has to be short. That is, think about it as the title and paragraph description on SourceForge, or the title and a snippet in a search result or in an RSS reader. The canonical 140 characters is a good upper limit.
2. It has to be written. Written like *written*. Like writers do writing. Not like "I put a bunch of ascii characters in a row."
3. It has to be concise and descriptive. More nouns and verbs than adjectives.
How come? First of all, it should be short because it should be easy to explain. It should be easy to explain because it should fit into the world in a way that is easy to explain. If it isn't, it is probably a waste of time.
It should be written in order to solve two problems. One is communicating it to people who aren't in the elevator with you. This also puts a proper scope threshold on the project. A project which isn't worth titling and describing is not a software project. It is something you should do with awk or grep.
The description should be mostly nouns and not many adjectives. This makes sure that you know what it is you are trying to do. The writing of this description commits you to some thinking. Fine. You may be wrong, but fortunately this needn't be your last project. You can change the description and try again.
These constraints imply a certain level of thinking and iterating and refining about what it is you are doing. That's fine. That's basically writing like writers do. ¶ 10:20 PM 0 Comments
Being Smart
1. Listening. There are thousands of really smart people, and the weird thing is that a surprisingly large number of the best, in whatever area, are constantly blabbing about whatever great thing they thought up. All you have to do is figure out who they are and pay attention. That's substantially easier than thinking up good ideas yourself. It requires skill at evaluation, because such people will throw off a dozen horrible ideas for every good one. That's expected. But it is easier to cultivate a careful ear than to arrange to be born a genius.
2. Persistence. 90% (or whatever) of success is showing up, and there are lots of forces aligned to make persistence pay off. Working hard and sticking with something is key. An idea has low value compared to sustained execution. This has to be balanced against adaptability and knowing when to make course corrections, of course, but that's really just another way to look at persistence: you persist despite the need for course corrections, not fighting them.
3. Planning. You can cultivate the ability to be tremendously productive by being attentive to what the most important thing is to do. It isn't always easy to plan that ahead, but it often is. Getting things done by setting intermediate goals, doing simple workable things first. Practicing. ¶ 9:32 PM 0 Comments
Tuesday, February 16, 2010
Here are some things I've learned about being smart. All else being equal, it's good, but there are things that are more important. Whether or not being smart is genetic, these skills can largely be cultivated.
1. Listening. There are thousands of really smart people, and the weird thing is that a surprisingly large number of the best, in whatever area, are constantly blabbing about whatever great thing they thought up. All you have to do is figure out who they are and pay attention. That's substantially easier than thinking up good ideas yourself. It requires skill at evaluation, because such people will throw off a dozen horrible ideas for every good one. That's expected. But it is easier to cultivate a careful ear than to arrange to be born a genius.
2. Persistence. 90% (or whatever) of success is showing up, and there are lots of forces aligned to make persistence pay off. Working hard and sticking with something is key. An idea has low value compared to sustained execution. This has to be balanced against adaptability and knowing when to make course corrections, of course, but that's really just another way to look at persistence: you persist despite the need for course corrections, not fighting them.
3. Planning. You can cultivate the ability to be tremendously productive by being attentive to what the most important thing is to do. It isn't always easy to plan that ahead, but it often is. Getting things done by setting intermediate goals, doing simple workable things first. Practicing. ¶ 9:32 PM 0 Comments
